CONFIGURATION REFERENCE 공식 매뉴얼 · 체계적으로 살펴보기

Shadowrocket 설정 항목 및 규칙 참고

설정 파일 구조부터 규칙 매칭 결과까지, 항목별 문법과 증상별 원인을 확인합니다. 이 문서는 사용자가 자신의 구독 또는 서버 정보를 이미 보유하고 있다는 전제로 작성했으며, 연결 서비스 획득 방법은 안내하지 않습니다.

시작 가이드에서는 처음 가져오기, Global Routing(전역 라우팅) 선택, 연결 설정을 안내합니다. 이 페이지에서는 각 설정 섹션이 결과에 미치는 영향을 설명하므로 첫 연결을 마친 뒤 참고하기 좋습니다. 처음 사용한다면 먼저 튜토리얼을 완료한 다음 해당 항목으로 돌아와 설정을 변경하세요.

01 / STRUCTURE

설정 파일 구조와 적용 관계

서버 정보, 구독, Config를 구분하세요

서버 정보에는 지정된 서버에 연결하는 데 필요한 프로토콜, 주소, 포트, 인증 매개변수가 담깁니다. Subscribe(구독)는 사용자가 이미 보유한 서버 항목을 가져오고 업데이트하는 기능입니다. Config는 일반 옵션, 도메인 해석, 요청 매칭 및 정책 할당을 담당합니다. 세 가지의 용도는 서로 다릅니다. 구독을 성공적으로 가져왔다고 해서 규칙 파일이 적용된 것은 아니며, 모든 요청이 현재 선택된 서버를 거친다는 뜻도 아닙니다.

설정을 확인할 때는 먼저 Home(홈)에서 현재 사용할 수 있는 서버를 확인하고, Global Routing 모드를 살펴본 뒤, Config에서 실제로 활성화된 파일을 확인하세요. 편집기에서 파일을 열기만 해서는 적용되지 않습니다. 사본을 저장해도 현재 선택 항목이 반드시 바뀌는 것은 아닙니다. 문제를 기록할 때는 이 세 가지 상태를 함께 적어 두세요. 테스트 경로에 따라 같은 규칙의 결과가 달라질 수 있습니다.

대괄호 섹션 이름과 줄별 문법

Shadowrocket의 일반적인 설정 파일은 대괄호로 섹션을 표시합니다. General에는 공통 키와 값, Rule에는 순서대로 검사하는 규칙, Host에는 지정된 호스트 매핑, URL Rewrite에는 URL 재작성 표현식이 들어갑니다. 섹션 이름은 문법의 일부이므로 번역하거나 바꾸지 마세요. 빈 줄은 주로 내용을 구분하는 데 사용합니다. 항목에는 반각 문장 부호를 사용하세요. 한국어 쉼표, 전각 등호, 서식 있는 따옴표를 사용하면 파싱 결과가 예상과 달라질 수 있습니다.

# 설정 구조 예시; 서버 연결 매개변수는 포함하지 않음
[General]
dns-server = system
ipv6 = false

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

[Host]
intranet.example.com = 192.0.2.10

[URL Rewrite]
^http://legacy\.example\.com/(.*) https://www.example.com/$1 302

이 조각은 각 섹션의 배열 방식만 보여 주며, 사용자가 이미 보유한 전체 연결 설정을 대신하지 않습니다. 예시의 도메인과 주소는 문서 설명용입니다. 특히 Host 매핑만으로 내부 서버가 새로 만들어지는 것은 아닙니다. 실제로 합칠 때는 해당 줄을 기존의 같은 이름 섹션에 넣으세요. 파일 끝에 같은 섹션 머리글을 반복해서 추가하거나, 규칙 행을 General의 키·값 목록에 넣지 마세요.

설정 섹션	주요 역할	확인할 항목
`[General]`	일반 동작 및 해석 옵션	키 이름, 값 유형 및 네트워크 조건
`[Rule]`	요청 매칭 및 정책	규칙 순서와 기본 정책
`[Host]`	지정 호스트 주소 매핑	호스트 이름과 주소의 일치 여부
`[URL Rewrite]`	요청 URL 재작성 또는 리디렉션	정규식 범위와 대상 URL

로컬 수정과 원격 업데이트의 범위

설정이 원격 주소에서 제공되는 경우, 업데이트 작업이 어떤 내용을 대체하는지 먼저 확인하세요. 원격 파일을 다시 가져오면 로컬 편집 내용이 덮어써질 수 있으며, 서버 구독 업데이트와 설정 업데이트는 서로 다른 작업일 수 있습니다. 계속 사용할 규칙은 직접 관리할 수 있는 설정 사본에 기록하고 출처도 함께 남겨 두세요. 기억에 의존해 다시 조합하면 업데이트가 몇 차례 진행된 뒤 어떤 규칙이 원본에서 왔고 무엇이 나중에 추가됐는지 확인하기 어렵습니다.

사본에는 ‘일상 설정’, ‘규칙 테스트’처럼 용도를 드러내는 이름을 붙이고, 의미가 불분명한 숫자로 구분하지 마세요. 사본을 만든 뒤에는 내용을 수정하지 않은 상태로 먼저 활성화해 기본 연결 결과가 원본과 같은지 확인하세요. 이후 편집을 시작하면 복사, 전환, 규칙 수정을 나누어 검증할 수 있습니다. 첫 단계부터 결과가 다르다면 설정을 더 추가하기보다 파일 내용과 선택 상태부터 확인하세요.

설정에는 사용자의 서버 정보, 사설 주소 또는 인증 정보가 포함될 수 있습니다. 문제를 공유할 때는 관련 섹션만 남기고 민감한 값은 바꾸되, 쉼표 위치와 키 이름, 항목 순서는 유지하세요. 최종 오류 메시지만으로는 진단에 필요한 정보가 부족한 경우가 많지만, 전체 설정을 공개하면 불필요한 정보가 노출됩니다. 민감한 내용을 가린 최소 설정 조각, 예상 결과, 실제 매칭 기록을 함께 제공하는 것이 가장 효과적입니다.

다른 설정 예시를 참고할 때는 ‘섹션 문법이 올바른지’와 ‘현재 환경에 적합한지’를 구분해야 합니다. 같은 규칙도 DNS, 연결 경로, Global Routing 모드에 따라 결과가 달라질 수 있습니다. 가져오기 전에 각 줄의 용도를 하나씩 확인하고, 설명할 수 없는 줄은 우선 추가하지 마세요. 설정이 복잡할수록 각 옵션이 어떤 관찰 가능한 문제를 해결하는지 명확히 해야 합니다.

02 / GENERAL

General 공통 항목과 DNS 해석

키·값 옵션은 트래픽 분기 규칙이 아닙니다

