Cloudflare Tunnel: URL 正規化を先に有効にしてパス単位のルーティングを確かめる（2027-01-25 から既定でオン）
cloudflared 2026.10.0 から、ingress ルールと照合する前に URL を正規化できるようになった。あわせて、特定のトンネルだけ「閲覧 + ログ配信」を許すロールが GA になった。
どんなときに効くか
- ingress ルールをパス（
path:）で分けていて、その一部に「オリジン側で Access の JWT を検証する」設定（access/ Access validation）を付けているトンネル - 正規化しないと、
/admin/../publicや%2e%2eのような書き方で、Access 検証付きのルールを避けて別ルールに当たる余地がある。正規化はそれを塞ぐためのもの - オリジンに送るパス自体は変わらない（変わるのは「どのルールに当たるか」の判定だけ）
やり方
今は既定でオフ。オンにするにはフラグか環境変数を使う。
bash
# フラグで有効化
cloudflared tunnel --disable-path-normalization=false run <TUNNEL_NAME_OR_UUID>
# もしくは各レプリカに環境変数を入れて再起動
TUNNEL_DISABLE_PATH_NORMALIZATION=false- ステージングのトンネル（または 1 レプリカ）で有効化する
- パスで分けているルールごとに、
..・//・パーセントエンコードを含む URL を投げて、期待どおりのルール（とサービス）に当たるか確認する - 問題なければ全レプリカに入れる。2027-01-25 以降の新しい cloudflared では既定でオンになるので、それまでに済ませる
Access 検証を使うルールがない構成は影響を受けない。
おまけ: 調査担当にだけ渡せる「Read And Monitor」ロール
「Cloudflare Tunnel - Granular Connector cloudflared Read And Monitor」ロールが GA。指定したトンネルだけについて、ルート（IP・ホスト名）やコネクタのホスト情報の閲覧に加えて、リモートのログ配信（cloudflared のログを手元にストリームする機能）まで許可できる。書き込み権限は付かない。既存の Read ロールにはログ配信が含まれないので、サポートや調査を頼む相手にはこちらを使う。
注意点
- 既定オン化はリリース単位で入る。cloudflared を自動更新している環境では、2027-01-25 以降のリリースで挙動が変わる前提で検証しておく
- 正規化の細かいルールは公式の「ingress matching」「Access validation at the origin」のページを確認する