Shadowrocket 규칙 가이드: 설정 파일 구조, 매칭 순서와 트래픽 분기

01 / 파일의 구성

설정 파일 구조: 네 가지 역할 구분하기

Shadowrocket 설정 파일은 여러 섹션으로 나뉜 텍스트 형식으로 설정을 구성합니다. 대괄호 안의 섹션 이름이 각 영역의 역할을 구분하며, 각 섹션에는 매개변수, 규칙 또는 매핑을 작성합니다. 파일을 읽을 때는 먼저 [General], [Rule], [Host], [URL Rewrite]를 찾고 각 섹션의 내용을 확인하세요. 설정 파일은 서버 목록과 같은 것이 아닙니다. 서버는 연결을 담당하고 설정은 각 요청을 어떻게 처리할지 지정하므로, 두 요소를 현재 실행 상태와 함께 살펴봐야 합니다.

섹션 이름에 따라 내용 해석 방식이 달라집니다

[General]에는 보통 키-값 형식의 설정 매개변수를 작성합니다. [Rule]에는 순서대로 확인하는 트래픽 분기 조건을 작성합니다. [Host]는 지정된 호스트 이름의 로컬 주소 매핑을 나타냅니다. [URL Rewrite]는 표현식에 맞는 요청 주소를 처리합니다. 유효한 규칙을 잘못된 섹션에 넣어도 자동으로 유효한 트래픽 분기 규칙이 되지는 않습니다. 문제를 해결할 때는 규칙의 정확성을 따지기 전에 올바른 섹션에 들어갔는지 확인하세요.

# 섹션 구조 예시; 완전한 연결 설정이 아닙니다
[General]
dns-server = system

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

[Host]
test.example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

위의 네 섹션은 각각 다른 문법을 보여 주며, 모든 설정 파일에 전부 포함해야 한다는 뜻은 아닙니다. 로컬 매핑이 필요하지 않다면 Host 항목을 추가하지 않아도 됩니다. 명확한 주소 변경 목적이 없다면 URL Rewrite도 추가할 필요가 없습니다. 최소 설정의 장점은 각 설정의 역할을 설명할 수 있다는 것입니다. 파일을 완성된 것처럼 보이게 하려고 용도를 알 수 없는 매개변수를 넣기보다, 각 설정이 실제 요구 사항에 부합하는지 확인하세요.

설정, 서버 정보, 구독은 각각 따로 관리합니다

사용자가 보유한 서버 정보에는 보통 주소, 포트, 프로토콜, 인증 매개변수가 포함됩니다. 구독은 해당 항목을 한곳에서 가져오거나 업데이트하는 데 사용하고, 설정 파일은 트래픽 분기 방식을 별도로 지정합니다. 가져오기에 성공했다는 사실만으로 해당 정보가 앱에 추가되었다는 점을 확인할 수 있을 뿐, 서버 연결 가능 여부나 설정 선택 여부, 규칙의 예상대로 실행되는지까지 확인되는 것은 아닙니다. 점검할 때는 이 세 가지를 각각 확인하고, “구독을 업데이트했다”는 사실을 “올바른 설정을 사용 중이다”라는 의미로 혼동하지 마세요.

앱의 Config에서 현재 설정을 열어 이름과 내용을 확인한 다음 Home으로 돌아가 Global Routing을 살펴보세요. 로컬 파일을 저장했다고 해서 실행 중인 설정으로 적용된 것은 아닙니다. 원격 설정과 로컬 사본의 이름이 비슷할 수 있으므로 수정 전에 편집 대상이 맞는지 확인하세요. 설정이 사용자가 직접 관리하는 출처에서 제공된 경우, 이후 업데이트가 로컬 변경 사항을 덮어쓸지도 확인해야 합니다. 테스트 설정을 보존하려면 알아보기 쉬운 이름으로 사본을 먼저 저장하세요.

설정 섹션	담당 기능	혼동하면 안 되는 내용
`General`	설정 단위의 실행 매개변수	순서대로 매칭하는 규칙 목록이 아닙니다
`Rule`	조건 매칭 및 정책 선택	서버 인증 매개변수를 저장하지 않습니다
`Host`	호스트 이름과 주소의 로컬 매핑	PROXY 또는 DIRECT를 직접 지정하지 않습니다
`URL Rewrite`	표현식에 따라 요청 주소 처리	도메인 트래픽 분기와 같지 않습니다

되돌릴 수 있도록 기준 상태를 먼저 저장하세요

긴 설정 파일을 처음 관리한다면 현재 정상적으로 접속되는 대상, 선택된 서버, Global Routing을 기록하고 원본 파일을 저장하세요. 한 번의 테스트에서 DNS를 바꾸고 모든 규칙의 순서를 재배치하며 URL Rewrite까지 추가하지 마세요. 한 번에 하나씩 수정해야 결과가 달라졌을 때 원인을 파악할 수 있습니다. 설정에 주석을 남길 때는 규칙의 문구를 반복하기보다 “이 예외가 필요한 이유”를 설명하는 편이 유용합니다. 예를 들어 특정 내부 호스트에 로컬 네트워크 연결이 필요한 이유를 적어 두세요.

문법 측면에서는 영문 쉼표, 섹션 이름의 철자, 의도치 않은 줄바꿈, 복사 과정에서 들어간 전각 문자를 확인하세요. 주석은 다른 내용과 혼동되지 않도록 별도 줄에 작성하는 것이 좋습니다. 규칙을 나누어 추가하고 저장한 뒤 앱의 안내를 확인한 다음, 검증할 연결을 새로 시작하세요. 섹션별 역할을 간단히 살펴보려면 설정 파일 섹션별 역할을 참고하세요. 이 페이지의 다음 장에서는 매칭 범위와 검증 방법을 자세히 설명합니다.

02 / 적용 조건

General: 실행 매개변수와 DNS의 범위