General은 ‘키 이름 = 값’ 형식으로 공통 동작을 지정하며, 쉼표로 구분하는 Rule과 문법이 다릅니다. 이 섹션을 수정하면 여러 도메인에 영향을 줄 수 있으므로 특정 웹사이트 하나를 고칠 때 가장 먼저 살펴볼 곳은 아닙니다. 접속 문제가 생기면 먼저 DNS 해석 실패인지, 주소에 연결할 수 없는지, 규칙이 잘못 적용된 것인지 확인하세요. 그런 다음 공통 항목을 바꿀 필요가 있는지 판단해야 합니다. 한 번에 여러 설정을 변경하면 정상 동작하던 요청까지 달라질 수 있습니다.

dns-server = system은 시스템이 제공하는 DNS 설정을 사용한다는 뜻입니다. 흐름을 이해하기 위한 출발점으로 적합하지만, 모든 네트워크 환경에서 같은 결과를 보장하지는 않습니다. 네트워크 전환, 시스템 설정, 도메인 자체의 해석 정책에 따라 반환 주소가 달라질 수 있습니다. 사용자가 특정 DNS 서버를 지정해야 한다면 해당 기술 안내를 따르세요. 예시에 주소가 나온다는 이유만으로 현재 네트워크에 적합하다고 판단하지 마세요.

[General]
dns-server = system
ipv6 = false
skip-proxy = 127.0.0.1, localhost

ipv6 = false는 불리언 값 작성 예시이며, 모든 사용자가 IPv6을 끄라는 뜻이 아닙니다. 사용 여부는 현재 네트워크, 서버 지원 여부, 대상 주소를 함께 고려해 결정해야 합니다. 끈 뒤 접속이 성공하더라도 접속 경로가 달라졌다는 점만 확인할 수 있을 뿐, 장애 원인이 입증된 것은 아닙니다. 설정 변경 전후의 DNS 기록을 남겨 도달할 수 없는 IPv6 주소가 반환된 것인지, 연결을 다시 설정하는 과정에서 다른 설정도 달라진 것인지 구분하세요.

도메인과 주소 정보가 확인되는 시점 이해하기

앱이 요청을 보낼 때 클라이언트가 전체 URL, 도메인, 대상 주소를 항상 동시에 파악하는 것은 아닙니다. 도메인으로 연결을 시작하는 요청도 있고 주소를 직접 사용하는 요청도 있으며, 기존 연결에서는 캐시된 결과가 계속 사용될 수 있습니다. 도메인 규칙과 주소 규칙은 필요한 정보가 서로 다릅니다. 문제를 진단할 때는 요청 기록에 실제로 어떤 정보가 있는지 먼저 확인하고, 해당 매칭 방식이 실행될 조건을 갖췄는지 판단하세요.

주소 규칙은 때에 따라 판단 전에 도메인 해석이 필요할 수 있습니다. 규칙 뒤에 no-resolve를 붙이면 해당 주소 규칙을 확인하기 위해 도메인을 추가로 해석하지 않습니다. 클라이언트 전체의 DNS를 끄는 옵션은 아닙니다. 요청 자체에 주소가 이미 포함되어 있다면 그 주소로 매칭할 수 있습니다. 불필요한 해석을 줄이는 데 중요한 차이이며, 같은 주소 규칙이 요청에 따라 다르게 동작하는 이유이기도 합니다.

[Rule]
DOMAIN,portal.example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

위 예시는 명시된 도메인을 먼저 처리한 뒤, 이미 확인된 주소가 문서 전용 네트워크 대역에 속하는지 검사하고, 마지막으로 기본 정책에 넘깁니다. 요청에 도메인만 있고 첫 번째 규칙에 맞지 않는다면 no-resolve가 붙은 주소 규칙은 자체 판단을 위해 추가 조회를 하지 않습니다. 따라서 도메인이 최종적으로 해당 대역의 주소로 해석된다는 이유만으로 이 규칙이 반드시 먼저 적용된다고 단정할 수 없습니다. 실제 요청 정보와 매칭 기록을 기준으로 판단하세요.

skip-proxy와 요청 경로

skip-proxy는 시스템 프록시 단계에서 예외로 처리할 대상을 지정합니다. Rule의 DIRECT와 같은 의미로 사용해서는 안 됩니다. 트래픽이 클라이언트로 들어오는 방식은 서로 다를 수 있으며, 시스템 프록시 예외만으로 완전한 규칙 설계를 대신할 수도 없습니다. 분기 결과를 확인해야 하는 작업이라면 Rule에 조건을 명시하고, 해당 트래픽이 클라이언트가 처리할 수 있는 경로에 있는지 확인하세요.

내부 도메인은 먼저 시스템 네트워크에서 필요한 해석 조건을 제공하는지 확인해야 합니다. 규칙에서 DIRECT를 선택해도 시스템이 올바른 호스트 주소를 알아야 하며, Host에 주소를 지정해도 기기에서 해당 주소까지 도달할 경로가 있어야 합니다. DNS 해석, 정책, 연결 가능성은 서로 이어져 있지만 각각 별개의 단계입니다. 한 항목만 바꿔도 나머지 두 단계가 해결되는 것은 아닙니다.

DNS 결과는 앱, 시스템 또는 클라이언트에 캐시될 수 있습니다. DNS 설정을 바꾼 뒤에는 현재 테스트 페이지를 닫고 새 요청을 시작하세요. 필요한 경우 앱 내 해당 정리 도구를 사용합니다. 캐시를 지우고, 서버를 바꾸고, 규칙까지 동시에 조정하지 마세요. 접속이 복구돼도 어떤 변경이 효과를 냈는지 알 수 없게 됩니다. 재테스트 기록에는 네트워크 유형, 대상 호스트, 해석된 주소, 실제 정책을 포함하세요.

일부 도메인만 실패한다면 공통 옵션을 바로 바꾸기보다 실패 도메인과 정상 도메인을 묶어 비교하세요. 실패한 도메인이 주소로 해석되는지, 반환 주소가 바뀌었는지, 같은 정책으로 처리되는 다른 대상은 접속되는지 확인합니다. DNS 문제는 네트워크를 전환한 뒤 나타나기도 합니다. 변경 전후 상태를 저장해 두면 네트워크 조건이 달라진 것인지, 다른 설정 파일로 바뀐 것인지 파악하는 데 도움이 됩니다.

03 / DOMAIN MATCHING

DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD

전체 도메인과 하위 도메인 범위

DOMAIN은 전체 호스트 이름 하나를 정확히 매칭합니다. 조건에 api.example.com을 지정하면 해당 호스트에만 적용되며, www.example.com이나 더 깊은 하위 도메인까지 자동으로 포함하지 않습니다. 조건에 프로토콜, 포트, 슬래시 또는 URL 경로를 넣지 마세요. 같은 호스트의 서로 다른 페이지를 구분해야 한다면 일반 도메인 규칙으로는 처리할 수 없습니다. 도메인 수준에서 차이가 없기 때문입니다.

