OFFICIAL MANUAL / RULE REFERENCE

Shadowrocket 규칙 가이드

구성 섹션, 매칭 순서, 트래픽 분기 정책

이 페이지는 Shadowrocket 공식 가이드의 상세 참고 자료입니다. 구독 정보나 서버 정보를 보유하고 연결을 설정한 뒤, 규칙이 요청에 미치는 영향을 확인할 때 참고하세요. 처음 가져오기와 연결 설정은 먼저 사용 설명서를 읽어 보세요. 기본 사용법을 익힌 다음 이 페이지의 각 장에서 구성을 점검할 수 있습니다.

  • 구성 예제를 항목별로 설명
  • 규칙은 첫 번째 일치 항목으로 판단
  • 예시 주소는 설명용입니다

구성 파일 구조와 적용 범위

Shadowrocket 구성 파일에는 대괄호로 표시된 여러 섹션이 들어갈 수 있습니다. 섹션 이름에 따라 뒤따르는 텍스트의 해석 방식이 달라지며, 파일에서 보기 좋게 나눈 구획과는 별개입니다. [Rule]의 도메인 규칙과 [Host]의 주소 매핑은 같은 도메인을 다루더라도 역할이 다릅니다. 수정하기 전에 현재 활성화된 구성이 무엇인지 확인한 뒤 해당 섹션을 편집하세요. 파일을 Config 목록에 저장하는 것만으로 해당 파일이 선택되는 것은 아닙니다.

서버 정보, 구독, 구성을 구분하세요

서버 정보는 어디에 어떤 프로토콜로 연결하고 어떻게 인증하는지를 나타냅니다. 구독은 서버 항목을 한꺼번에 가져와 업데이트하는 데 사용됩니다. 규칙 구성은 각 요청을 어떤 정책으로 처리할지 정합니다. 세 가지는 하나의 작업 흐름에서 함께 사용될 수 있지만 서로 대체할 수는 없습니다. 서버에 연결할 수 있어도 규칙 파일이 적용된다는 뜻은 아니며, 규칙 파일을 읽을 수 있어도 파일에서 지정한 프록시 출구가 사용 가능하다는 뜻은 아닙니다. 가져온 뒤 예상한 결과가 나오지 않으면 서버 항목이 없는 것인지, 트래픽 분기 구성이 없는 것인지부터 확인하세요.

Config에서 파일을 확인할 때는 파일 이름, 현재 선택 여부, 출처를 함께 기록하세요. 원격 파일을 나중에 업데이트하면 로컬 수정 사항이 덮어써질 수 있으므로 처음 시험할 때는 원본 사본을 보관하세요. 기존 구성을 충분히 이해하기 전에 온라인에서 찾은 조각으로 전체 내용을 교체하지 마세요. 이 페이지의 예제는 문법 설명용이며 인증 정보가 없으므로 그대로 연결할 수 있는 완전한 구성 파일이 아닙니다.

각 섹션의 역할

섹션주요 역할확인할 항목
[General]일반 네트워크 및 이름 확인 설정DNS 또는 우회 범위가 바뀌는지 확인
[Rule]조건에 따라 연결 정책 선택규칙 순서와 마지막 기본 처리
[Host]특정 도메인의 주소 매핑주소가 정확하고 여전히 유효한지 확인
[URL Rewrite]표현식으로 인식 가능한 URL 처리매칭 범위와 리디렉션 결과 확인
 
[General]
dns-server = system

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

[Host]
fixed.example.com = 192.0.2.10

위의 192.0.2.10은 문서용 예시 주소이며 사용할 수 있는 서버가 아닙니다. 내용을 읽을 때는 먼저 섹션 이름을 확인하고 각 줄의 구분 방식을 살펴보세요. General과 Host는 등호로 키와 값을 구분하고, Rule은 보통 영문 쉼표로 규칙 유형, 조건, 정책을 나눕니다. 전각 쉼표나 눈에 보이지 않는 공백, 서식 있는 텍스트에서 복사한 문장 부호 때문에 겉보기에는 같아도 입력값이 달라질 수 있습니다.

편집 전 최소 점검 목록 만들기

먼저 현재 Global Routing 모드를 기록하고, SERVER에서 선택한 서버를 확인한 다음, Config에서 사용 중인 파일을 확인하세요. 세 항목을 함께 기록해야 출구 변경을 규칙 변경으로 오해하지 않습니다. 수정 전후를 비교하려면 조건 하나만 바꾸고 저장한 뒤 연결 테스트를 다시 실행하세요. 서버 변경, DNS 조정, 규칙 재정렬을 한꺼번에 하면 결과가 달라져도 원인을 찾기 어렵습니다.

구성 파일을 판단할 때는 ‘구문을 읽을 수 있는가’와 ‘목적에 맞는가’를 구분해야 합니다. 전자는 문법이 허용된다는 뜻일 뿐이며, 후자는 실제 요청으로 확인해야 합니다. 예를 들어 FINAL 뒤에 적힌 도메인 규칙은 문법상 올바르더라도 앞의 기본 처리 규칙이 요청을 이미 처리했다면 적용되지 않습니다. 반대로 파일의 주석이 용도를 잘 설명하더라도 주석 자체는 매칭 동작을 바꾸지 않으므로 실제 적용되는 규칙을 기준으로 판단하세요.

General, DNS 및 규칙 입력

