Cloudflare Tunnel 경로 정규화 확대: 세미콜론·Access 규칙을 배포 전에 점검하기

경로와 접근 검증의 경계를 표현한 생성형 개념 이미지다. 실제 Cloudflare 화면이나 네트워크 구조도가 아니다.

Cloudflare Tunnel에서 경로별로 서비스를 나누고 Access 인증을 요구한다면, 이제 세미콜론이 들어간 URL도 배포 전에 점검해야 한다. cloudflared 2026.11.0은 ingress 규칙을 비교하기 전에 세미콜론 경로 매개변수를 제거하는 정규화를 지원한다. 원본 서버로 전달하는 경로를 바꾸는 기능은 아니다.

Cloudflare가 November 12, 2026 발표한 변경이다. 기본 활성화 예정일도 기존 January 25, 2027에서 February 8, 2027 이후 새 릴리스로 바뀌었다. 해당 날짜에 모든 설치본이 자동 변경된다는 뜻은 아니다. 공식 변경 공지

어떤 구성을 점검해야 하는가

이번 변경은 Access 검증을 요구하는 ingress 규칙이 있는 터널의 보안 개선이다. 그런 규칙이 없는 구성은 영향받지 않는다고 공식 공지가 설명한다. 2026.10.0과 2026.11.0에서는 기본적으로 꺼져 있다.

경로를 서비스 선택과 접근 제어의 기준으로 사용하는 운영자는 버전뿐 아니라 실제 실행 옵션까지 확인해야 한다. 여러 복제본을 운영한다면 한 대만 확인해서는 부족하다. 공식 안내의 환경변수 방식은 각 복제본에 적용하고 재시작하는 방식이다.

비교할 경로와 전달할 경로는 다르다

2026.10.0부터 지원한 정규화는 점 구간 제거, 역슬래시 변환, 연속 슬래시 병합을 수행한다. 2026.11.0은 여기에 세미콜론으로 구분한 경로 매개변수 처리를 더한다.

공식 문서의 예를 보면, 정규화가 켜지고 Access 검증 규칙이 있는 터널에서 /hello/../path는 /path로 ingress 규칙을 비교한다. 하지만 원본 서버에는 /hello/../path를 전달한다. ingress 비교·경로 전달 문서

따라서 “정규화를 켰으니 백엔드도 정리된 URL을 받는다”는 가정은 틀리다. 애플리케이션의 라우터가 어떤 경로로 해석하는지 별도로 검증해야 한다. 접두사 제거 또는 URL 재작성 요구사항과도 분리한다.

아래는 운영 점검을 위한 자체 권고다. 같은 요청에 대해 다음 세 가지를 나란히 기록한다.

• 클라이언트가 의도한 요청 경로

• 터널에서 선택한 ingress 규칙과 서비스

• 원본 애플리케이션이 받은 경로와 최종 라우트

이 세 값을 구분하면 “원본 경로는 같은데 왜 서비스가 달라졌는가”를 추적하기 쉽다. 인증 토큰이나 쿠키는 점검 로그에 남기지 않는다.

먼저 테스트 환경에서 명시적으로 켠다

다음은 공식 옵션을 사용한 실행 예시다. 운영 중인 서비스를 그대로 추가 실행하는 명령이 아니다. 테스트용 터널의 이름이나 UUID로 바꾸고, 기존 서비스 관리 방식과 설정 파일을 먼저 확인한다.

옵션 이름에 disable이 들어 있지만 false가 정규화 활성화다. run 앞에 둔다. 환경변수를 사용하는 실행 환경에서는 다음 값을 적용하는 방법도 있다.

설정 문법과 규칙 선택을 살피는 보조 명령은 다음과 같다. 로컬 관리형 터널의 실제 설정 파일을 읽는지부터 확인한다.

첫 명령은 ingress 설정 유효성을 확인한다. 두 번째는 URL과 처음 일치하는 규칙을 확인한다. 이 명령 결과만으로 실제 요청의 Access 인증·원본 도달·정규화 동작 전체를 검증했다고 판단하지 않는다.

배포 전 회귀 테스트

다음은 공식 동작 설명을 토대로 구성한 권장 테스트다. 운영 데이터 대신 별도 테스트 서비스에서 수행한다.

1. 일반 경로와 세미콜론을 포함한 경로를 나눠 같은 목적의 요청을 준비한다. 세미콜론을 업무상 사용하는 서비스는 정상 기능 유지 여부도 확인한다.

2. 점 구간, 반복 슬래시, 역슬래시가 포함된 요청도 비교한다. 클라이언트나 앞단 프록시가 먼저 경로를 바꿀 수 있으므로 실제 터널에 도달한 요청을 기준으로 판단한다.

3. 인증하지 않은 요청과 적절한 인증을 가진 요청을 각각 보낸다. 보호 대상이 원본까지 잘못 전달되지 않는지 확인한다.

4. 각 요청의 선택 서비스, 응답 상태, 원본 경로를 활성화 전후로 비교한다. 예상과 달라진 규칙은 먼저 원인을 분석한다.

5. 복제본별 버전과 옵션을 맞춘 뒤 순차 전환한다. 정상 확인 없이 기존 인스턴스를 한꺼번에 내리지 않는다.

서비스가 정상 응답한다는 사실만으로 보안 점검이 끝나지는 않는다. 거부돼야 하는 요청이 거부되는지가 별도의 완료 조건이다. 이 글에서는 실제 터널 실행이나 배포 변경을 하지 않았다. 명령은 문서에 근거한 예시이며 회귀 테스트는 운영 권고다.

기존의 연결 장애 점검과 달리, 이번 변경에서 핵심은 연결 성공 여부가 아니라 경로 해석과 인증 경계다. 기본값 전환 전에 대표 요청을 테스트로 남겨두면 향후 버전 업그레이드 때 같은 검증을 반복할 수 있다.