Cloudflare Tunnel 경로 정규화, 원본 서버 URL도 바뀔까?

/hello/../path를 매칭해도 원본 경로를 다시 쓰지는 않는다

Cloudflare Tunnel의 새 정규화는 라우팅 규칙 선택을 위한 기능이다. 공식 구성 문서는 cloudflared에 도착한 경로, 규칙과 비교하는 경로, 원본 서버로 전달하는 경로를 다음처럼 구분한다.

도착한 경로	규칙 매칭에 사용	원본 서버로 전달
/hello/../path	/path	/hello/../path
/hello//path	/hello/path	/hello//path
/hello\path	/hello/path	/hello\path

정규화를 켜면 같은 요청이 이전과 다른 규칙에 연결될 수 있다. 그러나 원본 앱이 받는 경로까지 정규화된 값으로 교체하는 기능은 아니다. 위 표는 cloudflared에 도착한 시점부터의 동작이며, 앞단의 별도 URL 변환 설정과 구분해야 한다.

Access 검증 규칙이 있는 구성에서 동작한다

Access 원본 매개변수는 cloudflared가 요청을 전달하기 전에 Access JWT를 검증하도록 한다. 새 정규화는 이런 검증을 요구하는 규칙이 있는 터널을 대상으로 하며, .과 .. 경로를 정리하고 역슬래시를 슬래시로 바꾸며 반복된 슬래시를 합친다.

정규화는 보호 규칙에 도달한 뒤에만 적용되는 것이 아니다. cloudflared의 규칙 선택 구현은 Access 검증 규칙이 있는지 확인하고, 첫 매칭 규칙을 찾기 전에 경로를 정규화한다. 앞쪽의 일반 규칙이 보호 대상 경로로 향하는 요청을 먼저 가져가는 상황을 막기 위한 순서다.

따라서 운영자는 보호 규칙 한 줄만 볼 것이 아니라 같은 호스트의 일반 경로와 규칙 순서도 함께 대조해야 한다. Access 검증을 요구하는 규칙이 없는 구성에는 이번 변경이 영향을 주지 않는다.

disable 옵션을 false로 해야 정규화가 켜진다

실행 매개변수 문서에 따르면 이 기능에는 cloudflared 2026.10.0 이상이 필요하다. disable-path-normalization은 이름 그대로 정규화를 끄는 옵션이므로, false를 지정해야 켜진다.

cloudflared tunnel --disable-path-normalization=false run YOUR_TUNNEL

YOUR_TUNNEL은 기존 터널의 이름이나 UUID로 바꾼다. 서비스로 운영한다면 각 replica의 실행 환경에 TUNNEL_DISABLE_PATH_NORMALIZATION=false를 적용하고 재시작하는 방법도 있다. 일부 replica만 다른 값으로 두지 않도록 실행 설정을 맞춰야 한다.

10월 22일 공지는 현재 기본값이 꺼짐이며, 2027년 1월 25일부터 나오는 새 릴리스에서 기본으로 켤 예정이라고 밝혔다. 기존 설치본 전체가 그날 자동 전환된다는 의미는 아니다.

전환 전에는 운영 중인 정상 URL과 점 경로·중복 슬래시가 있는 URL을 각각 요청했을 때 어느 서비스로 연결되고 Access 검증을 거치는지 대조한다. 규칙 매칭 결과와 원본 앱이 받은 경로를 함께 보면 정규화와 앱 내부 라우팅의 차이를 찾을 수 있다.

/api를 떼고 전달하려면 별도 재작성 규칙이 필요하다

정규화 옵션은 경로 접두사를 없애는 설정이 아니다. 예를 들어 /api/users가 /api 규칙과 일치하더라도 원본에는 전체 경로가 전달된다.

앱이 /users를 받아야 한다면 URL Rewrite Rules 같은 별도 재작성 기능이 필요하다. 이 기능은 URI 경로나 쿼리를 바꾸며, 브라우저 주소를 바꾸는 redirect와도 다르다. 먼저 필요한 변화가 ‘어느 규칙을 고르는가’인지 ‘앱에 어떤 경로를 보내는가’인지 정하면 사용할 설정이 분명해진다.