General은 규칙이 작동하는 환경에 영향을 줍니다. 도메인을 확인하는 방법과 시스템 경로에서 처리할 대상에 따라 이후 관찰할 수 있는 요청 정보가 달라집니다. 따라서 규칙을 분석할 때 Rule 섹션만 살펴봐서는 안 됩니다. 같은 규칙도 이름 확인 조건에 따라 결과가 달라질 수 있으며, 특히 대상 주소에 의존하는 GEOIP, IP-CIDR, IP-CIDR6에서 차이가 나타날 수 있습니다. 먼저 이름 확인과 라우팅이 서로 다른 단계임을 이해한 뒤 수정할 항목을 정하세요.

DNS 이름 확인과 정책 선택은 다릅니다

DNS는 도메인을 주소로 변환하고, 트래픽 분기 정책은 연결을 어떻게 처리할지 결정합니다. 도메인이 성공적으로 확인됐다는 사실만으로 요청이 PROXY와 DIRECT 중 어느 쪽으로 전달되는지 알 수는 없습니다. 도메인 규칙은 주소를 얻어야만 매칭되는 것도 아닙니다. 클라이언트가 대상 도메인을 알고 있으면 DOMAIN 또는 DOMAIN-SUFFIX로 바로 판단할 수 있습니다. 주소 규칙은 대상 주소가 필요하므로 두 규칙의 입력 조건은 서로 다릅니다.

[General]
dns-server = system

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

dns-server = system은 시스템에서 제공하는 DNS를 사용한다는 뜻입니다. 이해를 돕기 위한 시작점이지 모든 네트워크에 맞는 고정 설정은 아닙니다. 기존 구성에 다른 이름 확인 방식이 지정되어 있다면 용도를 먼저 기록하고, 예제를 적용하려고 곧바로 덮어쓰지 마세요. 네트워크 전환, 시스템 DNS 상태, 접속하려는 서비스의 배포 방식에 따라 최종 주소가 달라질 수 있습니다.

no-resolve의 적용 범위

주소 규칙 끝의 no-resolve는 해당 주소 규칙을 시도하기 위해서만 도메인 이름 확인을 새로 시작하지 말라는 뜻입니다. DNS를 끄거나 이후 연결에서 더는 이름 확인을 하지 않는다는 뜻은 아닙니다. 요청에 이미 사용할 수 있는 대상 주소가 있으면 그 주소로 판단할 수 있습니다. 도메인만 있고 해당 시점에 사용할 주소가 없다면 이 규칙만으로 주소를 만들어 매칭할 수 없으며, 이후 규칙에서 요청을 계속 처리할 수 있습니다.

이 차이는 문제 해결에 중요합니다. no-resolve를 추가한 뒤 도메인이 주소 규칙에 더 이상 매칭되지 않아도 주소 섹션의 문법이 잘못된 것은 아닐 수 있습니다. 매칭 시점에 사용할 수 있는 주소가 없었을 가능성이 있습니다. 억지로 매칭하려고 모든 규칙에서 no-resolve를 삭제하지 마세요. 먼저 도메인 요청인지 주소 직접 요청인지 확인하고, 이름 확인이 필요한지 판단한 다음, 이름 확인 비용과 트래픽 분기 목적을 비교하세요.

캐시, 네트워크 전환 및 관찰 시점

브라우저, 앱, 시스템, 클라이언트는 서로 다른 위치에 이름 확인 정보나 연결 상태를 보관할 수 있습니다. DNS를 바꾼 직후 페이지를 새로 고쳐도 기존 연결을 재사용하면 새 설정이 반영되지 않을 수 있습니다. 테스트할 때는 요청을 새로 시작하고, 필요한 경우 해당 앱의 기존 세션을 종료한 뒤 앱에서 제공하는 방법으로 관련 캐시를 정리하세요. 한 번 새로 고친 뒤 변화가 없다고 구성이 적용되지 않은 것은 아닙니다. 반대로 우연히 한 번 성공했다고 문제가 해결된 것도 아닙니다.

Wi-Fi와 셀룰러 네트워크를 전환한 뒤에는 기본 네트워크가 작동하는지 다시 확인하세요. 시스템 자체에서 접근 가능한 대상으로 연결할 수 없다면 Rule을 계속 조정해도 하위 연결 문제는 해결되지 않는 경우가 많습니다. 먼저 Direct 모드로 제한적인 비교를 한 뒤 Config로 돌아와 규칙을 확인할 수 있습니다. 비교가 끝나면 전역 직접 연결 상태를 규칙 분기 결과로 오해하지 않도록 기존 모드로 복원하세요.

우회 범위를 일반 Rule로 취급하지 마세요

General의 일부 설정은 어떤 트래픽이 이후 처리 경로로 들어가는지에 영향을 줍니다. Rule의 DIRECT와는 같은 단계의 설정이 아닙니다. 우회 범위를 넓히면 요청이 예상한 규칙을 아예 거치지 않을 수 있으므로 ‘마지막에 FINAL이 있다’는 이유만으로 모든 트래픽이 기본 처리된다고 단정할 수 없습니다. 이런 설정을 조정하기 전에 기존 파일의 설명과 앱 내 옵션을 확인하세요. 용도가 불확실하다면 여러 값을 한꺼번에 삭제하기보다 원래 값을 유지하는 편이 재현하기 쉽습니다.

IPv6 관련 문제라면 도메인이 여러 주소 계열의 주소를 함께 반환하는지도 확인하세요. IPv4 주소 규칙만 작성했다고 IPv6 요청까지 처리되는 것은 아닙니다. 먼저 업무 범위를 정확히 표현하는 도메인 규칙을 사용하고, 실제로 필요한 경우에만 주소 범위 규칙을 추가하세요. 특정 주소 계열을 비활성화하는 것부터 시작하지 마세요. 실제 대상 주소를 기록해야 문제가 이름 확인, 매칭, 연결 경로 중 어디에 있는지 알 수 있습니다.

DOMAIN 계열 규칙의 매칭 범위