General은 설정 단위의 실행 조건을 제공하며, 각 대상의 경로를 결정하는 Rule을 대체하지 않습니다. “같은 규칙인데 결과가 왜 다를까?”를 확인하려면 도메인 해석, 대상 주소, 현재 네트워크, 실제로 선택된 설정을 함께 점검해야 합니다. 특히 IP-CIDR 또는 GEOIP와 관련해서는 대상 주소를 확인할 수 있는지가 후속 판단에 영향을 줍니다. 규칙 한 줄만 보고 해석 과정을 살피지 않으면 전체 결과를 설명하기 어렵습니다.

최소한의 매개변수부터 살펴보세요

General의 매개변수는 키와 값의 쌍으로 작성합니다. 다른 곳에서 본 긴 매개변수 목록을 기존 파일에 통째로 붙여 넣지 마세요. 일부 설정은 해석, 네트워크 처리 또는 주소 처리 방식을 바꿀 수 있습니다. 낯선 매개변수를 확인할 때는 먼저 앱에서 설명을 확인하고, 현재 문제와 관련이 있는지 살펴보세요. 명확한 목적이 없다면 “최적화”를 위해 여러 실행 조건을 동시에 바꾸기보다 기존 상태를 유지하세요.

[General]
# 시스템에서 제공하는 DNS 해석 설정 사용
dns-server = system

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

이 예시는 DNS 설정과 Rule 섹션이 서로 독립적임을 보여 줍니다. dns-server = system은 시스템 DNS 설정을 사용한다는 뜻이지, 모든 도메인이 항상 같은 주소로 해석되거나 모든 네트워크 환경에서 결과가 같다는 뜻은 아닙니다. 네트워크 전환, DNS 캐시, 대상 서비스의 주소 분배에 따라 결과가 달라질 수 있습니다. 특정 요청을 판단할 때는 해당 시점에 확인할 수 있는 정보를 기준으로 삼으세요.

도메인 규칙과 주소 규칙에는 서로 다른 정보가 필요합니다

DOMAIN 계열 규칙에는 식별 가능한 대상 호스트 이름이 필요합니다. IP-CIDR과 GEOIP에는 주소 정보가 필요합니다. 도메인으로 시작한 요청은 도메인 규칙으로 정책을 정할 수도 있고, 이후 확인 과정에서 주소 해석이 필요할 수도 있습니다. “도메인이 특정 지역에 등록되어 있으므로 반드시 특정 GEOIP에 매칭된다”고 단정할 수는 없습니다. GEOIP는 웹사이트 이름이나 등록 정보가 아니라 주소와 데이터베이스상의 위치 정보를 기준으로 판단합니다.

주소를 해석하는 경로와 이후 서비스에 연결하는 경로는 서로 다른 문제입니다. DNS 요청이 보인다고 해서 이어지는 웹 연결도 반드시 같은 경로를 사용한다고 단정할 수 없습니다. 서비스 요청이 PROXY에 매칭되었다고 해서 모든 DNS 해석이 같은 서버를 거친다는 뜻도 아닙니다. 문제를 해결할 때는 “주소 확인”과 “대상 연결”을 별도 단계로 기록하고, 어느 단계에서 오류가 생겼는지 각각 점검하세요. 모든 시간 초과를 규칙 문제로 돌리지 마세요.

IPv4, IPv6, 캐시를 각각 확인하세요

IPv4 대역 규칙만 있다고 해서 IPv6 대상까지 처리된다고 가정하지 마세요. 연결에 실제로 IPv6를 사용했다면 IPv4 대역을 계속 넓히기보다 IP-CIDR6 및 관련 정책을 확인하세요. 같은 도메인도 요청에 따라 서로 다른 주소 계열을 사용할 수 있습니다. 설정을 검증하기 위해 특정 주소 계열을 먼저 비활성화할 필요는 없습니다. 실제 대상 주소를 기록한 뒤 해당 주소에 적용되는 규칙을 확인하세요.

캐시와 기존 연결 때문에 설정 변경이 관찰 결과에 즉시 나타나지 않을 수 있습니다. 앱, 브라우저, 네트워크 계층이 각각 정보를 보관할 수 있고, 연결을 저장해도 장기 연결이 자동으로 다시 설정되는 것은 아닙니다. 변경 후에는 설정이 계속 선택된 상태인지 확인하고 테스트 대상의 기존 세션을 종료하거나 새 요청을 시작하세요. 재연결 여부는 변경한 설정과 앱 안내에 따라 다르므로 연결을 반복해서 전환하는 것만으로 문제를 해결하려 하지 마세요.

시스템 네트워크 상태는 규칙 자체와 별개입니다

로컬 네트워크 로그인 필요, 무선 네트워크에서 대상에 접속할 수 없음, 서버 호스트 이름 해석 실패 등의 문제로 문법상 올바른 설정도 작동하지 않을 수 있습니다. 이때 DOMAIN-SUFFIX를 더 추가해도 기본 연결 문제는 해결되지 않습니다. 먼저 기기가 사용 가능한 네트워크에 연결되었는지 확인하고, 사용자가 보유한 서버의 연결 가능 여부와 인증 정보를 살펴본 다음 서비스 대상의 트래픽 분기를 검증하세요. 이 순서대로 확인하면 규칙 문제와 네트워크 문제를 구분할 수 있습니다.

General을 관리할 때는 변경 전후의 네트워크 유형, DNS 설정, 테스트 대상을 함께 기록하되 실제 인증 정보는 남기지 않는 것이 좋습니다. 특정 네트워크에서만 문제가 발생한다면 다른 네트워크를 비교 대상으로 삼아 하나씩 비교하세요. 권한과 최초 실행 단계는 시작하기를 참고하고, Global Routing 모드 선택은 라우팅 모드 안내를 확인하세요. 확인되지 않은 서버 또는 권한 문제를 실행 매개변수로 보완하려 하지 마세요.

03 / 호스트 이름 매칭

DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD

도메인 규칙은 “이 호스트 또는 호스트 그룹에 어떤 정책을 적용할까?”를 지정하는 데 적합합니다. 세 가지 주요 형식은 우열이 아니라 적용 범위가 다릅니다. 정확한 예외에는 DOMAIN을, 루트 도메인과 하위 도메인을 포함하려면 DOMAIN-SUFFIX를 고려하세요. 이름의 일부를 폭넓게 매칭해야 할 때만 DOMAIN-KEYWORD를 사용하세요. 범위가 넓을수록 의도치 않은 매칭이 없는지 더 꼼꼼히 확인해야 합니다.