DOMAIN-SUFFIX는 지정한 도메인과 그 하위 도메인을 매칭합니다. 조건이 example.com이면 해당 도메인 자체와 api.example.com 같은 하위 도메인을 포함합니다. 임의의 문자열 끝부분을 비교하는 방식이 아니므로 notexample.com까지 포함한다고 이해해서는 안 됩니다. 앞에 별표를 붙일 필요가 없으며, 브라우저 주소창의 URL 표기를 그대로 조건에 붙여 넣지 마세요.

[Rule]
DOMAIN,accounts.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

이 규칙 묶음에서는 계정 호스트가 먼저 정확히 일치하는 예외 규칙에 걸리고, 나머지 example.com 호스트는 하위 도메인 규칙으로 처리됩니다. 하위 도메인 규칙을 첫 줄에 두면 계정 호스트도 먼저 매칭되므로 아래의 정확한 예외가 실행되지 않습니다. 정확한 매칭 조건이 더 좁더라도 파일 순서와 관계없이 자동으로 우선 적용되지는 않습니다. 범위가 넓은 규칙보다 앞에 직접 배치해야 합니다.

키워드 매칭으로 인한 오매칭 범위

DOMAIN-KEYWORD는 도메인에 지정한 키워드가 포함됐는지 확인하므로, 여러 도메인에 걸쳐 같은 문자열을 처리해야 하는 경우에 적합합니다. 도메인의 소유 주체를 파악하거나 단어 경계를 구분하지는 않습니다. 키워드가 너무 짧으면 무관한 호스트도 다수 선택될 수 있습니다. 알고 있는 도메인이 하나 또는 몇 개뿐이라면 범위를 명확히 설명할 수 있는 DOMAIN이나 DOMAIN-SUFFIX를 우선 사용하세요.

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

이 예시에서는 example.com에 대한 예외를 먼저 적용하고, 그 외에 example 문자열이 들어간 도메인을 PROXY로 처리합니다. 순서와 의미를 설명하기 위한 예시이며, 모든 상황에 적용할 일반 권장 규칙은 아닙니다. 키워드를 사용하기 전에 실제 요청 기록에서 포함해야 할 호스트와 제외해야 할 호스트를 정리하고 하나씩 확인하세요. 페이지 하나가 성공했다는 이유만으로 검증을 끝내면 안 됩니다.

유형	조건 예시	적용 범위
`DOMAIN`	`api.example.com`	해당 전체 호스트 이름만 매칭
`DOMAIN-SUFFIX`	`example.com`	기본 도메인과 하위 도메인
`DOMAIN-KEYWORD`	`example`	도메인에 해당 문자열이 포함됨

여러 호스트로 구성된 페이지

브라우저 주소창에 표시된 호스트가 페이지 로딩에 필요한 모든 대상을 포함하지는 않습니다. 이미지, 글꼴, 로그인 인증, API, 동영상 세그먼트는 서로 다른 도메인에서 제공될 수 있습니다. 메인 페이지는 정상인데 일부 콘텐츠만 실패한다면 누락된 리소스의 호스트를 확인한 뒤 규칙 추가 여부를 결정하세요. 최상위 도메인 전체를 같은 정책에 맡기면 간단하지만 영향 범위가 넓어지고 실제로 필요한 조건이 무엇인지 파악하기 어려워집니다.

같은 서비스에서도 외부 저장소나 콘텐츠 전송 호스트를 사용할 수 있으며, 이러한 호스트가 메인 사이트의 도메인 하위에 속하지 않을 수도 있습니다. 사용자의 실제 접속 기록과 서비스 문서를 확인해 관계를 파악하고, 철자가 비슷하다는 이유로 소속을 추정하지 마세요. 여러 앱이 함께 사용하는 공용 리소스 도메인의 정책을 바꾸면 다른 앱에도 영향을 줄 수 있습니다. 필요하다면 더 정확한 예외를 남기고 메인 사이트의 하위 도메인 규칙만으로 처리할 수 없는 이유를 기록하세요.

일부 요청은 사용 가능한 호스트 이름 없이 주소에 직접 연결됩니다. 별칭 해석을 거친 도메인도 규칙 기록에는 원래 요청한 도메인이 표시될 수 있습니다. DNS 조회에서 확인한 별칭만으로 도메인 규칙이 그 별칭과 반드시 매칭된다고 단정하지 마세요. 문제를 진단할 때는 클라이언트 기록의 대상 필드를 기준으로 삼으세요. 기록에 주소만 있다면 주소 규칙과 도메인 정보의 가시성을 추가로 확인해야 합니다.

도메인 규칙을 테스트할 때는 임시 정확 매칭 규칙을 먼저 추가해 테스트 범위를 호스트 하나로 좁힐 수 있습니다. 매칭을 확인한 뒤 하위 도메인 규칙으로 확장하고, 하위 도메인 하나와 무관한 도메인 하나도 테스트하세요. 이 과정에서 문법, 순서, 범위를 각각 확인할 수 있습니다. 테스트가 끝나면 임시 규칙을 삭제해 용도를 잊은 채 넓은 규칙보다 앞에 남겨 두는 일이 없도록 하세요.

도메인 목록을 관리할 때는 설명할 수 없는 하위 도메인을 계속 쌓기보다 각 규칙이 어떤 실제 요구를 위한 것인지 기록하세요. 중복 규칙을 추가해도 안정성이 높아지지는 않습니다. 특히 같은 조건에 서로 다른 정책을 지정한 중복 행은 설정을 읽기 어렵게 만듭니다. 정리할 때는 유효한 첫 규칙을 남기고, 뒤의 중복 항목이 오래된 내용인지 확인하세요. 변경 후에는 로그인, 정적 리소스, API 요청을 다시 테스트합니다.

04 / ADDRESS AND METADATA

IP-CIDR, GEOIP, USER-AGENT

주소 대역과 프리픽스 길이

IP-CIDR은 네트워크 주소와 프리픽스 길이로 IPv4 주소 범위를 나타냅니다. 프리픽스 길이가 길수록 일반적으로 범위가 좁아집니다. 단일 주소에는 32비트 프리픽스를 사용할 수 있습니다. 입력 전에 대상이 단일 호스트인지 전체 네트워크인지 확인하세요. 앞부분 몇 개가 비슷하다는 이유만으로 범위를 넓혀서는 안 됩니다. 로컬 네트워크에 적용한다면 현재 네트워크에 실제로 할당된 주소 대역을 확인해 무관한 원격 주소까지 DIRECT에 포함되지 않도록 하세요.

[Rule]
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

