本文へスキップ
MameTechNews
バックエンド

Cloudflare、非公開IPのオリジンにWAFとWorkersを通す機能を一般提供

## POINTS

  • プライベートIPへプロキシすると、公開IPを増やさずにWAF、キャッシュ、Workersを使える。
  • 利用の有効化はアカウントチーム経由。Tunnel以外ではUnified Routingも必要になる。
  • 戻り経路に100.64.0.0/12と2606:4700:cf1:5000::/64が無いとオリジンへ届かない。

対象はプロキシしたAまたはAAAAレコードだ。RFC 1918のプライベートIPv4、CGNATの100.64.0.0/10、ULAのfc00::/7では、プライベートネットワーク経由の配送が自動で有効になり、APIから外せない。公開IPでも私設網経由でしか届かない場合は手動で有効にする。TLS終端、WAF、ルール、キャッシュはこれまで通りCloudflare側で動く。Argo Smart RoutingとDedicated CDN Egress IPは非対応で、オリジンのヘルスチェックにはLoad Balancingが要る。

利用前に、アカウントチームによるPrivate Originsの有効化と、IPsec、GRE、CNI、Cloudflare Tunnel、Cloudflare Meshのいずれかの接続が要る。Tunnel以外はUnified Routingも必要だ。WANまたはMeshでは、戻りの経路に100.64.0.0/12と2606:4700:cf1:5000::/64を入れる。ベータで最も多かった失敗は、タイムアウトなのにオリジンへ何も届かないケースで、原因はこの戻り経路の不足だった。

公開トラフィックを私設オリジンへ届けるところまでが今回の範囲だ。私設網同士の通信は、2027年初めのクローズドベータを目標にしている。社内API、MCPサーバー、エージェントのバックエンドを載せるなら、資格の有効化と戻り経路を先に確認する。既存のWAFとキャッシュは、そのホスト名へ追加設定なしで適用される。