DOMAIN: 단일 호스트에 명확한 예외 설정

DOMAIN,api.example.com,PROXY는 완전한 호스트 이름을 대상으로 하며, 이름에 example이 포함되었다고 다른 호스트까지 자동으로 포함하지 않습니다. 규칙 필드에는 프로토콜, 경로, 쿼리 매개변수, 포트를 붙이지 않고 호스트 이름만 작성하세요. https://api.example.com/login 전체를 DOMAIN에 입력해도 “로그인 페이지만 프록시 사용”을 뜻하지 않습니다. 경로 처리는 다른 영역의 기능이므로 URL Rewrite가 실제로 필요한지 먼저 판단해야 합니다.

[Rule]
# 단일 호스트의 정확한 예외
DOMAIN,api.example.com,PROXY
DOMAIN,intranet.example.com,DIRECT
FINAL,DIRECT

이 형식은 작은 범위부터 시험할 때 적합합니다. 단일 호스트에 올바른 정책이 적용되는지 확인한 뒤 같은 서비스의 다른 도메인으로 확대할지 결정하세요. 한 페이지에서 API, 이미지, 인증 등에 여러 호스트를 사용할 수 있으므로 “메인 페이지가 매칭됨”이 관련 요청 모두에 적용된다는 뜻은 아닙니다. 페이지 일부가 로드되지 않으면 도메인 전체에 같은 정책을 적용하기 전에 실패한 리소스의 실제 호스트 이름을 확인하세요.

DOMAIN-SUFFIX: 도메인 계층 기준으로 적용

DOMAIN-SUFFIX,example.com,PROXY는 example.com과 api.example.com 같은 하위 도메인에 적용됩니다. 임의의 문자열 끝을 매칭하는 것이 아니라 도메인 접미사 관계를 기준으로 합니다. 따라서 notexample.com은 example.com의 하위 도메인이 아닙니다. 보통 필드 앞에 별표를 추가할 필요도 없습니다. 이를 이해하면 와일드카드 표기와 규칙 자체의 매칭 방식을 혼동하지 않을 수 있습니다.

접미사 규칙은 적용 범위가 넓으므로 추가하기 전에 해당 도메인 아래에 직접 연결해야 하는 내부 서비스가 있는지 확인하세요. 내부 관리 호스트와 공개 API가 같은 루트 도메인을 사용한다면 내부 호스트의 정확한 DIRECT 예외를 루트 도메인의 PROXY 접미사 규칙보다 먼저 작성하세요. 순서를 반대로 하면 내부 호스트가 위쪽 규칙에 먼저 매칭되어 뒤의 정확한 예외로 결과를 바꿀 수 없습니다.

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

DOMAIN-KEYWORD: 이름 조각에 따라 범위 결정

DOMAIN-KEYWORD,ads,REJECT는 도메인에 포함된 키워드로 매칭하며, 단어의 의미를 이해하거나 해당 요청이 실제 광고인지 판별하지 않습니다. 호스트 이름에 지정한 문자열이 들어 있으면 범위에 포함될 수 있습니다. 짧은 키워드일수록 정상 서비스까지 잘못 차단할 가능성이 큽니다. 예시는 문법 설명용이며 모든 네트워크 환경에 적합한 차단 권고가 아닙니다. 실제 관리에는 확인된 정확한 호스트나 접미사 규칙을 우선 사용하세요.

규칙 유형	필드 예시	매칭 범위
`DOMAIN`	`api.example.com`	지정한 전체 호스트 이름
`DOMAIN-SUFFIX`	`example.com`	루트 도메인과 하위 도메인
`DOMAIN-KEYWORD`	`ads`	호스트 이름에 포함된 문자열

키워드가 포함된 정상 호스트를 유지해야 한다면 키워드 규칙보다 정확한 예외를 먼저 배치하세요. 예외가 계속 늘어난다면 패치를 무한정 추가하기보다 키워드 범위가 지나치게 넓지 않은지 다시 살펴보세요. 규칙 관리의 목표는 조건과 요구 사항을 일치시키는 것이지, 범위가 너무 넓은 규칙이 수많은 예외에 의존하도록 만드는 것이 아닙니다. 가독성과 검증 비용도 규칙을 선택할 때 고려하세요.

도메인이 보이지 않을 때는 추측으로 규칙을 추가하지 마세요

모든 연결에서 예상한 호스트 이름을 확인할 수 있는 것은 아닙니다. 주소로 직접 접속하거나 요청이 다른 중간 처리 과정을 거치거나 연결 정보가 부족하면 생각한 대로 도메인 조건에 매칭되지 않을 수 있습니다. 이때는 먼저 앱에서 확인할 수 있는 대상 정보를 살펴보고 주소 규칙이 필요한지 판단하세요. 브라우저 주소창에 이름이 표시된다고 해서 해당 페이지가 만든 모든 연결에 같은 매칭용 도메인이 포함된다고 가정하지 마세요.

마지막으로 도메인 필드와 코드 예시에는 영문 쉼표를 사용합니다. 호스트가 여러 개라면 한 필드에 몰아넣지 말고 규칙을 각각 작성하세요. 국제화 도메인이나 이름 형식에 차이가 있다면 실제 요청에서 확인할 수 있는 형식으로 테스트하세요. DOMAIN, FINAL 같은 키워드의 간단한 설명은 용어 설명에서 확인할 수 있습니다. 이 장에서는 적용 범위와 예외 관계를 판단하는 방법을 다룹니다.

04 / 주소 및 요청 속성

IP-CIDR, GEOIP, USER-AGENT