위 주소는 모두 문서 설명용이며 실제 서비스 주소로 사용할 수 없습니다. 첫 번째는 IPv4 주소 하나, 두 번째는 IPv4 네트워크 대역, 세 번째는 IPv6 프리픽스 표기를 보여 줍니다. IP-CIDR6은 IPv6 주소 범위에 사용하며, 콜론이 포함된 주소를 IP-CIDR에 넣지 마세요. 프리픽스는 주소 집합을 나타내며 포트 범위가 아닙니다. 같은 서버의 서로 다른 웹사이트를 구분하는 데도 사용할 수 없습니다.

여러 도메인이 같은 주소를 공유한다면 주소 규칙 하나가 여러 도메인에 동시에 영향을 줄 수 있습니다. 대상 호스트를 알고 있다면 일반적으로 도메인 규칙을 먼저 고려하고, 주소 기준으로 관리해야 하는 작업에만 네트워크 대역 규칙을 사용하세요. 반대로 대상이 고정된 내부 기기이고 요청이 주소를 직접 사용한다면 도메인 규칙으로 주소 규칙을 대신할 수 없습니다. 어느 방식이 더 짧아 보이는지가 아니라 작업을 식별하는 기준에 따라 선택해야 합니다.

GEOIP는 주소의 지역 분류이지 웹사이트의 신원이 아닙니다

GEOIP는 주소 데이터베이스의 지역 분류를 기준으로 판단합니다. 예를 들면 GEOIP,CN,DIRECT와 같습니다. 이 규칙은 대상 주소의 분류를 나타낼 뿐, 도메인 등록 국가나 서비스 제공자의 위치를 나타내지 않습니다. 콘텐츠 전송 네트워크를 사용하는 웹사이트는 네트워크에 따라 서로 다른 주소로 해석될 수 있으며, 데이터베이스 정보가 실제 이용 환경과 다를 수도 있습니다. 따라서 지역 규칙은 범위가 넓은 보조 조건으로 사용하는 것이 적절합니다.

[Rule]
DOMAIN,api.example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

이 예시는 특정 API의 정책을 먼저 지정한 다음 나머지 요청을 지역 조건으로 처리합니다. GEOIP를 앞에 두면 API가 해당 지역으로 분류되는 주소에 연결될 때 정확한 도메인 예외가 실행되지 않을 수 있습니다. 규칙은 여전히 순서대로 평가되며, 뒤에 더 구체적인 도메인 조건이 있다고 자동으로 다시 선택되지 않습니다. 분기 결과가 예상과 다르면 먼저 매칭된 위치를 확인하고, 주소 데이터베이스도 검토해야 하는지 판단하세요.

GEOIP 판단에는 대상 도메인 해석이 필요할 수 있습니다. no-resolve를 붙일지는 이 조건을 위해 해석을 수행할지에 따라 결정하세요. 붙이면 도메인만 있고 사용 가능한 주소가 없는 요청은 다음 규칙으로 넘어갈 수 있습니다. 붙이지 않으면 추가 해석 대기가 발생할 수 있습니다. 어느 한쪽이 모든 네트워크에서 항상 옳은 것은 아닙니다. 실제 기록을 바탕으로 검증해야 합니다.

USER-AGENT 정보의 가시성 제한

USER-AGENT는 요청에서 확인할 수 있는 User-Agent 정보를 기준으로 매칭하며, 앱의 신원을 기준으로 트래픽을 분기하는 기능과 같지 않습니다. 여러 앱이 같은 식별자를 보낼 수 있고, 같은 앱도 요청 유형에 따라 식별자를 바꿀 수 있습니다. 일반적인 암호화 연결에서는 모든 HTTP 요청 헤더가 자동으로 드러나지 않으므로 모든 앱 트래픽을 식별할 수 있다고 기대해서는 안 됩니다. 시스템 수준의 프로세스 선택기로 사용할 수도 없습니다.

[Rule]
USER-AGENT,ExampleClient*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

ExampleClient*는 설명을 위한 패턴입니다. 실제 조건에는 사용자가 요청 기록에서 확인할 수 있는 식별자를 사용해야 합니다. 앱 이름만 보고 User-Agent를 추측하면 실제 값과 브랜드 이름이 다를 수 있어 실패하기 쉽습니다. 요청 기록에 해당 정보가 없다면 확인 가능한 도메인이나 주소 조건을 사용하세요. 정보가 부족한 문제를 해결하려고 와일드카드 범위를 계속 넓히지 마세요.

접근 제어 요구 사항도 USER-AGENT에만 의존해서는 안 됩니다. 이 필드는 요청 메타데이터일 뿐 강력한 인증 정보가 아니며, 같은 대상도 요청마다 다른 값을 보낼 수 있습니다. 특정 호스트를 차단하려는 목적이라면 도메인 조건을 직접 지정하는 편이 검증하기 쉽습니다. 같은 호스트의 서로 다른 작업을 구분하려는 경우에는 클라이언트가 그 차이를 확인할 수 있는지 먼저 살펴보고 규칙 계층에서 처리할지 결정하세요.

주소 및 메타데이터 규칙을 테스트할 때는 기존 연결과 새 연결, 도메인 접속과 주소 직접 접속을 각각 확인하세요. 한 번 매칭됐다는 사실은 해당 요청이 조건을 충족했다는 뜻일 뿐, 비슷한 모든 트래픽도 같다는 뜻은 아닙니다. 기록에 중요한 필드가 없다면 결론을 ‘현재 증거로는 판단할 수 없음’으로 남기세요. 우연한 결과를 넓은 기본 정책으로 고정하기보다 관찰 가능한 규칙을 유지하는 편이 안전합니다.

05 / POLICY AND PRECEDENCE

PROXY, DIRECT, REJECT와 규칙 우선순위

먼저 Global Routing 모드를 확인하세요

Global Routing의 Config, Proxy, Direct는 각각 구성, 프록시, 직접 연결 모드를 나타냅니다. Rule의 개별 트래픽 분기를 확인하려면 Config를 사용하고 실제 활성화된 설정 파일인지 확인하세요. Proxy와 Direct는 해당 전역 모드에 따라 연결을 처리합니다. 이 모드의 테스트 결과로 일반 분기 규칙이 올바른지 판단해서는 안 됩니다. 인터페이스의 Proxy와 규칙 키워드 PROXY는 대소문자와 계층이 다르므로 구분해서 읽으세요.

구분	이름	의미와 확인 항목
Global Routing	`Config`	현재 설정에 따른 규칙 매칭 확인
Global Routing	`Proxy / Direct`	전역 모드이며 규칙 행과는 다름
Rule 정책	`PROXY`	현재 프록시 선택에 맡겨 처리
Rule 정책	`DIRECT`	로컬 네트워크를 통해 직접 연결
Rule 정책	`REJECT`	매칭된 요청 거부