분기 목적을 표현할 때는 계속 바뀌는 대상 주소보다 도메인 규칙이 적합한 경우가 많습니다. 단, 매칭 시 클라이언트가 대상 도메인을 확인할 수 있어야 합니다. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD의 차이는 주로 적용 범위에 있으며 어느 하나가 더 ‘강력한’ 것은 아닙니다. 규칙을 선택하기 전에 포함하려는 대상을 명확히 정하고, 필요한 범위 안에서 가장 좁은 조건을 사용하세요. 한 줄을 줄이려고 오매칭을 알아차리기 어려운 규칙을 만들지 마세요.

DOMAIN: 정확한 도메인 하나만 지정

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

DOMAIN은 완전한 도메인 이름을 정확히 매칭합니다. 첫 번째 규칙은 login.example.com만 처리하며 example.com이나 cdn.login.example.com까지 자동으로 포함하지 않습니다. 로그인 주소나 API 도메인처럼 별도로 처리할 대상을 지정할 때 적합합니다. 규칙 조건에는 도메인만 입력하고 프로토콜, 포트, 경로는 붙이지 마세요. 전체 웹 주소를 입력해도 도메인 규칙이 경로 규칙으로 바뀌지는 않습니다.

특정 API 요청만 변경하고 같은 도메인의 다른 경로는 그대로 두려는 경우 DOMAIN만으로는 그 정도의 세밀한 구분을 표현할 수 없습니다. 경로 단위 처리가 정말 필요한지 먼저 판단하세요. 도메인 뒤에 슬래시를 붙인다고 해결되는 것은 아닙니다. 도메인 규칙은 연결 정책을 선택할 뿐, 조건에 로그인 도메인을 입력했다고 로그인에 필요한 다른 도메인까지 자동으로 처리하지는 않습니다.

DOMAIN-SUFFIX: 루트 도메인과 하위 도메인 포함

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

DOMAIN-SUFFIX는 도메인 접미사의 경계를 기준으로 매칭합니다. 여기서 example.com은 루트 도메인과 www.example.com, a.b.example.com 같은 하위 도메인을 포함합니다. 문자열 어디에든 같은 글자가 있으면 매칭되는 방식은 아닙니다. notexample.com은 이 도메인 경계에 속하지 않으며 example.com.other.test도 하위 도메인이 아닙니다.

예제에서는 portal에 대한 정확한 예외 규칙이 앞에 있어 먼저 DIRECT로 처리됩니다. 나머지 example.com 도메인에는 접미사 규칙이 적용되어 PROXY로 전달됩니다. 접미사 규칙을 첫 줄에 두면 portal 예외가 적용될 기회를 잃습니다. 정확한 규칙이라고 자동으로 우선순위가 높아지는 것은 아니며, 먼저 검사되는지는 목록의 순서로 결정됩니다.

DOMAIN-KEYWORD: 더 넓은 문자열 범위