대상 주소, 대역 또는 요청 속성을 기준으로 처리해야 한다면 도메인 규칙이 가장 적합한 도구가 아닐 수 있습니다. IP-CIDR은 IPv4 주소 집합을, IP-CIDR6은 IPv6 주소 집합을 나타냅니다. GEOIP는 주소 위치 데이터베이스를 기준으로 분류합니다. USER-AGENT는 확인 가능한 요청 헤더 정보에 따라 매칭합니다. 각 규칙에 필요한 입력 정보가 다르므로 도메인 규칙의 다른 표기 정도로 여겨서는 안 됩니다.

IP-CIDR: 접두사로 주소 집합 표현

192.168.0.0/16은 IPv4 주소 대역을 나타냅니다. 슬래시 뒤 숫자는 포트가 아니라 네트워크 접두사 길이입니다. 접두사 길이가 길수록 적용 범위는 좁아집니다. IPv4 주소 하나는 /32로 표현할 수 있습니다. 규칙을 작성하기 전에 실제 대상 주소를 확인하고 서버 주소, 기기 자체 주소, 서비스 대상 주소를 혼동하지 마세요. 일반적인 대상 트래픽 분기 규칙은 요청의 대상 주소를 확인합니다.

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
FINAL,PROXY

위 예시는 사설 주소 대역 표기법을 보여 줄 뿐, 모든 로컬 서비스에 접속할 수 있게 해 주지는 않습니다. 기기가 연결된 네트워크의 경로 설정, 서버의 수신 주소, 방화벽, 앱의 우회 설정 등이 결과에 영향을 줄 수 있습니다. 규칙 처리 전에 이미 제외된 일부 트래픽은 해당 항목을 거치지 않습니다. 내부 서비스 문제를 해결할 때는 기기 자체에서 해당 주소에 실제로 접속할 수 있는지도 확인해야 합니다.

no-resolve: 이 규칙을 위해 해석을 직접 요청하지 않음

주소 규칙 끝에 붙는 no-resolve는 해당 규칙의 매칭을 위해 도메인을 직접 해석하지 않도록 합니다. 설정 전체의 DNS를 끄거나 이미 확보한 주소 정보를 무시한다는 뜻은 아닙니다. 호스트 이름만 있고 사용할 주소를 아직 얻지 못한 요청은 이 옵션이 붙은 주소 규칙에 매칭되지 않을 수 있습니다. 요청은 뒤의 규칙으로 계속 처리되므로 적절한 도메인 규칙과 FINAL이 여전히 필요합니다.

로컬 대역 규칙에 이 옵션을 사용하는 일반적인 목적은 사설 대역 확인만을 위해 다수의 일반 도메인을 추가로 해석하지 않도록 하는 것입니다. 기존 설정에 적합한지는 요청 정보와 해석 방식에 따라 판단해야 합니다. 내부 도메인을 직접 연결해야 한다면 주소 규칙에서 우연히 필요한 정보를 얻기를 기대하기보다 명확한 DOMAIN 규칙을 추가하고 현재 네트워크에서 해당 이름이 올바르게 해석되는지 확인하세요.

GEOIP: 데이터베이스상의 주소 위치는 서비스 신원을 뜻하지 않습니다

GEOIP,CN,DIRECT는 대상 주소의 데이터베이스상 위치 정보를 기준으로 정책을 선택합니다. 웹페이지 언어, 도메인 접미사, 사용자의 현재 위치를 기준으로 판단하지 않으며, 대상 서비스를 어떤 기관이 운영하는지 증명하지도 않습니다. 주소 위치 데이터에는 갱신 및 경계상 차이가 있고, 같은 서비스가 여러 지역의 주소를 사용할 수도 있습니다. 따라서 GEOIP는 넓은 범위의 분류 조건으로 사용하고 신원 확인 수단으로 삼지 않는 것이 좋습니다.

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

이 순서에서는 명시된 호스트가 먼저 PROXY를 사용하고, 나머지 요청은 GEOIP를 확인합니다. 범위가 넓은 주소 분류를 앞에 두면 조건을 충족한 요청이 먼저 처리되어 뒤에 있는 도메인 예외가 적용되지 않을 수 있습니다. 특정 서비스의 경로를 안정적으로 지정하려면 먼저 확인 가능한 호스트 이름으로 요구 사항을 표현한 다음 GEOIP를 보조 조건으로 사용하는 편이 이해하고 관리하기 쉽습니다.

USER-AGENT: 필요한 정보가 사용 가능한지 먼저 확인

USER-AGENT는 USER-AGENT,ExampleClient*,DIRECT처럼 확인 가능한 요청 헤더 내용을 기준으로 패턴을 매칭합니다. 여기서 ExampleClient는 설명용 클라이언트 식별자이며 실제 앱을 가리키지 않습니다. 앱 이름을 기준으로 트래픽을 분기하는 것과 같지 않습니다. 기기에 특정 앱이 설치되어 있다고 해서 해당 앱의 모든 트래픽이 같은 요청 헤더 패턴에 매칭된다고 추정할 수 없습니다.

HTTPS는 요청 내용을 암호화하므로 규칙 처리 과정에서 User-Agent를 읽지 못할 수 있습니다. 일부 요청에는 이 필드가 없거나 앱에 따라 값이 달라질 수도 있습니다. 일반적인 트래픽 분기를 확인하기 위해 복호화 관련 설정 범위를 넓히지 마세요. 알려진 도메인으로 대상을 정확히 지정할 수 있다면 도메인 규칙을 우선 사용하세요. USER-AGENT가 반드시 필요하다면 앱에서 해당 정보를 확인할 수 있는지 먼저 점검하고, 매칭되지 않은 요청을 처리할 명확한 기본 정책도 유지하세요.

05 / 트래픽 경로

PROXY, DIRECT, REJECT와 Global Routing

규칙의 정책은 “매칭된 뒤 어떻게 처리할까?”에 답하고, Global Routing은 “현재 어떤 전체 라우팅 방식을 사용할까?”를 결정합니다. 두 설정은 서로 다른 계층에 있습니다. Rule이 적용되지 않는 문제를 확인할 때는 먼저 Global Routing이 Config로 설정되어 있는지 살펴보세요. 현재 Proxy 또는 Direct를 사용 중이라면 Config에 있는 일반 규칙의 순서만으로 같은 요청의 결과를 설명할 수 없습니다. 정책을 살피기 전에 먼저 모드를 확인하세요.