PROXY는 규칙에서 서버를 정의하는 것이 아니라 현재 사용할 수 있는 프록시 선택을 참조합니다. 서버 매개변수가 잘못됐거나 인증에 실패했거나 서버에 연결할 수 없으면 규칙이 올바르게 매칭돼도 요청은 실패합니다. DIRECT도 기기의 모든 시스템 네트워크 조건을 우회한다는 뜻은 아닙니다. 현재 네트워크, DNS, 대상 서비스 상태의 영향을 받습니다. REJECT는 명시적으로 요청을 거부하므로 원인을 모르는 장애를 진단할 때 기본 시험값으로 사용해서는 안 됩니다.

첫 번째 매칭과 명시적 예외

Rule은 일반적으로 위에서 아래로 검사하며, 먼저 조건에 맞는 규칙이 해당 요청의 정책을 결정합니다. 도메인 길이, 유형 이름, 작성 시점을 기준으로 규칙을 다시 정렬하지 않습니다. 설정은 ‘정확한 예외, 업무 도메인, 주소 보완, 최종 기본값’ 순으로 구성하면 추론하기 쉽습니다. 다만 이는 이해를 돕기 위한 구성이지 반드시 따라야 할 고정 목록은 아닙니다. 각 규칙이 현재 위치에 있어야 하는 이유를 설명할 수 있어야 합니다.

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,blocked.example.net,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY

로그인 호스트가 첫 번째 규칙에 매칭되면 example.com 하위 도메인 규칙에서 정책을 다시 결정하지 않습니다. 다른 example.com 하위 도메인은 두 번째 규칙까지 내려가 매칭됩니다. 명시된 거부 대상은 세 번째 규칙으로 처리되고, 나머지 요청만 지역 조건에 도달합니다. 설정을 읽을 때는 관련 있어 보이는 한 줄만 따로 보지 말고, 구체적인 호스트 하나를 정해 첫 줄부터 차례대로 확인하세요.

세 번째 규칙의 거부 대상이 그보다 앞선 넓은 DIRECT 규칙에도 포함되면 REJECT 조건이 실행되지 않을 수 있습니다. 같은 REJECT를 반복해서 적어도 이 충돌은 해결되지 않습니다. 규칙의 위치를 바꾸거나 앞선 조건의 범위를 좁혀야 합니다. 적용되지 않는 규칙을 삭제하기 전에는 설명을 위해 남겨 둔 항목인지도 확인하세요. 실제로 쓸 수 없는 규칙이라면 서로 모순되는 활성 규칙을 남기는 것보다 주석으로 설명하는 편이 명확합니다.

FINAL은 기본 규칙이지 자동 복구 기능이 아닙니다

FINAL에는 도메인 조건이 필요하지 않습니다. 기본 형식은 FINAL,PROXY 또는 FINAL,DIRECT입니다. 앞선 규칙에 매칭되지 않은 요청을 처리하므로 규칙 맨 끝에 두세요. 중간에 FINAL을 두면 뒤에 있는 일반 규칙이 예상대로 실행되지 않습니다. 설정을 확인할 때 FINAL의 개수를 검색하고, 일반적으로 명확한 최종 정책 하나만 남기세요. 서로 다른 용도를 표현하려고 기본 규칙을 여러 개 두지 마세요.

기본값은 실제 사용 목적과 현재 연결 조건을 고려해 선택해야 합니다. FINAL을 PROXY로 설정하면 분류되지 않은 요청을 프록시 선택에 맡깁니다. DIRECT로 설정하면 분류되지 않은 요청을 현재 네트워크로 직접 연결합니다. 어느 쪽도 대상에 반드시 연결된다고 보장하지 않습니다. 특정 작업 하나에서 문제가 생겼다면 기본값을 번갈아 바꾸며 시험하기보다 근거가 있는 정확한 예외를 추가하세요.

# 정확한 예외는 이를 포함하는 넓은 규칙보다 앞에 둬야 함
[Rule]
DOMAIN,health.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

위 예시를 테스트할 때는 상태 확인 호스트, 다른 example.com 하위 도메인, 전혀 무관한 도메인을 최소한 확인하세요. 이 세 요청으로 예외, 하위 도메인 규칙, 기본값을 각각 검증할 수 있습니다. 첫 번째 유형만 테스트하면 FINAL이 잘못 변경된 사실을 놓칠 수 있고, 메인 사이트만 확인하면 정확한 예외가 넓은 규칙에 가려진 것을 발견하지 못할 수 있습니다. 규칙 검증은 성공 경로 하나만 확인하지 말고 경계 조건까지 포함해야 합니다.

On Demand(필요 시 연결)는 해당 네트워크 조건에서 연결을 설정할지 결정하며, Rule을 대신해 요청 정책을 결정하지 않습니다. 연결이 자동으로 설정된 뒤에도 현재 Global Routing과 Config를 확인해야 합니다. 네트워크를 바꾼 뒤 결과가 달라졌다면 연결이 다시 설정됐는지, 설정 파일이 같은지, DNS가 달라졌는지 각각 확인하세요. On Demand가 켜져 있다는 이유만으로 모든 요청이 예상한 경로를 사용한다고 단정할 수 없습니다.

정책 매칭과 작업 성공은 따로 확인해야 합니다. 매칭 기록은 분류 로직을 증명하고, 대상 응답은 현재 연결 경로가 작동하는지 보여 줍니다. 둘 다 확인해야 합니다. 실패가 발생하면 다음 단계로 넘어가기 전에 ‘정책을 잘못 선택했는지’와 ‘정책은 맞지만 연결이 실패했는지’를 구분하세요. 처음 연결할 때 자주 묻는 내용은 질문과 답변에서 확인하세요. 계정 권한이나 서버 인증 문제를 규칙 우선순위 문제로 오해하지 않도록 합니다.

06 / HOST AND URL REWRITE

Host 매핑과 URL Rewrite의 적용 범위

Host는 주소 매핑을 바꾸지만 웹사이트의 신원은 바꾸지 않습니다

Host는 지정한 호스트에 정적 주소를 매핑하며, 대상 주소를 사용자가 명확히 알고 있는 통제된 환경에서 주로 사용합니다. 내부 기기를 자동으로 찾아 주거나 해당 주소에 연결할 수 있음을 보장하지는 않습니다. 설정 전에 정확한 주소를 확보하고 대상 호스트가 해당 주소에서 실제 서비스를 제공하는지 확인하세요. 임의로 접속 가능한 주소를 넣으면 요청이 잘못된 대상으로 전달될 뿐이며, DNS 문제를 해결하는 방법이 아닙니다.

[Host]
portal.example.com = 192.0.2.20
files.example.com = 192.0.2.21

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN,files.example.com,DIRECT
FINAL,PROXY

여기서 Host는 주소를 지정하고 Rule은 정책을 지정하므로 서로 다른 단계를 설명합니다. 주소 예시는 문서 전용 대역을 사용했으며, 실제로 사용하려면 사용자 환경에 유효한 값으로 바꿔야 합니다. 대상 주소가 특정 네트워크에서만 연결된다면 기기가 그 네트워크를 벗어난 뒤에는 정적 매핑이 남아 있어도 연결이 실패할 수 있습니다. 이때는 같은 이름의 매핑을 계속 추가하기보다 연결 경로를 확인하세요.