[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 매칭합니다. example.com뿐 아니라 myexample.test에도 적용될 수 있습니다. 특정 도메인과 그 하위 도메인만 처리하려는 목적이라면 키워드 규칙은 접미사 규칙보다 범위가 넓어 같은 문자열이 우연히 포함된 다른 사이트까지 함께 처리할 수 있습니다. 흔한 문자 몇 개만 키워드로 지정하면 오매칭 원인을 찾기가 특히 어렵습니다.

따라서 단일 예외에는 DOMAIN을, 명확한 도메인 집합에는 DOMAIN-SUFFIX를 먼저 고려하세요. 공통 접미사가 없는 여러 도메인을 이름의 일부로 분류해야 하고 잠재적인 적용 범위도 확인한 경우에만 DOMAIN-KEYWORD를 사용하세요. 도메인 목록 관리를 대신하려고 키워드를 사용하면 특정 요청이 왜 해당 분류에 들어갔는지 나중에 설명하기 어렵습니다.

도메인 조건의 경계와 누락

웹페이지는 메인 사이트 외에도 정적 리소스, 인증, API 등에 여러 도메인을 요청하는 경우가 많습니다. 메인 사이트에 예상한 규칙이 적용되어도 페이지의 모든 리소스가 같은 정책을 사용한다는 뜻은 아닙니다. 페이지 기본 화면은 뜨는데 이미지나 로그인이 실패한다면 메인 도메인에 규칙을 반복해서 추가하지 말고 실제로 실패한 요청의 도메인을 확인하세요. 외부 서비스 의존성도 기록을 바탕으로 처리하고, 추측만으로 범위를 넓히지 마세요.

주소로 직접 접속하는 연결에는 사용할 수 있는 도메인이 없을 수 있으며, 이 경우 도메인 규칙에 적용할 조건이 없습니다. 암호화된 트래픽에서 어떤 도메인 정보를 얻을 수 있는지는 연결 상황에 따라 달라지므로 모든 요청의 원래 이름을 복원할 수 있다고 가정하지 마세요. 기록에 주소만 표시된다면 주소 규칙을 확인하고, 그 주소를 DOMAIN 조건인 것처럼 작성하지 마세요. 용어는 용어 설명에서 함께 확인할 수 있습니다.

GEOIP, IP-CIDR 및 USER-AGENT

대상이 주소로 표시되거나 트래픽 분기 목적이 주소의 지역 구분에 실제로 좌우될 때 주소 규칙을 사용할 수 있습니다. 주소 규칙은 도메인 규칙과 함께 매칭되며 자동으로 뒤에 배치되지 않습니다. USER-AGENT는 확인 가능한 요청 헤더를 기준으로 하므로 입력 조건이 또 다릅니다. 여러 규칙 유형을 한 목록에서 사용할 때는 각 조건이 어떤 정보에서 오는지 이해해야 합니다. 그렇지 않으면 입력 정보가 없는 문제를 문법 오류로 오해하기 쉽습니다.

IP-CIDR 및 IP-CIDR6

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

IP-CIDR은 IPv4 주소 범위를 나타냅니다. 슬래시 뒤 숫자는 네트워크 프리픽스 길이이며 포트나 우선순위가 아닙니다. /32는 IPv4 주소 하나에 해당하고 /24는 더 넓은 주소 블록을 나타냅니다. IP-CIDR6은 IPv6 범위를 지정하며 단일 주소는 /128로 표현할 수 있습니다. 예시 주소는 모두 문서용이므로 실제 서비스 대상으로 연결을 테스트하는 데 사용할 수 없습니다.

프리픽스가 짧을수록 일반적으로 적용 범위가 넓습니다. ‘대상을 확실히 포함’하려고 네트워크 범위를 함부로 넓히면 관련 없는 연결까지 다른 경로로 전달될 수 있습니다. 먼저 실제 주소를 확인하고 네트워크 경계를 정하세요. 주소가 특정 도메인의 이름 확인 결과라면 이후 그 도메인이 다른 주소를 반환할 수 있다는 점도 고려해야 합니다. 한 번 확인된 주소가 서비스의 전체 주소 범위를 계속 대표하지는 않습니다.

GEOIP: 주소 데이터베이스로 판단

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

GEOIP는 주소 데이터베이스에 기록된 지역 분류를 기준으로 매칭합니다. 예제에서는 명확한 도메인 예외를 먼저 처리한 뒤 CN으로 분류된 대상 주소는 DIRECT로 연결하고, 나머지는 FINAL에 맡깁니다. 지역 분류는 도메인 등록 지역, 콘텐츠 언어, 서비스 운영 기관을 뜻하지 않으며 연결 속도를 나타내지도 않습니다. 데이터베이스와 실제 네트워크 할당에는 시차가 있을 수 있고, 여러 지역에 배포된 서비스나 주소 변경으로 인해 예상과 데이터베이스 결과가 다를 수 있습니다.

중요한 대상을 지역 분류만으로 안정적으로 처리할 수 없다면 GEOIP 앞에 더 구체적인 도메인 또는 주소 예외를 추가하고 이유를 기록하세요. 관찰 결과 없이 지역 정책 전체를 자주 바꾸지 마세요. GEOIP,CN,DIRECT,no-resolve를 사용한다면 앞 장에서 설명한 이름 확인 제한도 고려해야 합니다. 사용할 수 있는 주소가 없으면 이 규칙이 예상대로 판단하지 못할 수 있습니다.

USER-AGENT의 적용 범위

[Rule]
USER-AGENT,ExampleClient*,DIRECT
FINAL,PROXY

USER-AGENT는 클라이언트가 읽을 수 있는 User-Agent 요청 헤더를 확인합니다. 예제의 와일드카드 형식은 ExampleClient로 시작하는 값을 나타낼 뿐이며 실제 앱을 가리키지는 않습니다. 시스템 앱 이름을 기준으로 트래픽을 나누는 범용 기능이 아니며 암호화된 연결에서 임의의 요청 헤더를 자동으로 가져올 수도 없습니다. 앱에 표시되는 이름, 프로세스 이름, User-Agent는 서로 다를 수 있으므로 서로 바꿔 입력할 수 없습니다.

HTTPS에서는 일반적인 연결 처리만으로 암호화된 HTTP 요청 헤더를 직접 읽을 수 없는 경우가 많으므로 USER-AGENT가 모든 앱 트래픽에 적용된다고 가정하지 마세요. 이 페이지의 예제를 위해 인증서를 추가하거나 복호화 범위를 넓힐 필요는 없습니다. 헤더를 확인할 수 있는지 확실하지 않다면 검증 가능한 도메인 또는 주소 규칙을 우선 사용하세요. 대상 요청에 해당 헤더가 없다면 이 규칙에 매칭할 입력 정보도 없습니다.

표현 방식을 먼저 정한 뒤 예외를 처리

서비스 도메인을 관리할 때는 도메인 조건을, 고정 주소 범위를 다룰 때는 IP-CIDR을, 주소 데이터베이스에 따른 분류에는 GEOIP를 우선 고려하세요. 요청 헤더를 읽을 수 있고 헤더에 따른 구분이 꼭 필요한 경우에만 USER-AGENT를 검토하세요. 규칙 유형이 많다고 구성이 더 완전해지는 것은 아닙니다. 같은 대상에 여러 조건을 쌓으면 이해가 어려워지고, 조건마다 정책이 다르면 더 혼란스러울 수 있습니다.

주소 규칙을 검증할 때는 주소 계열, 실제 대상 주소, 매칭된 규칙을 함께 기록하세요. 같은 도메인도 한 테스트에서는 IPv4를, 다른 테스트에서는 IPv6를 사용해 서로 다른 규칙에 적용될 수 있습니다. 비교 테스트는 네트워크와 대상을 동일하게 유지하는 것이 좋습니다. IPv6 예외를 추가해야 한다면 확인된 범위를 근거로 설정하고 모든 IPv6 요청을 한꺼번에 처리해 일부 구성 문제를 감추지 마세요.

정책, Global Routing 및 우선순위

규칙 조건은 ‘매칭되는가’를, 정책은 ‘매칭된 뒤 어떻게 처리되는가’를 결정합니다. 이 페이지의 예제에서는 기본 정책으로 PROXY, DIRECT, REJECT를 사용합니다. 이 정책들은 Home의 Global Routing과 같은 단계가 아닙니다. Global Routing은 구성에 따른 분기와 전역 모드 중 어떤 방식을 사용할지 정하고, Rule의 정책은 구성 기반 분기 중 개별 연결을 처리합니다. 문제를 해결할 때는 바깥쪽 모드를 먼저 확인하고 안쪽 규칙을 살펴보세요.

세 가지 정책의 실제 의미

정책처리 방식흔한 오해
PROXY현재 사용할 수 있는 프록시 출구 사용정책을 작성해도 서버가 자동으로 생성되지는 않음
DIRECT대상에 직접 연결직접 연결도 로컬 네트워크와 이름 확인에 영향을 받음
REJECT매칭된 요청 거부거부하면 페이지에 필요한 리소스에 영향을 줄 수 있음

PROXY를 사용하려면 사용할 수 있는 서버 정보와 유효한 출구 선택이 먼저 있어야 합니다. 출구 인증에 실패해도 PROXY 규칙 자체는 올바르게 매칭됐을 수 있으며, 이후 연결 단계에서 실패한 것입니다. DIRECT도 요청 성공을 보장하지 않으며 시스템 네트워크 조건의 영향을 받지 않는다는 뜻도 아닙니다. REJECT는 요청을 명시적으로 거부하므로 실제로 차단할 의도가 있는 경우에 사용하세요. 범위가 넓은 키워드를 곧바로 REJECT로 지정한 뒤 필요한 리소스가 사라진 문제를 서버 장애로 오해하지 마세요.

Global Routing의 세 가지 모드

구성 모드인 Config는 현재 구성에 따라 트래픽을 분기합니다. 프록시 모드인 Proxy는 전체 트래픽을 프록시로 처리하며, 직접 연결 모드인 Direct는 전체 트래픽을 직접 연결합니다. 규칙을 확인할 때는 Config로 돌아가세요. Proxy나 Direct 모드에 계속 머물러 있으면 Rule만 수정해도 해당 규칙이 예상대로 작동하는지 확인할 수 없습니다. 모드 비교는 진단 절차로 활용하고 올바른 규칙을 대신하는 장기 설정으로 사용하지 마세요.

이 페이지는 클라이언트의 처리 경로에 진입한 트래픽의 분기를 설명합니다. 시스템 수준의 네트워크 처리와 General의 우회 범위도 실제 적용 범위에 영향을 줄 수 있으므로 ‘전역’ 모드가 모든 시스템 트래픽을 반드시 같은 경로로 전달한다는 뜻은 아닙니다. 상태 표시줄의 연결 표시만 보고 모든 대상에 예상한 정책이 적용된다고 판단하지 말고 관찰 가능한 특정 요청을 대상으로 테스트하세요.

위에서 아래로 검사하고 첫 매칭에서 종료

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

Rule 목록은 일반적으로 위에서 아래로 검사하며 처음 매칭된 규칙의 정책을 적용하고 ‘더 정확한’ 규칙을 계속 찾지 않습니다. 예제에서는 특정 도메인 예외를 접미사 규칙보다 앞에, 명확한 주소 범위를 지역 규칙보다 앞에 두고 마지막에 기본 처리 규칙을 배치했습니다. 이 순서는 작성자가 의도한 결과를 나타낼 뿐 엔진이 정밀도 순위를 계산한 결과가 아닙니다. 하나의 대상이 여러 규칙에 해당하면 목록에서 앞선 규칙이 먼저 결과를 만듭니다.

FINAL은 일반적인 조건부 규칙이 아닙니다

FINAL,PROXY에는 유형과 정책만 있으며 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 도메인을 추가로 입력할 필요가 없습니다. 중간에 배치하면 이후 규칙이 나머지 요청을 처리할 기회를 잃습니다. 구성 파일을 관리할 때 예상한 마지막 기본 규칙만 있는지 확인하고, 파일을 합치는 과정에서 FINAL이 여러 개 생기지 않도록 하세요. 마지막에 PROXY와 DIRECT 중 무엇을 사용할지는 구성 목적에 따라 결정해야 합니다. 어느 한쪽이 본래 더 올바른 것은 아닙니다.

규칙 순서를 바꾸기 전에 구체적인 도메인 하나를 선택하고 첫 줄부터 순서대로 판단해 처음 매칭되는 지점에서 멈추는 방식으로 우선순위를 검토하세요. 목록에 없는 대상 하나에도 같은 방식으로 적용해 FINAL에 도달하는지 확인합니다. 예상한 결과와 실제 기록이 다르면 키워드 길이나 도메인 단계에 따라 엔진이 자동 정렬한다고 가정하지 말고 현재 파일, 모드, 사용 가능한 입력 정보를 확인하세요.

Host와 URL Rewrite의 차이

Host와 URL Rewrite는 모두 접속 결과를 바꿀 수 있지만 처리 대상은 다릅니다. Host는 도메인과 주소의 매핑을 지정하고, URL Rewrite는 URL 표현식에 따라 해당 작업을 수행합니다. 둘 다 Rule의 정책 선택과는 다릅니다. 요청이 예상하지 못한 주소로 연결되거나 다른 URL로 이동했다면 이름 확인 매핑, 재작성 결과, 트래픽 분기 규칙을 각각 확인하세요. 원인을 Rule에서만 찾지 마세요.

Host: 이름 확인 매핑 지정

[Host]
fixed.example.com = 192.0.2.10
service.example.com = 198.51.100.20

[Rule]
DOMAIN,fixed.example.com,DIRECT
DOMAIN,service.example.com,PROXY
FINAL,PROXY

여기 있는 두 Host 항목은 완전한 도메인을 지정된 주소에 매핑하는 예제이며 주소는 문서용 값입니다. 첫 번째 Rule은 별도로 fixed.example.com을 DIRECT로 처리합니다. 즉 ‘어디로 매핑할지’와 ‘어떻게 연결할지’는 따로 지정해야 합니다. Host를 입력했다고 해당 도메인이 반드시 직접 연결되는 것은 아닙니다. DOMAIN을 PROXY로 지정해도 잘못된 주소 매핑이 자동으로 수정되지는 않습니다.

주소를 고정 매핑하면 일반적인 DNS 응답에 대한 의존성은 줄지만, 서비스가 주소를 동적으로 조정할 수 있는 유연성도 사라집니다. 동적 배포나 여러 지역의 접속 지점을 사용하는 서비스에서는 과거에 확인한 주소를 고정하면 시간이 지나면서 작동하지 않을 수 있습니다. 용도를 확인했고 계속 관리할 수 있을 때만 사용하세요. 일부 네트워크에서는 연결되고 다른 네트워크에서는 실패한다면 모든 DNS를 바로 바꾸기보다 Host를 별도 변수로 두고 비교 테스트하세요.

Host는 인증서 식별 정보를 바꾸지 않습니다

도메인을 특정 주소에 매핑해도 그 주소의 서비스가 해당 사이트에 맞는 설정이나 유효한 인증서를 자동으로 갖게 되는 것은 아닙니다. HTTPS는 여전히 접속 도메인에 해당하는 신원을 확인하며, 서버는 요청에 포함된 이름에 따라 서로 다른 사이트를 선택할 수도 있습니다. 매핑 후 인증서 오류가 발생하면 대상 주소가 실제로 해당 도메인 서비스를 제공하는지 확인하세요. 신원 확인을 무시해 잘못된 주소를 입력한 문제를 감추지 마세요.

마찬가지로 Host는 웹페이지 리디렉션 도구가 아닙니다. 주소 매핑만으로 브라우저 주소 표시줄의 도메인이 다른 이름으로 바뀌지는 않습니다. 브라우저가 새 페이지로 이동한 이유를 알아보려면 서버 응답이나 URL Rewrite를 확인하세요. 주소가 바뀌는 것과 화면에 표시되는 URL이 바뀌는 것을 혼동하지 마세요. 처리 단계를 구분해야 겉보기에는 비슷한 문제를 잘못된 기능으로 해결하는 일을 줄일 수 있습니다.

URL Rewrite: 표현식과 작업 이해하기

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

예제는 매칭된 HTTP URL을 해당 HTTPS URL로 리디렉션합니다. 왼쪽은 정규식입니다. ^는 시작 위치를 지정하고 도메인 안의 점은 백슬래시로 이스케이프하며 (.*)는 뒤에 오는 내용을 캡처합니다. 가운데는 대체 대상이고 $1은 첫 번째 캡처 그룹을 참조합니다. 끝의 302는 임시 리디렉션을 뜻합니다. 이 문법은 대상 도메인을 PROXY로 보내는 규칙도 아니며 서버에 HTTPS를 설정하는 방법도 아닙니다.

표현식을 작성할 때는 프로토콜과 도메인의 경계를 제한하세요. 이스케이프하지 않은 점은 임의의 문자 하나를 의미하며 시작 또는 끝 경계가 없으면 매칭 범위가 넓어질 수 있습니다. 루트 경로, 쿼리 매개변수가 있는 경로, 매칭되면 안 되는 유사 도메인을 포함해 테스트하여 캡처 내용이 잘리거나 중복으로 이어지지 않는지 확인하세요. 개인 쿼리 매개변수가 포함된 실제 URL을 공유 메모에 붙여 넣지 말고 예제에는 example.com을 사용하세요.

표시 범위와 리디렉션 루프

URL Rewrite가 작동하려면 해당 URL 정보를 확인할 수 있어야 합니다. 일반적인 암호화 연결이라고 해서 전체 경로를 자동으로 읽을 수 있는 것은 아니므로 HTTP 예제가 모든 HTTPS 콘텐츠에도 적용된다고 가정하지 마세요. 이 장에서는 복호화 범위를 넓힐 필요가 없습니다. 규칙이 작동하지 않으면 먼저 입력 URL을 확인할 수 있는지 살펴본 다음 표현식을 점검하세요. 모든 도메인에 적용하도록 정규식을 넓혀도 부족한 정보를 보충할 수는 없으며 위험만 커집니다.

대상 주소가 다른 규칙에 의해 다시 원래 주소로 바뀌면 리디렉션 루프가 발생할 수 있습니다. 브라우저 기록에는 일반적으로 단순한 시간 초과가 아니라 반복 이동으로 표시됩니다. 문제를 해결할 때는 새로 추가한 Rewrite를 잠시 비활성화해 원래 요청이 복구되는지 확인한 다음 규칙을 하나씩 다시 추가해 비교하세요. Host, Rewrite, Rule은 각각 따로 테스트하고 매 단계에서 한 가지 방식만 바꾸세요. 비교할 수 있도록 원래 URL, 최종 URL, 매칭 결과를 기록하세요.

규칙 조합, 병합 및 구성 관리

관리하기 쉬운 구성은 규칙 수가 많아서가 아니라 각 조건의 역할이 분명해서 만들어집니다. 흔한 구성 방식은 구체적인 예외를 앞에 두고, 그다음 서비스 도메인 집합을 배치하며, 필요한 주소 및 지역 조건을 뒤에 둔 뒤 마지막에 기본 처리 규칙을 두는 것입니다. 이는 일반적인 방식일 뿐 고정 표준은 아닙니다. 구성 목적에 따라 순서를 바꿀 수 있지만 구체적인 요청이 현재 결과를 얻은 이유를 설명할 수 있어야 합니다.

검증 가능한 최소 예제부터 시작

[Rule]
# 특정 예외를 도메인 집합보다 먼저 배치
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY

# 이미 사용할 수 있는 대상 주소만 처리
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve

# 지역 판별 뒤에 기본 처리 규칙 배치
GEOIP,CN,DIRECT
FINAL,PROXY

이 예제는 규칙 섹션의 구성 방식만 보여 주며 서버 정보와 인증 정보는 포함하지 않습니다. 먼저 portal이 DIRECT로 처리되는지 확인하고, 같은 접미사를 가진 다른 도메인이 PROXY로 전달되는지 살펴본 다음, 관련 없는 도메인이 주소에 따라 분류되거나 FINAL에 도달하는지 확인하세요. 문서용 주소를 실제 테스트 서버로 사용할 수는 없습니다. 자신이 보유하고 접근 권한이 있는 테스트 대상을 조건에 맞게 사용하세요.

REJECT를 추가할 때도 최소 원칙을 지키세요. 주요 기능에 영향을 주지 않는다고 확인된 완전한 도메인 하나를 대상으로 하고 실제 기록에서 요청이 예상한 대상인지 검증할 수 있습니다. 요청 수를 줄이려고 업무 도메인 전체를 곧바로 거부하지 마세요. 정적 리소스만 제공하는 것처럼 보이는 도메인도 인증이나 페이지 초기화에 필요할 수 있습니다. 잘못 거부하면 네트워크 전체가 끊기는 대신 일부 기능만 이상해질 수 있습니다.

병합 전에 중복 범위와 종료 조건 확인

파일 두 개를 단순히 이어 붙이면 섹션이 중복되거나 정책이 충돌하고 FINAL이 중간에 놓일 수 있습니다. 병합하기 전에 Rule 목록을 하나로 정리하고 각 규칙의 위치를 확인하세요. 조건과 정책이 같은 규칙이 반복되면 대체로 관리 부담만 늘어납니다. 정책이 다르면 뒤쪽 규칙이 계속 매칭될 기회를 얻지 못하면서 독자는 두 정책이 모두 적용된다고 오해할 수 있습니다.

텍스트만 비교해 중복을 제거하는 방식으로 충돌을 판단해서는 안 됩니다. DOMAIN과 DOMAIN-SUFFIX는 내용이 달라도 같은 대상에 적용될 수 있으며 IP-CIDR과 GEOIP도 주소 범위가 겹칠 수 있습니다. 대표 대상을 몇 개 선택해 규칙을 차례로 검토하고 예외가 넓은 조건보다 앞에 있는지 확인하세요. 병합 후에는 예상한 기본 처리 규칙 하나만 남기고 각 정책 이름이 현재 구성 환경에서 실제로 인식되는지도 다시 점검하세요.

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

기존 구독 업데이트는 주로 서버 항목에 영향을 주고, 원격 구성 업데이트는 Rule, General 등의 텍스트를 바꿀 수 있습니다. 두 작업은 같은 것으로 볼 수 없습니다. 업데이트 후 동작이 달라졌다면 어떤 내용이 업데이트됐는지 먼저 확인하세요. 서버 목록 변경은 출구 선택에 영향을 줄 수 있고 규칙 텍스트 변경은 매칭 경로를 바꿀 수 있습니다. 기억에 의존하는 것보다 업데이트 전후 파일을 따로 저장하는 편이 실제 차이를 찾기 쉽습니다.

장기간 사용할 때는 검증된 로컬 수정을 별도 사본에 보관하고 출처, 목적, 복구 방법을 기록하는 것이 좋습니다. 원격 내용을 업데이트하기 전에 해당 파일이 덮어써지는지 확인하세요. 로컬에서 추가한 모든 내용이 자동으로 보존된다고 가정하지 마세요. 가져오기 경로와 구독 업데이트의 차이는 Subscribe, Add Server, QR 코드 및 클립보드로 가져오기 안내를 참고하세요.

주석에는 이유와 되돌릴 조건을 기록

유용한 주석은 규칙을 다시 말하는 데 그치지 않고 예외가 필요한 이유, 검증 방법, 삭제할 수 있는 시점을 설명합니다. 예를 들어 “이 API는 메인 사이트와 같은 출구가 필요함. 테스트할 때 로그인과 후속 API 확인”이라고 적으면 “API 규칙”이라고만 적는 것보다 도움이 됩니다. 주석에 구독 인증 정보, 개인 링크 전체, 서버 비밀번호를 저장하지 마세요. 도움을 요청할 때는 구성 텍스트에서 민감한 정보를 먼저 가리세요.

수정할 때마다 변경 조건, 이전 결과, 예상 결과, 실제 결과를 간단히 기록하세요. 새 규칙을 추가해도 대상 문제가 나아지지 않으면 다른 변수를 시도하기 전에 해당 규칙을 되돌리세요. 효과가 없는 수정 사항을 목록에 계속 남겨 두지 마세요. 규칙 관리의 목표는 파일에 추적할 수 없는 예외를 쌓는 것이 아니라 현재 동작을 나중에도 다시 설명할 수 있게 하는 것입니다.

매칭 확인 및 연결 문제 해결

규칙 문제와 연결 문제가 함께 발생하면 모두 페이지가 열리지 않는 현상으로 나타날 수 있지만 해결 방법은 다릅니다. 규칙 문제는 요청이 예상한 정책에 들어갔는지 확인하고, 연결 문제는 해당 정책의 네트워크 경로를 사용할 수 있는지 살펴봐야 합니다. ‘현재 연결 상태’, ‘매칭 조건’, ‘출구 연결 결과’를 따로 기록하세요. VPN 스위치가 켜졌다는 것은 구성 연결이 시작됐다는 뜻일 뿐 서버, DNS, 대상 서비스가 모두 정상이라는 증거는 아닙니다.

반복 가능한 테스트 조건 만들기

시작하기 전에 네트워크 유형, Global Routing 모드, 현재 구성 이름, 선택한 서버, 명확한 테스트 대상 하나를 기록하세요. 먼저 기존 구성으로 기본 연결을 확인한 다음 Config에서 대상 규칙을 점검합니다. 테스트할 때마다 연결 요청을 새로 시작해 앱이 이전 세션을 재사용하지 않도록 하세요. 비슷한 페이지를 여러 개 열어 체감 속도를 비교하기보다 실제 요청에 예상한 정책이 적용됐는지 보여 주는 근거를 찾으세요.

Connectivity Test로 기존 서버의 연결 상태를 확인할 수 있지만 결과는 해당 테스트 조건에만 적용되며 모든 도메인이나 프로토콜 요청이 성공한다는 뜻은 아닙니다. 서버 테스트에 통과해도 DNS, 트래픽 분기, 서버 측 제한, 주소 계열 차이로 대상 사이트에 접속하지 못할 수 있습니다. 서버 테스트는 점검 항목 중 하나이지 규칙 검증을 생략할 근거가 아닙니다.

예상한 규칙에 매칭되지 않을 때

  1. Global Routing이 Config인지, Config에서 방금 편집한 파일을 실제로 선택했는지 확인하세요.
  2. 요청에서 실제로 사용한 도메인 또는 주소를 확인하세요. 브라우저 주소 표시줄이 모든 리소스 요청을 나타내지는 않습니다.
  3. 목록의 맨 위부터 확인해 먼저 매칭되는 넓은 조건, 중복 조건, 앞쪽에 배치된 FINAL이 있는지 살펴보세요.
  4. 영문 쉼표, 섹션 이름, 정책 이름과 no-resolve가 입력 조건에 미치는 영향을 확인하세요.

기록에 주소만 표시된다면 도메인을 실제로 사용할 수 없는 상황인지 먼저 판단한 뒤 IP-CIDR 또는 GEOIP를 확인하세요. 예상하지 않은 DOMAIN-KEYWORD 규칙이 매칭됐다면 키워드 범위를 좁히는 방법을 고려하세요. 규칙 자체가 처리에 참여하지 않았다면 General의 우회 설정도 다시 확인해야 합니다. 처음부터 구성 파일 전체를 삭제하면 문제를 설명해 줄 원래 조건까지 사라집니다.

올바른 정책에 매칭됐는데도 실패하는 경우

관찰된 결과우선 확인할 항목먼저 하지 말아야 할 작업
PROXY에 매칭된 뒤 실패현재 출구, 인증 정보, 대상 접근 가능 여부같은 도메인 규칙을 반복해서 추가
DIRECT에 매칭된 뒤 실패시스템 네트워크, DNS, 대상 주소직접 연결은 반드시 성공한다고 가정
페이지 일부 리소스만 실패실패한 리소스의 도메인과 적용 정책메인 사이트에 맞춰 키워드 범위만 확대
리디렉션이 연속으로 발생URL Rewrite와 서버 측 리디렉션프록시 출구만 변경

PROXY 경로가 실패하면 규칙은 그대로 둔 채 자신이 보유한 다른 유효한 출구로 비교 테스트할 수 있습니다. 출구를 바꾼 뒤 정상화된다면 원래 출구나 해당 출구에서 대상까지의 경로에 문제가 있을 가능성이 큽니다. DIRECT 경로가 실패하면 같은 네트워크에서 시스템 자체의 접속 상태를 먼저 확인하세요. 비교 테스트에서는 매번 무엇을 바꿨는지 기록해 네트워크 변동과 구성 수정을 혼동하지 않도록 하세요.

일부 리소스 실패와 구성 되돌리기

로그인, 이미지, 동영상, API 요청이 실패하면 해당 요청을 먼저 확인하세요. 메인 페이지와 같은 도메인이나 연결을 사용한다고 가정하지 마세요. REJECT가 필요한 리소스를 차단하는지, 서로 다른 도메인이 호환되지 않는 출구 경로로 설정됐는지도 확인해야 합니다. 새 구성을 추가한 뒤 문제가 발생했다면 먼저 기준 구성으로 되돌려 관련성을 확인한 후 수정 사항을 하나씩 다시 적용하세요. 규칙을 계속 추가하는 것보다 원인을 찾기 쉽습니다.

문제 기록을 정리할 때는 구성 일부, 민감 정보를 가린 대상 이름, 매칭 규칙, 오류 증상만 남기세요. 인증 정보, 개인 구독 주소, 민감한 요청 내용은 삭제해야 합니다. 프로토콜 매개변수 불일치는 VMess와 VLESS 필드 차이에서, 자주 발생하는 연결 증상은 자주 묻는 질문에서 유형별로 확인할 수 있습니다. 인증 문제를 규칙 키워드 문제로 착각하지 마세요.

검증을 마치면 평소 사용하는 Global Routing 모드로 복원하고 확인된 구성을 저장한 뒤 임시 Host, Rewrite 또는 테스트 규칙을 제거하세요. 처음부터 전체 사용 절차를 다시 확인해야 한다면 사용 설명서로 돌아가 가져오기, 출구 선택, VPN 구성 승인, 연결 검증을 순서대로 확인하세요. 시스템 요구 사항, 기기 호환성, 앱 다운로드 정보는 App Store 페이지에 표시된 내용을 기준으로 확인하세요.