기본 정책 세 가지의 역할

PROXY는 처리 대상에 포함된 요청을 프록시 경로로 보냅니다. 연결 가능 여부는 사용자가 보유한 서버의 상태와 관련 설정에 따라 달라집니다. DIRECT는 선택한 프록시 서버를 거치지 않고 직접 연결하지만 대상에 반드시 접속할 수 있다는 뜻은 아닙니다. REJECT는 조건에 맞는 요청을 거부하며, 실패한 뒤 다른 경로로 자동 전환하지 않습니다. 세 정책은 각각 구체적인 요구 사항에 맞게 사용해야 합니다.

정책	처리 방식	자주 하는 오해
PROXY	프록시 경로 사용	매칭되었다고 서버를 사용할 수 있다는 뜻은 아닙니다
DIRECT	직접 연결 경로 사용	직접 연결도 네트워크 상태의 영향을 받을 수 있습니다
REJECT	매칭된 요청 거부	DIRECT로 자동 전환되지 않습니다

파일에서는 기본 정책을 대문자로 작성해 인터페이스의 Config, Proxy, Direct와 구분하기 쉽게 합니다. 기존 설정에서 사용자 지정 정책 이름을 사용한다면 해당 이름이 정의되어 있는지, 어떤 서버 또는 선택 로직을 가리키는지 함께 확인하세요. 이 문서의 최소 예시에는 기본 정책 세 가지만 사용합니다. 사용자가 이미 사용자 지정 그룹을 만들어 두었다고 가정하지 않으며, 기본적인 트래픽 분기를 위해 복잡한 구조를 추가하도록 요구하지도 않습니다.

Config, Proxy, Direct 비교

Global Routing의 Config는 선택한 설정의 규칙에 따라 트래픽을 분기합니다. Proxy는 처리 대상으로 지정된 트래픽에 프록시 방식을 사용하고, Direct는 직접 연결 방식을 사용합니다. 여기서 “전체”는 모든 시스템 제한을 우회해 기기에서 발생할 수 있는 모든 트래픽을 처리한다는 뜻이 아닙니다. 실제 동작은 시스템, 앱의 처리 범위, 관련 설정의 영향을 받습니다. 이는 앱 내 라우팅 선택이며 연결 성공을 보장하지 않습니다.

평소 내부 서비스는 직접 연결하고 지정한 대상은 프록시를 사용해야 한다면 Config에서 두 동작을 구분하는 것이 적합합니다. Proxy로 잠시 전환하면 프록시 경로를 사용할 수 있는지 확인할 수 있고 Direct로 전환하면 직접 연결을 비교해 볼 수 있습니다. 하지만 두 방식 모두 진단 수단일 뿐 규칙을 수정한 것은 아닙니다. 테스트가 끝나면 필요한 모드로 되돌리세요. 그렇지 않으면 이후 관찰 결과가 원래 설정의 설계 목적과 달라집니다.

FINAL은 매칭되지 않은 요청의 처리를 결정합니다

FINAL,PROXY는 앞선 규칙에 매칭되지 않은 요청을 최종적으로 PROXY로 처리하고, FINAL,DIRECT는 DIRECT를 선택합니다. 도메인이나 대역 필드는 없으므로 일반 조건 규칙처럼 필드 세 개를 작성하지 마세요. FINAL에 도달한 요청은 모두 기본 처리되기 때문에 뒤에 있는 조건 규칙이 더 이상 영향을 주지 않습니다. 따라서 FINAL은 규칙 목록 맨 끝에 배치해야 합니다.

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

이 예시는 명시적으로 나열하지 않은 대상을 DIRECT로 처리하지만, 이 기본 정책이 모든 사용자에게 적합하다는 뜻은 아닙니다. FINAL을 선택할 때는 먼저 설정의 기본 처리 원칙을 정하고 예외 규칙을 추가하세요. 기본 처리 방식을 바꾸면 명시되지 않은 여러 대상에 영향을 주므로 단일 DOMAIN 변경보다 넓은 범위를 검증해야 합니다. 이미 명시적으로 매칭되는 도메인 하나만 테스트하고 새 FINAL까지 확인했다고 판단하지 마세요.

연결 상태, 정책 매칭, 서비스 성공은 따로 판단하세요

시스템에 연결 완료로 표시되어도 해당 연결 상태만 확인된 것이며 모든 대상에 접속할 수 있다는 뜻은 아닙니다. 규칙이 PROXY에 매칭되어도 선택한 처리 경로가 확인된 것일 뿐, 이후 인증 실패, 연결 시간 초과, 대상의 거부가 발생할 수 있습니다. Connectivity Test는 연결 상태를 참고하는 수단이지만 특정 서비스 요청의 규칙 매칭을 대신 확인하지는 않습니다. 세 항목을 각각 기록해 테스트 결과를 서로 대체하지 않도록 하세요.

앱을 구매하려면 먼저 App Store 정품 확인에서 개발자와 앱 ID를 확인하세요. Shadowrocket은 Apple 플랫폼용 유료 클라이언트이며 App Store에서만 받을 수 있습니다. 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 하세요. 앱 구매와 사용자가 보유한 서버는 별개이며, 클라이언트 일회 구매와 회선 구독은 다릅니다. 모드별 설명은 Global Routing 세 가지 모드의 차이를 참고하세요.

06 / 우선순위

매칭 순서: 먼저 매칭된 규칙이 결과를 결정합니다

규칙 목록은 순서대로 확인하며, 일반적으로 처음 매칭된 규칙이 정책을 결정합니다. DOMAIN이 DOMAIN-SUFFIX보다 자동으로 우선한다고 가정하지 마세요. 더 구체적인 대역이 앞에 있는 넓은 조건을 자동으로 덮어쓴다고 생각해서도 안 됩니다. 조건의 구체성은 순서를 정할 때 참고할 요소일 뿐, 파일 순서와 별개인 우선순위 체계가 아닙니다. 결과를 예측하려면 규칙 목록 맨 위부터 한 줄씩 확인하세요.