HTTPS를 사용할 때는 원래 도메인이 웹사이트 신원 확인에 계속 사용됩니다. Host에서 도메인을 다른 주소에 연결해도 인증서가 자동으로 올바르게 바뀌지 않으며, 요청의 호스트 신원도 해당 주소로 바뀌지 않습니다. 인증서 이름이 일치하지 않는다면 매핑 대상과 서버 설정을 확인하세요. 인증서 검증을 끄는 방식은 정상적인 해결책으로 사용하지 마세요. 정적 매핑은 대상 서비스가 이전된 뒤에도 반드시 다시 확인해야 합니다.

Host 매핑과 캐시가 함께 관찰 결과에 영향을 줄 수도 있습니다. 변경한 뒤에도 예전 주소로 연결된다면 기존 연결을 종료하고 앱에 캐시가 있는지 확인하세요. 새 요청이 새 매핑을 사용하는 것을 확인한 뒤에야 효과를 평가할 수 있습니다. 원래 DNS 해석으로 되돌리려면 테스트 매핑을 삭제하고 새 요청을 시작하세요. 같은 호스트에 서로 경쟁하는 값을 계속 추가하는 것보다 추적하기 쉽습니다.

URL Rewrite는 URL 표현식을 매칭합니다

URL Rewrite는 정규식으로 요청 URL을 식별하고 설정에 따라 재작성하거나 리디렉션합니다. 도메인 분기와는 다른 기능입니다. 도메인 규칙은 정책을 정하고, 재작성 규칙은 대상 표현식을 바꿉니다. 특정 호스트를 DIRECT로 연결하려는 목적이라면 URL 재작성을 사용할 필요가 없습니다. 통제된 URL 이동이나 경로 조정 같은 요구가 실제로 있을 때만 이 섹션을 추가하세요.

[URL Rewrite]
^http://legacy\.example\.com/(.*) https://www.example.com/$1 302

예시에서는 기존 호스트의 HTTP URL을 새 호스트로 리디렉션하면서 캡처한 나머지 내용을 유지합니다. 맨 앞의 삽입 기호는 시작 위치를 제한하고, 백슬래시는 도메인의 점을 문자 그대로 매칭하게 합니다. 괄호는 캡처 그룹을 만들며, 대상 URL의 달러 기호와 숫자는 해당 그룹을 참조합니다. 마지막의 302는 임시 리디렉션을 뜻합니다. 문법 설명용 예시이며 대상 도메인은 실제 이용 가능한 서비스가 아닙니다.

시작 위치 조건을 생략하거나 점을 이스케이프하지 않으면 정규식 매칭 범위가 넓어집니다. 정규식에서 점은 보통 임의의 문자를 의미하며 일반적인 도메인 구분점이 아닙니다. 편집 전에 비슷한 URL 몇 개로 확인하세요. 기존 호스트는 매칭되고 다른 호스트는 매칭되지 않아야 하며, 이미 새 호스트인 URL도 다시 매칭되면 안 됩니다. 범위가 좁을수록 예상한 요청에만 재작성이 적용되는지 확인하기 쉽습니다.

리디렉션, 암호화, 순환 여부 확인

클라이언트가 확인할 수 있는 URL 정보는 실제 요청 경로와 암호화 상태에 따라 달라집니다. URL Rewrite를 추가했다고 해서 임의의 HTTPS 경로를 읽을 수 있는 것은 아닙니다. 터널 안에서 호스트 정보만 보이는 경우 전체 경로를 사용하는 표현식은 실행 조건을 갖추지 못할 수 있습니다. 정보가 보이고 범위가 제한된 요청으로 먼저 검증하세요. 경로 문제 하나를 해결하려고 인증서 신뢰 범위나 검사 범위를 임의로 넓히지 마세요.

리디렉션이 발생하면 앱은 새 대상에 후속 요청을 보내야 하며, 새 대상도 현재 분기 설정에 부합하고 접속 가능해야 합니다. 기존 대상의 규칙이 올바르다고 새 대상의 정책도 같다는 뜻은 아닙니다. 새 호스트가 요청을 다시 이전 호스트로 보내면 순환이 발생할 수 있으며, 브라우저에는 리디렉션이 너무 많다는 메시지가 표시될 수 있습니다. 이때 각 이동의 출발지와 대상을 확인하고 서버 동작과 로컬 규칙이 서로 영향을 주는지 살펴보세요.

영구 리디렉션은 클라이언트에 캐시될 수 있습니다. 따라서 검증 단계에서는 통제 가능한 임시 리디렉션을 먼저 사용하고, 확인을 마친 뒤 작업 요구 사항에 따라 최종 방식을 결정하는 편이 좋습니다. 로컬 규칙을 삭제해도 앱 캐시 때문에 테스트 결과가 잠시 그대로일 수 있습니다. 새 요청 경로를 사용하고 실제 리디렉션 경로를 기록하세요. 주소창에 최종 표시된 주소만으로 규칙이 아직 실행 중인지 판단하지 마세요.

쿼리 매개변수에 인증 정보나 작업 상태가 포함될 수 있으므로 구조를 파악하지 않은 채 임의로 삭제하거나 이어 붙이지 마세요. 캡처 표현식이 쿼리 부분을 유지하는지는 구체적인 사례로 확인해야 합니다. 경로의 특수 문자는 이스케이프 처리 방식에 따라 결과가 달라질 수 있습니다. 로그인, 결제, 양식 제출처럼 민감한 흐름에서는 서비스가 자체적으로 설계한 리디렉션 방식을 우선 따르세요. 단순 GET 요청 테스트 결과를 모든 요청 방식에 적용해서는 안 됩니다.

07 / COMPOSITION

자주 쓰는 규칙 조합, 병합, 설정 관리

설명할 수 있는 최소 규칙부터 시작하세요

규칙 집합을 만들기 전에 요구 사항을 자연어로 명확히 적으세요. 예를 들면 ‘계정 호스트는 직접 연결하고, 나머지 업무 하위 도메인은 현재 프록시를 사용하며, 그 외 요청은 직접 연결한다’와 같습니다. 그런 다음 각 요구를 해당 조건으로 바꾸세요. 새 규칙이 실제로 필요한지 판단할 수 있고, 테스트에 실패해도 더 넓은 조건을 추가해 기존 충돌을 덮기보다 원래 요구부터 다시 살펴볼 수 있습니다.

[Rule]
# 계정 호스트 예외
DOMAIN,accounts.example.com,DIRECT

# 업무 도메인
DOMAIN-SUFFIX,example.com,PROXY

# 사용자가 확인한 거부 대상
DOMAIN,blocked.example.net,REJECT

