Cloudflare プライベートロードバランサー: セッションアフィニティとハッシュ振り分けで同じユーザーを同じサーバーへ
Cloudflare One Client や Cloudflare WAN から私設ネットワークへ向かう通信を振り分けるプライベートロードバランサーで、ユーザーごとに同じエンドポイントへ送り続けられるようになった（2026-11-04）。
何が困っていたか
社内の業務アプリなど、セッション状態を 1 台のサーバーのメモリに持つアプリをプライベート LB の後ろに置くと、リクエストごとに別サーバーへ振られてログインが切れたり、処理途中の状態が見えなくなったりする。これまでは LB を使わず 1 台に固定するか、アプリ側でセッションを外部ストアに出す必要があった。
2 つのやり方
| 方法 | 設定場所 | 動き |
|---|---|---|
| ハッシュによるエンドポイント振り分け | ダッシュボードでプールの Endpoint steering を Hash にする | プール内で、ユーザーごとに決まったエンドポイントに割り当てる |
| セッションアフィニティ | API でロードバランサーの session_affinity を ip_cookie にする | エンドポイントが正常でプール構成が変わらない限り、同じエンドポイントに送り続ける |
ユーザーの見分け方は入口で変わる。
- Cloudflare One Client から来た通信はデバイス単位で識別するので、Wi-Fi から 4G に切り替わって IP が変わっても同じエンドポイントのまま。
- Cloudflare WAN の拠点など、それ以外の通信は送信元 IP で識別する。拠点の NAT の後ろにいる全員が 1 台に寄る可能性がある点に注意。
対象は Cloudflare Tunnel・Cloudflare Mesh・Cloudflare WAN の先にあるエンドポイント（エンドポイント = IP アドレス + 仮想ネットワーク）。
注意点
- 固定されるのはエンドポイントであって、通信を運ぶ
cloudflaredや Mesh のレプリカではない。コネクタを冗長化していても、アプリのサーバー固定には影響しない。 - エンドポイントが不健康になる、またはプールを編集すると割り当てが変わる。メンテで 1 台抜くとそのユーザーのセッションは切れる前提で考える。
- 送信元 IP 方式は、拠点 NAT で偏りやすい。均等に分けたいならアプリ側でセッションを Redis などに出すほうが確実（ここは筆者の補足）。
- Tunnel の私設 IP をエンドポイントにする場合は、その経路を含む仮想ネットワークの指定が必要。仮想ネットワーク ID の書き方は Workers VPC: network_id = "cf1:vnet:<UUID>" でバインディングごとに仮想ネットワークを選ぶ も参照。
出典
- Changelog: developers.cloudflare.com（2026-11-04「Steer Cloudflare One users and private networks to the same endpoint with session affinity and hash steering in private load balancers」）
- Private Network Load Balancing: developers.cloudflare.com