정확한 예외를 범위 규칙보다 먼저 작성하세요

example.com과 하위 도메인은 PROXY를 사용하되 intranet.example.com은 DIRECT로 연결해야 한다고 가정해 보겠습니다. 두 규칙을 단순히 함께 넣는 것만으로는 충분하지 않습니다. 내부 호스트의 정확한 조건을 먼저 배치해야 합니다. intranet.example.com도 example.com의 하위 도메인이므로 접미사 규칙이 앞에 있으면 먼저 매칭됩니다. 뒤의 정확한 조건이 올바르게 작성되어도 결과를 바꿀 수 없습니다.

# 예외를 먼저 배치
[Rule]
DOMAIN,intranet.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

목록의 두 줄 순서만 바뀌어도 동작은 달라집니다. 따라서 문제를 해결할 때 “해당 규칙이 있는가”만 검색해서는 안 됩니다. 규칙이 존재해도 실행될 기회가 없을 수 있습니다. 대상을 찾은 뒤에는 위쪽에서 영향을 줄 수 있는 키워드, 도메인 접미사, 주소 분류, 앞서 배치된 FINAL을 확인하세요. 위에서 먼저 매칭되는 규칙이 하나라도 있으면 대상 규칙이 실행되지 않을 수 있습니다.

서로 다른 규칙 유형도 같은 순서를 따릅니다

도메인 규칙과 주소 규칙은 서로 독립된 두 목록이 아닙니다. 같은 Rule 섹션에 있다면 조건마다 필요한 정보는 달라도 실제로 배치된 순서에 따라 확인해야 합니다. 앞선 도메인 조건에 이미 매칭되었다면 뒤의 GEOIP가 결과를 바꾸기를 기대할 필요가 없습니다. 앞선 주소 조건에 매칭되면 뒤에 있는 도메인 예외가 적용되지 않을 수도 있습니다. 주소 해석이 관련된 경우에는 두 번째 장에서 설명한 주소 정보의 범위도 함께 고려하세요.

“구체적인 조건부터 넓은 조건 순”은 규칙을 정리하는 방식으로 활용할 수 있습니다. 명시적인 호스트 예외, 도메인 범위, 필요한 주소 대역, 넓은 분류 조건, 마지막으로 FINAL을 배치하는 식입니다. 하지만 반드시 그대로 따라야 하는 고정 템플릿은 아닙니다. 확인된 특정 호스트의 연결을 거부해야 한다면 정확한 REJECT를 해당 도메인의 허용 접미사 규칙보다 앞에 두어야 할 수도 있습니다. 순서는 정책의 우선 관계에 따라 정해야 하며 색상으로 결정되지 않습니다.

중복되거나 충돌하는 규칙 정리 방법

같은 조건과 같은 정책이 두 번 있으면 뒤의 항목은 대개 읽기만 번거롭게 합니다. 같은 조건에 서로 다른 정책이 있다면 먼저 매칭된 항목이 실제 결과를 결정합니다. 정리할 때는 어느 곳에서 중복되었는지 확인한 다음 유지할 항목을 고르세요. 단순히 오래되어 보이는 줄을 삭제하지 마세요. 업데이트에서 가져온 규칙일 수 있으므로 출처를 확인하지 않으면 다음 업데이트 때 다시 나타날 수 있습니다.

적용 범위가 겹치는 것이 항상 오류는 아닙니다. 정확한 예외와 접미사 규칙이 겹치는 것은 의도된 구성일 수 있지만 우선순위를 설명할 수 있어야 합니다. 목적을 설명하기 어려운 중복은 설정을 여러 번 합친 결과일 가능성이 높습니다. 정리할 때는 먼저 요구 사항별로 그룹을 나누고 각 그룹에 예외 이유를 적어 두세요. 호스트 이름의 알파벳순으로만 정렬하면 위아래 순서에 따라 달라지던 동작이 바뀔 수 있습니다.

테스트 행렬로 각 분기를 확인하세요

위 예시를 검증할 때는 최소한 세 종류의 대상을 준비하세요. 정확한 예외 호스트, 같은 도메인의 일반 호스트, 해당 도메인과 무관한 호스트입니다. 각각 DIRECT 예외, PROXY 적용 범위, FINAL을 확인합니다. 접미사에 포함되지 않지만 비슷한 호스트 이름도 추가해 매칭 경계를 잘못 이해하지 않았는지 확인하세요. 예시 호스트가 실제 서비스를 제공할 필요는 없지만 실제 연결 테스트에는 사용자가 존재를 확인한 대상을 사용해야 합니다.

테스트할 때 대상, 예상 매칭 조건, 예상 정책, 실제 결과, 실패 단계를 기록하세요. 예상한 규칙에 매칭되지 않았다면 먼저 앞에서 덮어쓰는 조건이 있는지 확인하세요. 규칙에 매칭되었지만 요청이 실패했다면 경로와 대상 서비스를 점검하세요. 순서를 변경한 뒤에는 기존 세션의 영향을 피하도록 테스트 연결을 새로 시작하세요. 이런 기록은 비슷한 규칙을 계속 추가하는 것보다 문제를 재현하기 쉽고, 설정 업데이트 후 다시 검증할 때도 유용합니다.

07 / 매핑과 주소 변경

Host 및 URL Rewrite: 트래픽 분기 규칙을 대신하지 않습니다

Host는 지정된 이름에 대응하는 주소를 바꾸고, URL Rewrite는 표현식과 일치하는 요청 주소를 처리합니다. Rule은 어떤 정책을 적용할지 결정합니다. 세 기능은 같은 파일에 있을 수 있지만 서로 대체할 수는 없습니다. 특정 호스트에 DIRECT가 필요하다면 보통 분기 조건을 먼저 명확히 작성해야 합니다. 직접 연결을 위해 호스트를 임의의 고정 주소에 매핑하거나, URL Rewrite로 접속 대상을 무관한 서비스로 바꾸지 마세요.

Host는 해석 관계를 고정합니다