# 기타 요청
FINAL,DIRECT

이 규칙 조합은 항목별로 확인하기 쉽도록 짧게 구성했습니다. 서버 주소나 구독 내용은 포함하지 않으며, 사용자가 이미 이용 가능한 연결 정보를 갖고 있어야 합니다. 업무 대상을 추가할 때는 대상 호스트를 확인한 뒤 정확 매칭과 하위 도메인 매칭 중 적절한 방식을 선택하세요. 페이지 하나가 로드되지 않는다는 이유로 확인하지 않은 도메인을 여러 개 추가하면 나중에 어떤 규칙이 실제로 처리에 관여했는지 파악하기 어렵습니다.

규칙 병합 시 의미 충돌을 처리하세요

두 설정 파일을 병합할 때는 텍스트를 앞뒤로 이어 붙이는 것만으로는 충분하지 않습니다. 각 파일의 섹션을 먼저 확인하고 같은 유형의 내용을 해당 섹션에 모은 뒤 규칙 순서와 FINAL을 점검하세요. General에서 같은 키에 서로 다른 값이 있거나, Host에서 같은 호스트에 다른 주소가 있거나, Rule에서 같은 조건에 다른 정책이 지정된 경우에는 어느 쪽을 유지할지 직접 판단해야 합니다. 불명확한 중복 적용 동작에 맡기지 마세요.

도메인 하위 도메인 규칙과 정확 도메인 규칙 사이에 숨은 충돌이 생길 수도 있습니다. 한 설정에서 example.com 전체를 PROXY로 보내고 다른 설정에서 그 안의 특정 API를 DIRECT로 지정했다면 단순한 중복이 아닙니다. 정확한 예외를 넓은 규칙보다 앞에 둬야 합니다. 병합할 때는 같은 기본 도메인 주변의 모든 항목을 검색해 더 넓은 하위 도메인 또는 키워드 규칙이 이미 먼저 적용되는지 확인하세요.

# 병합 후 순서: 예외를 먼저, 넓은 조건은 나중에
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

원본 파일에 사용자 정의 정책 이름이 있다면 옮긴 뒤 대상 설정에도 같은 이름이 정의되어 있는지, 대소문자가 일치하는지 확인해야 합니다. 이 페이지에서는 기본 의미를 설명하기 위해 PROXY, DIRECT, REJECT를 사용합니다. 그렇다고 익숙하지 않은 정책 이름을 모두 바로 사용할 수 있다는 뜻은 아닙니다. 알 수 없는 참조가 있다면 어떤 서버 선택이나 정책 그룹을 가리키는지 먼저 확인한 뒤 유지 여부를 결정하세요.

변경 기록과 업데이트 범위를 관리하세요

변경할 때마다 대상, 수정한 행, 검증 결과를 기록하세요. 주석은 독립된 줄에 두고 업무 목적과 예외 사유를 간단히 적으면 됩니다. 임시 진단 규칙은 특히 해제 조건을 표시하세요. 그렇지 않으면 테스트를 몇 차례 진행한 뒤 잊어버려 보이지 않는 우선순위를 만들 수 있습니다. 규칙을 정리할 때는 주석 내용이 실제 정책과 여전히 일치하는지도 확인하세요. 오래된 주석은 설명이 없는 경우보다 설정을 관리하기 어렵게 만듭니다.

원격 설정을 업데이트하기 전에 로컬 사본을 백업하고 파일을 정상적으로 가져왔는지만 확인하지 말고 주요 섹션을 비교하세요. 원본에서 기본 정책이 바뀌거나 넓은 범위의 규칙이 추가되거나 DNS 옵션이 변경되면 로컬 예외에도 영향을 줍니다. 로컬 내용을 다시 병합해야 한다면 규칙의 의미와 위치를 확인하세요. 이전 예외를 파일 맨 끝에 그대로 붙이면 FINAL 뒤에 놓여 적용되지 않을 수 있습니다.

구독 업데이트는 주로 기존 서버 항목과 관련된 작업이며, 규칙 동기화를 대신하는 통합 기능으로 이해해서는 안 됩니다. 업데이트 후 프록시 경로에 문제가 생기면 현재 선택된 서버가 여전히 유효한지, 인증 매개변수가 바뀌었는지, 기존 항목이 대체됐는지 확인하세요. 규칙이 여전히 PROXY에 매칭돼도 다른 연결 선택을 가리키면 결과가 달라질 수 있습니다. 이런 문제는 도메인 규칙 순서를 조정해 해결할 수 없습니다.

설정 백업과 서버 인증 정보는 보관 범위를 구분해야 합니다. 내보낸 파일에는 연결 매개변수가 포함될 수 있고, 별도로 저장한 서버 목록이 있어야 사용할 수 있는 경우도 있습니다. 기기를 바꾼 뒤 파일 이름이 같다는 이유만으로 내용이 완전하다고 판단하지 마세요. 구체적인 준비 및 복원 절차는 설정 백업 및 새 기기로 복원하기에서 확인하고, 이전 기기를 사용할 수 있을 때 복원 결과를 한 번 확인하세요.

규칙이 늘어나면 주기적으로 정리해야 합니다. 한 번도 매칭되지 않았거나 용도를 알 수 없거나 더 넓은 조건에 이미 포함된 항목은 테스트 사본에서 먼저 비활성화해 관찰한 뒤 삭제 여부를 결정하세요. 목표는 행을 최소화하는 것이 아니라 모든 활성 규칙의 필요성을 설명할 수 있도록 하는 것입니다. 가능한 모든 유형을 설정에 추가하기보다 정상적인 작업을 안정적으로 유지하는 편이 관리하기 쉽습니다.

프로토콜 연결 매개변수와 규칙 정책도 따로 관리해야 합니다. 예를 들어 WireGuard의 키와 주소는 연결 설정에 영향을 주고, DOMAIN-SUFFIX는 어떤 대상을 해당 프록시 선택에 맡길지 결정합니다. 서로 다른 계층의 문제입니다. 항목 입력 방법은 WireGuard 설정 입력 안내에서 확인하세요. 인증 오류를 해결하려고 업무 도메인 매칭 범위를 계속 넓히지 마세요.

08 / VERIFICATION

규칙 검증, 장애 진단, 복구 확인

반복할 수 있는 테스트 조건을 준비하세요

유효한 테스트에는 명확한 대상 호스트, 예상 정책, 고정된 네트워크, 분명한 설정 상태가 필요합니다. 먼저 Config 모드를 확인하고 활성화된 파일과 현재 서버를 기록한 다음 새 요청을 시작하세요. 테스트 중에는 구독을 업데이트하거나 네트워크를 바꾸지 마세요. 조건이 계속 바뀌면 결과가 우연히 성공하더라도 규칙 수정이 원인이라고 증명하기 어렵고 이후 관리에 적용할 결론도 내릴 수 없습니다.