예를 들어 test.example.com = 192.0.2.10은 호스트 이름을 주소에 정적으로 매핑하는 방법을 보여 줍니다. 이 주소는 문서 예시용이며 실제로 접속할 수 있는 서비스가 아닙니다. Host 항목에는 PROXY, DIRECT, REJECT 필드가 없습니다. 이후 연결에 어떤 정책을 적용할지는 Rule과 실제 요청 정보를 함께 살펴봐야 합니다. 주소 매핑 성공과 트래픽 분기 성공을 같은 것으로 여기면 문제의 원인을 놓칠 수 있습니다.

[Host]
test.example.com = 192.0.2.10

[Rule]
DOMAIN,test.example.com,DIRECT
FINAL,PROXY

정적 매핑은 사용자가 직접 관리하는 테스트 환경처럼 제한된 경우에 적합합니다. 공개 서비스는 동적 주소, 부하 분산, 장애 전환을 사용할 수 있습니다. 주소를 장기간 고정하면 연결이 끊기거나 네트워크 변화에 따라 이뤄지던 기존 분산 처리를 우회할 수 있습니다. 주소의 소유 관계, 용도, 관리 책임을 확인할 수 있는 경우에만 매핑을 추가하고 해제 조건도 기록하세요. 한 번 해석에 성공한 주소를 설정에 영구적으로 저장하지 마세요.

매핑은 인증서와 서비스 신원 확인을 없애지 않습니다

호스트를 다른 주소에 매핑해도 해당 주소의 서비스가 원래 호스트의 신원을 갖게 되는 것은 아닙니다. HTTPS에서는 인증서와 요청 호스트를 확인합니다. 대상 서비스에 해당 호스트 설정이 없으면 인증서 불일치나 서비스 요청 거부가 발생할 수 있습니다. 이런 오류를 무시해 “매핑이 성공했다”고 판단하지 마세요. 주소, 호스트, 서비스 설정이 서로 일치하는지 다시 확인해야 합니다.

매핑 결과와 접속 동작이 다르면 앱이 실제로 해당 해석 정보를 사용했는지, 기존 연결에 이전 주소가 남아 있는지, 요청이 다른 방식으로 주소를 얻었는지도 확인하세요. 단일 매핑을 잠시 제거해 비교한 다음 복원하고 연결을 새로 시작하세요. Host 때문에 차이가 발생했다고 확인한 뒤 주소 규칙과의 상호 작용을 검토해야 합니다. 매핑과 트래픽 분기를 동시에 변경하면 원인을 찾기 어렵습니다.

URL Rewrite의 세 가지 구성 요소

일반적인 리디렉션 형식은 매칭 표현식, 대체 대상, 상태 코드로 구성되며 필드 사이에는 해당 문법의 구분자를 사용합니다. 다음 예시는 특정 호스트의 HTTP 접두사를 HTTPS 접두사로 바꾸고 302를 사용합니다. 표현식에서 마침표는 임의의 문자로 해석되지 않도록 역슬래시로 이스케이프합니다. 시작 부분의 ^는 요청 주소의 첫 위치부터 매칭하도록 제한해 불필요한 오매칭을 줄입니다.

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

이 예시는 문법만 설명하며 웹사이트 자체의 올바른 HTTPS 설정을 대신하지 않습니다. 매칭 범위에 슬래시 위치가 포함되므로 경로 슬래시가 없거나 포트 또는 호스트가 다른 입력은 같은 결과를 내지 않을 수 있습니다. 테스트할 때는 홈페이지, 경로가 포함된 요청, 쿼리 매개변수가 포함된 요청을 각각 확인해 대체 결과가 예상에 맞는지 살펴보세요. 표현식의 범위가 넓을수록 매칭되지 않아야 할 입력도 함께 테스트해야 합니다.

리디렉션 반복과 확인 범위를 벗어난 변경을 피하세요

한 번 변경된 주소가 다른 Rewrite 규칙에 다시 매칭되면 리디렉션이 반복되거나 두 주소 사이에서 순환할 수 있습니다. 규칙을 추가하기 전에 원래 주소, 첫 번째 대체 결과, 이후 매칭될 가능성이 있는 조건을 적어 두세요. 브라우저가 리디렉션 결과를 캐시할 수 있으므로 디버깅할 때 이를 고려하고 캐시된 이동을 현재 설정이 계속 적용되는 결과로 오해하지 마세요. 규칙을 되돌린 후에도 새 요청으로 다시 검증해야 합니다.

암호화된 요청의 경로가 규칙 처리 과정에서 자동으로 보이는 것은 아닙니다. URL Rewrite로 임의의 HTTPS 내용을 모두 변경할 수 있다고 보장하지 않습니다. 이 페이지는 일반적인 트래픽 분기를 위해 추가 복호화 기능을 요구하지 않습니다. 트래픽 경로만 바꾸려면 Rule을, 이름에 대응하는 주소를 확인하려면 Host를 살펴보세요. 요청 주소를 실제로 관리해야 하는 경우에 URL Rewrite를 사용하세요. 이 세 영역의 역할을 구분하면 문제가 발생했을 때 담당 부분을 빠르게 찾을 수 있습니다.

08 / 검증과 유지 관리

설정 검증: 최소 규칙에서 되돌릴 수 있는 관리까지

설정 검증의 목표는 한 번 접속에 성공하는 것이 아니라, 예상한 조건에서 예상한 규칙이 설명 가능한 결과를 내는지 확인하는 것입니다. 전체 과정에는 원본 설정 저장, 실행 모드 확인, 한 항목 수정, 새 요청 생성, 매칭과 연결 결과 확인, 기록 및 복원 계획 보관이 포함됩니다. 각 단계를 나누면 잘못 판단할 가능성을 줄이고, 이후 구독이나 설정을 업데이트한 뒤에도 빠르게 다시 확인할 수 있습니다.

1단계: 실제로 실행 중인 항목 확인

먼저 Home에서 연결 상태, 현재 선택한 서버, Global Routing을 확인한 뒤 Config에서 사용 중인 파일을 살펴보세요. 파일 이름이 같거나 비슷하면 이름만 믿지 말고 내용을 직접 확인하세요. 사용자가 보유한 서버 매개변수는 본인의 정보 출처와 일치해야 합니다. 규칙을 검증하면서 프로토콜, 포트, 인증 필드까지 함께 바꾸면 연결 결과의 원인을 파악하기 어렵습니다.

사용할 수 있는 연결을 만든 적이 없다면 먼저 시작하기를 완료하세요. 많은 규칙과 URL Rewrite가 포함된 설정을 바로 가져오지 마세요. 앱 구매 및 구입 항목 복원 문제는 Rule을 수정하지 말고 구매 복원 안내를 확인하세요. App Store에서 확인할 수 있는 개발자 이름은 Shadow Launch Technology Limited이고 앱 ID는 932747118입니다. 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 하세요.

2단계: 설명 가능한 최소 설정으로 줄이기

문제가 발생하면 원본 파일을 보관하고 사본에는 테스트 대상과 관련된 조건, 명확한 FINAL만 남기세요. 먼저 정확한 DOMAIN을 검증한 뒤 접미사, 주소 분류, Host, URL Rewrite를 차례대로 복원하세요. 사용 가능한 유일한 설정을 바로 삭제하거나 테스트 사본을 원격 원본에 덮어쓰지 마세요. 최소화는 다른 요인의 영향을 배제하기 위한 것이며, 평소에도 규칙을 두세 개만 사용하라는 뜻은 아닙니다.

[Rule]
# example.com을 사용자가 존재를 확인한 테스트 호스트로 바꾸세요
DOMAIN,example.com,PROXY
FINAL,DIRECT

이 구조로 테스트할 때는 DOMAIN에 명확히 매칭되는 대상 하나와 매칭되지 않아 FINAL을 확인할 대상 하나를 선택하세요. 두 대상의 결과가 모두 예상과 다르면 먼저 Config를 사용 중인지, 테스트 사본이 선택되었는지 확인하세요. PROXY 대상만 실패하면 프록시 경로를 따로 점검하고 DIRECT 대상만 실패하면 현재 네트워크에서 해당 대상에 직접 연결할 수 있는지 확인하세요. 실패 결과 하나만으로 설정 문법 전체가 잘못되었다고 판단하지 마세요.

3단계: 흔한 오류 네 가지 구분하기

증상	먼저 확인할 항목	다음 단계
규칙이 매칭되지 않음	설정 선택 여부, 모드, 위쪽에서 덮어쓰는 조건	대상 정보를 확인하고 규칙을 최소화하세요
매칭되지만 시간 초과 발생	선택된 경로, 서버, 대상의 연결 가능 여부	연결 경로를 각각 테스트하세요
일부 리소스만 실패	실패한 리소스의 실제 호스트와 정책	관련 요청을 하나씩 확인하세요
수정 후에도 이전 결과가 나타남	기존 연결, 캐시, 설정 선택 상태	새 요청을 시작한 뒤 다시 확인하세요

앱에서 확인할 수 있는 연결 기록이나 로그를 통해 대상, 정책, 실패 단계를 확인할 수 있습니다. 구체적인 표시 방식은 현재 앱 화면을 기준으로 하세요. 기록에 주소만 보인다고 임의로 도메인을 덧붙이지 마세요. 도메인만 있고 주소가 없다면 특정 대역에 속한다고 단정하지 마세요. Connectivity Test는 연결 상태 판단에 도움이 되지만 실제 웹페이지나 API 요청은 별도로 실행해 검증해야 합니다.

4단계: 업데이트 덮어쓰기와 규칙 회귀 처리

구독 업데이트와 설정 업데이트는 따로 확인해야 합니다. 기존 서버 항목을 업데이트해도 현재 Rule이 반드시 바뀌는 것은 아닙니다. 원격 설정을 업데이트하면 로컬에서 수정한 내용이 다시 정렬되거나 대체될 수 있습니다. 업데이트 후에는 최소한 정확한 예외, 일반적인 범위, FINAL에 해당하는 대상 세 가지를 다시 테스트하세요. Host나 URL Rewrite가 있다면 매핑 대상과 리디렉션 경계도 확인해야 합니다. 메인 페이지가 열린다는 이유만으로 관리를 끝내지 마세요.

관리 기록에는 변경 이유, 기존 규칙, 새 규칙, 예상 결과, 실제 결과를 포함할 수 있지만 전체 구독 주소, 인증 정보, 기타 민감한 내용은 넣지 마세요. 다른 사람에게 문제를 설명해야 한다면 실제 호스트와 인증 정보를 먼저 바꾸되 규칙 순서, 필드 구조, 필요한 오류 정보는 유지하세요. 비밀번호만 지우고 인증 매개변수가 포함된 구독 주소를 남겨도 사용자의 접근 권한이 노출될 수 있습니다.

규칙을 저장했는데 왜 변화가 보이지 않나요?

먼저 선택된 설정과 Global Routing을 확인한 다음 기존 연결과 캐시를 살펴보세요. 테스트 요청을 새로 시작하고 위쪽에서 먼저 매칭되는 규칙이 있는지 확인하세요. 새 항목이 존재하는지만 확인해서는 안 됩니다.

PROXY에 매칭되면 설정이 모두 올바르다는 뜻인가요?

해당 요청에 그 정책이 선택되었다는 점만 확인됩니다. 서버 연결, 인증, 주소 해석, 대상 서비스에서 여전히 오류가 발생할 수 있습니다. 다른 규칙 분기와 매칭되지 않은 요청에 적용되는 FINAL도 확인해야 합니다.

마지막으로 검증을 마친 뒤 되돌릴 수 있는 설정을 보관하고 불필요하다고 확인된 테스트 항목을 정리하세요. 규칙이 많다고 결과가 더 안정적인 것은 아닙니다. 각 조건의 목적, 순서, 검증 방법을 설명할 수 있어야 장기적으로 관리하기 쉽습니다. 최초 연결 과정을 다시 확인하려면 기본 서버 선택 및 Connectivity Test 검증을 참고하세요. 용어를 빠르게 확인하려면 용어 설명에서 키워드로 찾아보세요.