변경할 때마다 세 종류의 테스트 대상을 정하는 것이 좋습니다. 규칙에 매칭돼야 하는 대상, 예외로 처리돼야 하는 대상, 영향을 받지 않아야 하는 대상을 각각 확인하세요. 규칙, 정책, 실제 결과를 기록합니다. 하위 도메인 규칙을 추가한다면 기본 도메인, 하위 도메인, 비슷해 보이지만 해당 하위 도메인에 속하지 않는 도메인을 최소한 포함하세요. 주소 규칙이라면 범위 안팎의 주소를 각각 확인해 성공 사례만 검증하지 않도록 합니다.

관찰된 증상	우선 확인할 항목	다음 단계
예상한 규칙이 매칭되지 않음	파일, 모드, 요청 필드	앞선 넓은 규칙과 새 요청 확인
PROXY에 매칭되지만 요청 실패	서버 연결 및 인증	연결 경로와 대상 서비스 문제 구분
DIRECT에 매칭되지만 요청 실패	로컬 DNS 해석과 네트워크 경로	반환 주소와 도달 가능한 범위 확인
메인 페이지는 정상인데 리소스가 실패함	리소스의 실제 호스트	의존 요청을 하나씩 확인
수정 후에도 결과가 달라지지 않음	캐시와 기존 장기 연결	새 요청을 시작하고 파일을 확인

미매칭과 매칭 후 실패를 먼저 구분하세요

매칭되지 않았다면 먼저 대상에 규칙이 필요로 하는 정보가 실제로 있는지 확인하세요. 도메인 조건은 주소만 있는 요청에 적용할 수 없고, USER-AGENT 조건은 보이지 않는 요청 헤더와 매칭될 수 없습니다. 다음으로 Rule 위에서부터 내려가며 앞선 하위 도메인, 키워드, 지역 조건 또는 FINAL이 있는지 확인하세요. 마지막으로 반각 문장 부호, 정책 이름 표기, 해당 행이 올바른 섹션에 있는지 점검합니다.

규칙에 매칭됐는데 접속에 실패하면 근거 없이 규칙 위치를 바꾸지 마세요. PROXY 분기는 현재 서버가 연결을 설정할 수 있는지, 인증 정보가 유효한지, 대상 서비스에 연결할 수 있는지 확인합니다. DIRECT 분기는 로컬 네트워크에서 해석된 주소에 접속할 수 있는지 확인하세요. 대상 하나만 실패한다면 먼저 대상 간 차이를 비교하고, 같은 정책의 모든 요청이 실패한다면 해당 정책이 공유하는 연결 조건을 살펴보세요.

Connectivity Test(연결 테스트)는 특정 테스트 조건에서의 결과를 제공하지만, 각 실제 요청의 검증을 대신하지 않습니다. 테스트 대상 하나가 응답한다고 해서 로그인 API, 동영상 리소스 또는 다른 프로토콜 요청도 성공한다는 뜻은 아닙니다. 테스트 결과는 원인 범위를 좁히는 증거로 활용하고 실제 실패 요청과 함께 판단하세요. 하나의 수치만으로 전체 설정을 평가해서는 안 됩니다.

캐시, 장기 연결, 네트워크 전환 처리

설정 변경이 이미 설정된 모든 연결에 즉시 새 정책을 적용하는 것은 아닙니다. 브라우저의 연결 재사용, 앱의 백그라운드 전송, 미디어 연속 재생은 이전 상태를 유지할 수 있습니다. 검증하려면 해당 세션을 직접 종료하고 새 요청을 시작하세요. 필요한 경우 클라이언트 연결도 다시 설정합니다. 기존 페이지가 계속 재생된다는 사실은 기존 연결이 작동한다는 뜻일 뿐 새 규칙이 이후 연결에 적용됐다는 증거는 아닙니다.

Wi-Fi에서 셀룰러 네트워크로 전환하면 DNS 서버, 연결 가능한 주소, 연결 상태가 함께 바뀔 수 있습니다. 기존 네트워크에서 접속되던 내부 호스트가 전환 후 실패해도 규칙 문제라고 단정할 수 없습니다. On Demand가 연결을 설정했는지, Global Routing 모드가 유지됐는지, 대상이 기존 네트워크 경로에 의존하는지 다시 확인한 다음 네트워크별로 설정을 분리할 필요가 있는지 판단하세요.

Data(트래픽 통계)는 지정된 기록 범위의 전송량을 나타내며, 규칙이 매칭됐다는 직접적인 증거는 아닙니다. 특정 서버에 트래픽이 표시돼도 현재 테스트 대상이 반드시 그 서버를 통과했다는 뜻은 아닙니다. 캐시된 요청은 새 트래픽이 눈에 띄게 추가되지 않을 수도 있습니다. 통계 기준과 읽는 방법은 트래픽 통계 안내에서 확인하세요. 트래픽 분기 검증은 요청별로 진행해야 합니다.

최소 재현과 안전한 복구

복잡한 문제는 테스트 사본에서 설정을 단계적으로 줄여 확인할 수 있습니다. 필요한 General 항목, 대상 규칙 하나, FINAL 하나만 남기고 관련 없는 Host와 URL Rewrite는 잠시 제거하세요. 내용 한 묶음을 제거할 때마다 같은 테스트를 반복해 차이를 확인합니다. 일상적으로 사용하는 설정에서 모든 섹션을 한꺼번에 비우지 마세요. 기준 상태를 잃으면 원래 정상적으로 작동하던 동작까지 복구하기 어려워집니다.

# 단일 대상을 분리해 확인하기 위한 규칙 섹션; 전체 연결 설정이 아님
[Rule]
DOMAIN,api.example.com,PROXY
FINAL,DIRECT

최소 규칙이 예상대로 매칭되면 기존 내용을 한 묶음씩 복원하며 차이가 처음 나타나는 위치를 찾으세요. 최소 규칙도 매칭되지 않는다면 다른 규칙을 더 병합하지 말고 활성화 상태와 요청 필드를 다시 확인해야 합니다. 단계마다 변수 하나만 바꾸면 파일 미활성화, 앞선 조건의 적용, 정책 경로 장애를 구분할 수 있어 불필요한 반복 테스트를 줄일 수 있습니다.

추가 문의가 필요하다면 민감한 정보를 가린 관련 섹션, 실제 호스트, 매칭된 정책, 네트워크 조건, 재현 절차를 제공하세요. 전체 구독 주소, 키, 인증 항목을 공개하지 마세요. 더 이상 원인을 찾기 어렵다면 검증된 백업을 복원하고 기존 작업이 정상으로 돌아왔는지 확인한 다음 다음 테스트를 준비하세요. 가져오기와 첫 권한 확인은 시작 가이드를 참고하고, 구입 확인 및 구입 항목 복원은 구입 항목 복원 안내를 확인하세요.