CONFIG / RULE / POLICY

Shadowrocket 규칙·Config 설정 가이드 총정리

이 페이지는 Shadowrocket 공식 매뉴얼의 설정 참고 자료로, Config 구조와 규칙 매칭 기준, 문제 원인 파악에 중점을 둡니다. 구독을 처음 가져와 연결하려면 먼저 사용법을 확인하세요. 기본 연결을 마친 다음 이 페이지의 목차를 참고해 규칙을 조정하면 됩니다.

모든 예시는 문법 설명을 위한 것이며, 도메인과 주소는 교육용 값입니다. 작업 전에 본인 소유의 구독 또는 서버 정보를 준비하고, 현재 정상 작동하는 Config를 보관하세요.

1. Config 파일 구조와 설정 범위

서버 정보, 구독, Config 파일 구분하기

Shadowrocket에서 서버 정보, 구독, Config 파일은 각각 다른 역할을 합니다. 서버 항목에는 연결 대상의 주소, 포트, 인증 정보와 프로토콜 매개변수가 들어갑니다. 구독은 사용자가 이미 보유한 서버 항목을 일괄 관리하는 데 쓰이며, Config 파일은 요청을 해석하고 매칭해 처리하는 규칙을 구성합니다. 세 가지가 같은 사용 과정에서 함께 등장할 수는 있지만 서로 대체할 수는 없습니다. 서버 구독을 가져온 뒤에도 현재 어떤 Config를 사용하는지 확인해야 하며, Config를 선택했다고 해서 연결 가능한 서버가 준비된 것은 아닙니다. 문제를 해결할 때는 이 두 부분을 먼저 구분해야 관련 없는 설정을 반복해서 수정하는 일을 줄일 수 있습니다.

Config는 보통 여러 섹션으로 구성된 텍스트 파일입니다. 대괄호로 표시된 제목에서 섹션이 시작되며, 다음 섹션 제목이 나오기 전까지 해당 섹션의 내용이 이어집니다. 일반 설정은 [General], 순서가 있는 매칭 규칙은 [Rule], 지정한 호스트 이름의 주소 매핑은 [Host], 표시되는 요청 주소를 바꾸는 규칙은 [URL Rewrite]에 저장합니다. 섹션 제목은 설명 문구가 아니므로 한국어로 바꾸면 안 됩니다. 규칙의 쉼표, 등호와 매개변수 위치도 문법의 일부이므로 편집할 때 영문 반각 기호를 사용하세요.

섹션주요 역할확인할 항목
[General]일반 동작 및 이름 해석 관련 설정매개변수 이름, 값, 시스템과의 상호작용
[Rule]조건에 따라 연결 정책 선택규칙 순서, 조건, 정책 이름
[Host]지정된 호스트 이름의 주소 매핑매핑 대상이 여전히 유효한지 여부
[URL Rewrite]표현식에 따라 표시되는 요청 주소 변경매칭 범위, 대상, 동작

간단한 예시로 섹션 간 관계 이해하기

아래 예시는 일반 설정과 규칙을 구분해 작성하는 방법을 보여줍니다. dns-server = system은 시스템에서 제공하는 DNS 설정을 사용한다는 뜻이지, 모든 네트워크에서 더 빠르다는 보장은 아닙니다. 두 도메인 규칙은 서로 다른 연결 방향을 지정하며, 마지막 규칙은 앞에서 매칭되지 않은 요청을 처리합니다. 이는 구조를 보여주는 예시일 뿐, 기존 파일을 그대로 덮어써도 되는 완성된 설정은 아닙니다. 특히 PROXY가 실제로 연결할 대상은 앱에서 현재 선택한 서버를 확인해야 하며, 이 몇 줄만으로 추정할 수 없습니다.

[General]
dns-server = system

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

긴 Config 파일을 읽을 때는 먼저 섹션을 모두 표시하고, 마지막 기본 규칙을 확인한 다음 도메인 및 주소 규칙을 살펴보세요. 이렇게 하면 파일의 전체 구조를 파악한 뒤 예외 조건을 확인할 수 있습니다. 특정 섹션을 통째로 다른 파일에 복사하는 것은 피하세요. 같은 이름의 정책, 기존 규칙, 일반 설정이 다를 수 있어 문법상 올바른 부분도 합친 뒤에는 요청의 연결 방향을 바꿀 수 있습니다. 용도를 모르는 설정은 무엇을 위한 것인지 먼저 확인한 후 유지하거나 삭제하세요.

저장, 선택, 복구용 사본 보관

Config를 편집하기 전에 현재 파일을 복사해 알아보기 쉬운 이름으로 저장하세요. 편집을 마치면 저장 여부를 확인하고, 실제로 수정한 Config를 선택했는지도 확인해야 합니다. 편집기에서 내용을 열어 보기만 해서는 현재 Config가 바뀌지 않습니다. 그다음 Global Routing도 확인하세요. Config에 규칙이 들어 있는 것과 요청이 실제로 그 규칙에 따라 처리되는 것은 별개의 조건입니다. 처음 설정한다면 빠른 시작 가이드에 따라 Config를 선택한 뒤 이 페이지에서 문법을 확인하세요.

원격으로 관리되는 Config는 업데이트 범위도 고려해야 합니다. 원격 내용으로 교체될 파일에 개인 규칙을 직접 추가하면 다음 업데이트에서 수정 내용이 덮어써질 수 있습니다. 원본 사본을 보관하고 개인 작업용 사본을 따로 저장한 다음, 수정할 때마다 이유를 기록하는 편이 안전합니다. 구독 업데이트, Config 업데이트, 앱 업데이트도 각각 구분해야 합니다. 구독 업데이트는 주로 기존 서버 항목을 관리하고, Config 업데이트는 규칙 텍스트를 변경합니다. 앱은 App Store에서 받거나 업데이트할 수 있습니다.

2. Global Routing과 연결 정책

먼저 모드를 확인한 뒤 규칙 결과 살펴보기

Global Routing은 규칙이 요청 처리에 적용되는지 판단하는 첫 번째 항목입니다. Config 모드는 Config, 프록시 모드는 Proxy, 직접 연결 모드는 Direct입니다. 일반적인 규칙 문제 해결은 먼저 Config로 전환한 뒤 파일 내용을 확인하는 순서로 진행하세요. 다른 모드에서는 도메인 규칙만 수정해도 기대한 결과가 나오지 않을 수 있습니다. 여기서 설명하는 것은 전체 연결 경로를 선택하는 방식이며, 앱이 시스템 제한을 우회한다거나 모든 시스템 트래픽이 똑같이 표시된다는 뜻은 아닙니다.

모드 이름과 규칙의 정책 키워드는 서로 다른 계층에 속합니다. Proxy는 화면에 표시되는 모드 이름이고, PROXY는 규칙에 쓰는 정책 값입니다. Direct와 DIRECT도 마찬가지입니다. 표기는 비슷하지만 모드를 바꾸는 것과 특정 규칙의 정책을 바꾸는 것은 다릅니다. 여러 요청의 연결 방향이 한꺼번에 달라졌다면 모든 도메인 규칙이 무효가 됐다고 추측하기보다 현재 모드와 선택된 Config부터 확인하세요.

모드화면 표기사용 및 진단 시 확인할 점
ConfigConfig현재 Config에서 매칭 조건과 정책 확인
프록시Proxy프록시 연결 방향으로 서버 연결 확인
직접 연결Direct로컬 네트워크에서 직접 접속한 결과와 비교

PROXY, DIRECT, REJECT의 실제 의미

PROXY는 프록시 방향으로 처리한다는 뜻이지, 서버 주소를 가리키는 것은 아닙니다. 연결 성공 여부는 선택한 서버, 프로토콜 매개변수, 네트워크 연결 가능 여부에 달려 있습니다. 규칙이 PROXY에 정상적으로 매칭된 뒤 시간 초과가 발생해도 규칙이 잘못됐다고 단정할 수 없습니다. 서버가 유효한지, 현재 요청에 필요한 전송 방식을 지원하는지, 인증 정보가 일치하는지 계속 확인하세요. 모든 오류를 규칙 탓으로 돌리면 실제 연결 설정 단계에서 발생한 문제를 놓칠 수 있습니다.

DIRECT는 대상에 직접 연결한다는 뜻입니다. 도메인 이름 해석을 건너뛰거나 대상에 반드시 연결할 수 있다는 의미는 아닙니다. 로컬 네트워크의 라우팅, 방화벽, DNS 응답, 대상 서버 상태가 여전히 결과에 영향을 줍니다. REJECT는 조건에 해당하는 연결을 거부하므로 차단할 범위를 명확히 지정할 때 사용합니다. 요청이 거부되면 대개 완료되지 않지만, 앱에는 규칙 이름 대신 로드 실패로 표시될 수 있으므로 매칭 기록과 함께 확인하세요.

[Rule]
DOMAIN,service.example.com,PROXY
DOMAIN,intranet.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
FINAL,PROXY

예시에서는 각 정책의 범위를 쉽게 구분할 수 있도록 호스트 이름 세 개를 따로 사용했습니다. 실제 Config에서 전체 도메인 접미사를 거부하는 규칙을 먼저 작성하고, 그 아래에 특정 호스트 이름의 허용 규칙을 추가하지 마세요. 앞 규칙이 먼저 매칭되면 뒤의 예외는 실행되지 않습니다. 또한 REJECT를 서버 장애 시 사용할 예비 회선처럼 취급하지 마세요. 요청을 차단할 뿐, 다른 연결 경로를 찾아 주지 않습니다.

서버를 선택해도 모든 요청이 그 서버를 거치는 것은 아닙니다

Config 모드에서는 서버 선택과 규칙 정책이 함께 결과를 결정합니다. 요청이 DIRECT에 매칭되면 유효한 서버를 선택했더라도 직접 연결됩니다. 반대로 기본 정책이 PROXY라고 해서 앞에 있는 직접 연결 및 거부 규칙이 무시되는 것도 아닙니다. 서버 이름만 확인해서는 프록시 방향에서 사용할 대상을 알 수 있을 뿐, 특정 요청이 왜 그 경로를 택했는지는 알 수 없습니다.

프록시 연결과 직접 연결을 비교하려면 동일한 테스트 대상을 정하고 모드, 네트워크 유형, 테스트 시간을 각각 기록하세요. 테스트가 끝나면 기존 Config 모드로 되돌립니다. 서버 변경, DNS 수정, 모드 전환을 동시에 하지 마세요. 결과가 나아져도 어떤 변경이 효과를 냈는지 알 수 없습니다. 프록시 방향에서만 실패한다면 노드 시간 초과 및 연결 실패 확인 순서를 참고하세요. 특정 도메인만 실패한다면 매칭 조건과 DNS 응답을 다시 확인해야 합니다.

3. DOMAIN 계열 규칙과 도메인 범위

DOMAIN: 호스트 이름 하나를 정확히 매칭

DOMAIN은 도메인을 정확히 매칭할 때 사용합니다. 조건에는 전체 웹 주소가 아니라 호스트 이름을 입력해야 하므로 프로토콜 접두사, 경로, 쿼리 매개변수, 포트를 포함하지 마세요. 웹 주소에는 이런 요소가 함께 들어갈 수 있지만 도메인 규칙은 그중 호스트 이름만 확인합니다. 특정 웹 경로만 처리하려면 다른 적절한 방식을 사용해야 합니다. 경로를 도메인 뒤에 붙인다고 규칙이 전체 주소를 이해하는 것은 아닙니다.

예를 들어 아래 첫 번째 규칙은 api.example.com에만 적용되며 같은 조직의 도메인이라는 이유로 www.example.com까지 자동으로 포함하지 않습니다. 정확한 규칙은 범위를 확인한 단일 서비스 주소를 처리하거나, 넓은 규칙보다 먼저 예외를 지정할 때 적합합니다. 페이지 이름을 보고 추측하기보다 요청 기록에서 호스트 이름을 복사하는 편이 정확합니다. 페이지에 표시된 브랜드 이름과 실제 요청 도메인은 다를 수 있고, 정적 리소스나 인증 요청은 별도 호스트 이름을 사용할 수 있습니다.

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

DOMAIN-SUFFIX: 도메인 계층에 따라 접미사 범위 매칭

DOMAIN-SUFFIX는 루트 도메인과 하위 도메인에 같은 정책을 적용할 때 적합합니다. 조건을 example.com으로 지정하면 루트 도메인과 해당 하위 도메인이 매칭되지만, 이 문자열이 어디든 포함된 임의의 이름까지 매칭되는 것은 아닙니다. 도메인 계층에는 명확한 경계가 있으며, 이는 키워드 매칭과 다릅니다. 보통 조건 앞에 별표를 붙일 필요가 없습니다. 브라우저나 다른 문법에서 쓰는 와일드카드 표기를 그대로 가져오면 의도한 의미와 달라질 수 있습니다.

접미사 규칙을 사용하면 하위 도메인을 하나씩 관리할 필요가 줄지만 적용 범위는 넓어집니다. 같은 접미사 아래 프록시가 필요한 API와 로컬 네트워크에서만 열리는 서비스가 있다면 하나의 정책으로 묶었을 때 일부에 영향을 줄 수 있습니다. 범위가 좁은 예외를 먼저 쓰고 접미사 규칙을 뒤에 배치하는 편이 좋습니다. 위 예시에서는 로그인 호스트 이름이 먼저 DIRECT에 매칭되고, 같은 접미사의 나머지 요청은 뒤의 규칙에서 처리됩니다. 순서는 Config의 의도를 나타내는 일부입니다.

DOMAIN-KEYWORD: 문자열 조건과 오매칭

DOMAIN-KEYWORD는 도메인에 지정한 키워드가 포함되는지 판단하므로 전체 도메인 접미사보다 적용 범위가 넓습니다. 키워드의 업무상 의미를 이해하거나 특정 이름이 광고, 분석 또는 업데이트 서비스인지 판단하지는 않습니다. 조건이 너무 짧으면 관련 없는 도메인까지 잘못 매칭될 수 있으며, 흔한 문자 조합일수록 위험합니다. 아래 내용은 문법 설명용일 뿐 검증된 차단 목록이 아닙니다. 테스트 없이 일상적으로 사용하는 Config에 추가하지 마세요.

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

예시에서는 명확한 호스트 이름의 예외를 먼저 두고 키워드 거부 규칙을 보여줍니다. 그래도 같은 문자를 포함한 다른 도메인이 거부될 수 있습니다. 이미지 일부가 표시되지 않거나 로그인 과정이 중단된다면 실패한 요청의 실제 호스트 이름부터 확인하고, 이처럼 범위가 넓은 조건에 걸렸는지 살펴보세요. 알려진 도메인 하나만 처리하려는 경우에는 정확한 규칙이나 접미사 규칙을 우선 사용하면 의미를 파악하고 나중에 범위를 유지 관리하기가 쉽습니다.

하나의 페이지를 여러 연결로 나누어 살펴보기

웹 페이지 로드에는 요청 하나만 있는 것이 아닙니다. 기본 페이지, 스크립트, 이미지, 인증, API가 각기 다른 도메인에 연결될 수 있습니다. 주소창에 표시된 도메인에 규칙을 작성해도 모든 리소스가 같은 경로를 사용한다고 보장할 수 없습니다. 확인할 때는 “기본 페이지가 열리는가”와 “전체 기능을 사용할 수 있는가”를 구분하고, 새 요청을 발생시켜 주요 도메인을 확인하세요. 이미지 하나가 실패한다고 전체 사이트에 더 넓은 키워드 규칙을 적용하지 말고, 일시적으로 나타난 서드파티 리소스 도메인을 모두 같은 접미사에 추가하지도 마세요.

도메인 규칙은 매칭 단계에서 도메인 정보를 확인할 수 있어야 적용됩니다. 요청이 주소 형태로 전송되거나 기존 연결이 재사용되면 관찰 결과가 방금 수정한 도메인 규칙과 다를 수 있습니다. 테스트 페이지를 닫고 새로 접속한 다음 기록에 실제 대상이 어떻게 표시되는지 확인하세요. 문제가 안정적으로 재현된 뒤에 도메인 규칙을 추가할지, 주소 규칙을 조정할지, DNS를 살펴볼지 판단할 수 있습니다. 관련 용어는 용어 빠른 참고에서 함께 확인할 수 있습니다.

4. IP, GEOIP, USER-AGENT 규칙

IP-CIDR와 IP-CIDR6의 주소 범위

IP-CIDR은 IPv4 주소 범위에, IP-CIDR6은 IPv6 주소 범위에 매칭됩니다. 슬래시 뒤의 숫자는 네트워크 프리픽스 길이이며 포트나 주소 개수를 뜻하지 않습니다. 프리픽스 길이가 길수록 일반적으로 범위가 좁아집니다. 규칙에는 올바른 네트워크 주소와 프리픽스를 조합해 입력해야 합니다. IPv4 주소 하나만 매칭하려면 전체 호스트 프리픽스를 사용할 수 있으며, 프리픽스를 생략해도 모든 표기가 같은 의미라고 가정하면 안 됩니다.

아래는 흔히 쓰이는 사설 주소 범위와 IPv6 로컬 주소 범위를 문법 예시로 보여줍니다. 이 규칙이 필요한지는 실제 네트워크와 기존 일반 설정을 함께 고려해야 합니다. 일부 시스템 트래픽이나 일반 우회 설정은 일반 규칙 매칭 전에 처리될 수 있으므로 주소 규칙의 매칭 기록이 보이지 않는다고 해서 반드시 문법 오류인 것은 아닙니다. 특히 LAN 서비스 문제를 확인할 때는 기기의 실제 주소, 게이트웨이, 현재 네트워크 유형을 함께 기록하세요.

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

no-resolve의 역할

no-resolve는 주소 조건의 매칭 여부를 판단하기 위해 도메인 조회를 수행하지 않도록 합니다. 앱 전체에서 DNS 사용을 중단한다는 뜻도 아니고, 도메인 관련 연결에 이 규칙이 절대 매칭되지 않는다는 뜻도 아닙니다. 요청 대상이 원래 주소 형태이거나 매칭 단계에서 사용할 주소 정보를 이미 확보한 경우에는 주소 조건이 성립할 수 있습니다. 이 매개변수는 매칭 과정에서의 DNS 조회 동작을 제어할 뿐, 특정 앱에서만 쓰는 특수 규칙으로 바꾸는 것은 아닙니다.

Config에 주소 범위 규칙이 많으면 불필요한 매칭마다 DNS 조회를 수행하는 것이 대기 시간을 늘리거나 조회 경로가 결과에 영향을 주게 할 수 있습니다. 반대로 모든 규칙에 이 매개변수를 기계적으로 추가하면 DNS 응답에 의존하는 규칙이 예상한 단계에서 판단되지 않을 수 있습니다. 선택하기 전에 “이 규칙이 작동하려면 도메인을 주소로 해석해야 하는가?”를 확인하고 실제 기록을 살펴보세요. 일반적인 속도 향상 옵션으로 취급하면 안 됩니다.

GEOIP는 데이터베이스 분류이며 웹사이트 소재지를 판정하지 않습니다

GEOIP는 대상 주소를 사용 중인 IP 지리 데이터베이스와 비교해 판단합니다. 흔히 쓰이는 문법은 아래와 같지만 국가 또는 지역 코드는 데이터베이스상의 주소 분류일 뿐, 웹사이트 운영 주체나 콘텐츠 언어, 사용자의 위치를 나타내지는 않습니다. 도메인이 분산형 서비스를 사용하면 네트워크와 시간에 따라 해석 결과가 달라질 수 있고, 최종 분류도 달라질 수 있습니다. 따라서 GEOIP는 범위가 넓은 후순위 규칙으로는 쓸 수 있지만 용도를 이미 파악한 도메인의 정확한 조건을 대체하기에는 적합하지 않습니다.

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

지리 규칙 결과가 예상과 다르면 실제 연결 주소를 확인한 뒤 어떤 규칙이 매칭됐는지 살펴보세요. 페이지 언어만 보고 주소가 어느 지역에 속할지 추측하거나, 예외 하나 때문에 전체 지리 정책을 뒤집지 마세요. 특정 서비스의 연결 방향을 안정적으로 유지해야 한다면 더 명확한 도메인 규칙을 앞에 배치하는 편이 관리하기 쉽습니다. 데이터베이스 분류, DNS 응답, 서비스 요구사항은 서로 다른 사실이므로 각각 기록해야 합니다.

USER-AGENT 사용 조건

USER-AGENT는 확인할 수 있는 요청 식별 정보를 기준으로 매칭하며, 기기에 설치된 앱 이름을 기준으로 하지는 않습니다. 아래 문법은 접두사 와일드카드 조건을 보여주지만 실제 매칭 여부는 요청에 해당 필드가 포함되어 있는지, 처리 단계에서 필드를 확인할 수 있는지에 달려 있습니다. 암호화된 요청의 내용을 규칙 하나만으로 자동 확인할 수는 없습니다. 매칭되지 않는다면 범위를 넓히기 전에 필요한 정보가 보이는지부터 확인하세요.

USER-AGENT,ExampleClient*,DIRECT

같은 앱도 시스템 구성 요소나 네트워크 모듈에 따라 서로 다른 식별 정보를 보낼 수 있고, 서로 다른 앱이 같은 식별 정보를 사용할 수도 있습니다. 따라서 이런 규칙을 앱의 정체성을 엄격히 구분하는 기준으로 사용하기는 어렵습니다. 일반적인 도메인별 트래픽 분기에는 도메인 조건이 더 명확한 경우가 많습니다. 요청 식별 정보를 확인하고 적용 범위를 파악했으며 재현 가능한 테스트를 할 수 있을 때만 해당 규칙을 유지하세요. 조건을 억지로 매칭시키려고 인증서 신뢰를 변경하거나 콘텐츠 처리 권한을 넓히지 마세요.

5. 매칭 순서, 예외, FINAL

첫 번째로 매칭된 규칙이 적용되며, 가장 구체적인 규칙을 자동 선택하지 않습니다

일반적인 [Rule] 처리에서는 규칙을 위에서 아래로 평가하며, 조건을 처음 충족한 규칙의 정책이 적용됩니다. 정확한 도메인이라고 해서 더 구체적이라는 이유만으로 우선순위가 자동으로 높아지지는 않습니다. 범위가 넓은 접미사 규칙이 앞에서 먼저 매칭되면 뒤의 정확한 규칙은 결과를 바꾸지 못합니다. 이것이 “규칙이 있는데 적용되지 않는” 흔한 원인입니다. 문제를 확인할 때는 대상 규칙만 찾지 말고, 그 위쪽에 먼저 매칭될 수 있는 조건이 있는지도 살펴보세요.

규칙을 읽을 때 각 줄을 하나의 판단으로 보면 됩니다. 조건이 맞으면 해당 줄의 정책을 적용하고 멈추며, 그렇지 않으면 다음 줄로 넘어갑니다. 주석, 그룹 제목, 빈 줄은 가독성을 높일 뿐 별도의 우선순위를 만들지는 않습니다. 눈에 띄는 제목 아래에 예외를 넣어도 앞에서 이미 매칭된 규칙을 건너뛸 수 없습니다. 긴 파일을 관리할 때는 기억에 의존해 예외 위치를 찾기보다 일관된 그룹 순서로 의도를 표현하세요.

[Rule]
DOMAIN,office.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

명확한 예외에서 넓은 조건 순으로

위 예시는 명확한 호스트 이름 두 개를 먼저 처리하고, 전체 접미사와 주소 범위, 지리 조건을 확인한 뒤 기본 정책을 적용합니다. 설명을 위한 한 가지 구성 방식일 뿐 모든 네트워크에서 그대로 따라야 하는 것은 아닙니다. 특정 서비스에서 주소 규칙을 항상 우선해야 한다면 순서를 다시 정하고 도메인 조건에 미치는 영향을 파악해야 합니다. 중요한 것은 정해진 순서를 외우는 것이 아니라, 조건이 겹치는 각 요청이 어떤 규칙을 먼저 만나게 되는지 설명할 수 있는 것입니다.

office.example.com을 예로 들면 접미사 조건에도 해당하지만 첫 번째 규칙에서 직접 연결로 결정됩니다. 접미사 규칙을 첫 줄로 옮기면 결과가 달라집니다. 해당 접미사에 속하지 않는 도메인은 주소 또는 지리 조건을 거친 뒤 기본 규칙에 도달할 수 있습니다. 일상적인 웹 탐색이 “그럭저럭 정상”인지 관찰하는 것보다 이런 간단한 테스트 대상을 하나씩 구성하는 편이 순서 문제를 더 잘 찾아낼 수 있으며, 수정으로 달라진 부분도 확인하기 쉽습니다.

FINAL은 나머지 요청을 처리하는 마지막 규칙이어야 합니다

FINAL에는 도메인이나 주소 조건이 없으며 앞에서 매칭되지 않은 요청을 처리합니다. 따라서 유효한 규칙의 맨 마지막에 배치해야 합니다. 중간에 두면 뒤의 규칙이 실행되지 않는 경우가 많습니다. 기본 규칙이 여러 개 있다고 해서 여러 정책을 차례로 시도하는 것도 아닙니다. 아래의 두 기본 연결 방향은 서로 다른 선택을 나타냅니다. 명시적으로 처리하지 않은 요청을 프록시로 보내거나 직접 연결하는 방식입니다. 현재 연결 목적과 기존 Config에 맞춰 선택하세요.

FINAL,PROXY
FINAL,DIRECT

두 예시는 서로 대체하는 설정이므로 “혹시 몰라서” 둘 다 추가하면 안 됩니다. 기본 정책은 적용 범위가 넓으므로 변경 전에 기본 연결 방향에 의존하는 서비스를 포함해 대표적인 요청을 몇 가지 정리하세요. 이미 정확한 규칙에 매칭되는 도메인 하나만 테스트해서는 새로운 기본 방향이 적절한지 알 수 없습니다. 현재 Config의 설계를 확신할 수 없다면 기존 기본 정책을 유지하고, 명확한 문제에 필요한 예외만 추가하세요. 작은 수정을 전역 동작 변경으로 만들지 않는 것이 좋습니다.

규칙을 합칠 때 중복과 가려짐 확인하기

두 규칙 조각을 합칠 때는 같은 텍스트가 있는지만 확인해서는 안 되며 적용 범위가 겹치는지도 살펴야 합니다. 같은 조건이 반복되면 보통 앞에 있는 규칙이 결과를 결정하고, 뒤의 다른 정책은 실행되지 않을 수 있습니다. 범위가 넓은 키워드, 접미사, 주소 범위도 뒤의 예외를 가릴 수 있습니다. 정리하기 전에 원본 사본을 보관하고 대상 도메인이 처음 매칭되는 위치를 추적한 뒤 불필요한 내용을 삭제하세요. 전체 파일을 알파벳순으로 정렬하면 순서가 중요한 규칙 섹션이 망가질 수 있습니다.

가려진 규칙을 찾았다면 의도치 않은 중복인지, 나중에 용도를 바꾸기 위해 남긴 메모인지도 판단해야 합니다. 실제로 적용되는 텍스트는 명확하게 유지하고, 유지 관리 메모는 실행되지 않는 위치에 기록하세요. 수정한 뒤에는 새 연결을 시작해야 합니다. 기존 연결에서 계속 데이터가 전송되는 상황을 보고 새 규칙 순서가 적용되지 않았다고 오해하지 마세요. 관련 호스트 이름이 여러 개라면 각각 확인해야 합니다. 규칙 하나의 우선순위가 올바르다고 해서 전체 서비스의 요청이 모두 처리된다는 보장은 없습니다.

6. DNS, Host와 연결 주소의 관계

DNS는 주소를 알려주고 규칙은 연결 정책을 결정합니다

DNS는 호스트 이름에 대응하는 주소를 알려주며, 규칙은 요청에 적용할 정책을 결정합니다. 두 기능은 서로 영향을 줄 수 있지만 같은 것은 아닙니다. DNS 조회에 성공해 주소를 받았더라도 대상 포트에 연결할 수 있다는 뜻은 아닙니다. 프록시 규칙에 매칭됐다고 해서 DNS 조회가 예상한 경로로 이루어진다는 보장도 없습니다. 문제 해결 기록에는 호스트 이름, DNS 응답, 매칭된 규칙, 최종 연결 상태를 각각 포함하세요. “열리지 않는다”는 결과 하나로 모든 단계의 상태를 뭉뚱그리면 안 됩니다.

[General]의 DNS 설정은 이후 판단에 필요한 정보에 영향을 줍니다. 시스템 DNS를 사용하면 결과가 현재 Wi-Fi 또는 셀룰러 네트워크에 따라 달라질 수 있습니다. 별도로 지정한 DNS를 사용한다면 해당 DNS 서버에 연결할 수 있는지도 확인해야 합니다. DNS 옵션을 여러 개 동시에 바꾼 뒤 페이지 로딩 속도만으로 어느 쪽이 나은지 판단하지 마세요. 도메인 캐시가 남아 있거나 페이지에서 연결을 재사용할 수도 있어 Config 차이가 실제보다 크게 또는 모호하게 보일 수 있습니다.

[General]
dns-server = system

Host 매핑은 서버 항목이 아닙니다

[Host]에서는 지정한 호스트 이름에 주소를 연결할 수 있습니다. 아래 예시는 문법을 보여주기 위해 교육용 도메인을 문서 예시 주소에 매핑한 것이며, 해당 주소에 접속할 수 있는 서비스가 있다는 뜻은 아닙니다. 등호 왼쪽은 호스트 이름, 오른쪽은 대상 주소입니다. 이 설정은 Add Server에 프록시 서버를 입력하는 방법이 아니며 원격 서비스의 인증 정보도 바꾸지 않습니다. 구독에 포함된 서버 주소나 비밀번호를 이 섹션에 입력해 서버를 가져오려고 하지 마세요.

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

고정 매핑은 주소가 명확히 정해진 통제된 환경에 적합하지만, 도메인의 동적 라우팅을 우회합니다. 서비스 이전, 주소 만료, 네트워크 위치 변경 이후에도 이전 매핑이 남아 있으면 요청이 적절하지 않은 대상으로 계속 연결될 수 있습니다. 특정 Config를 사용할 때만 도메인에 문제가 생긴다면 남아 있는 매핑을 확인하고 시스템 DNS와 Config DNS의 주소를 비교하세요. 일시적으로 접속을 복구하기 위해 출처가 불분명한 고정 주소를 계속 유지하지 마세요.

주소 변경은 인증서 신원 변경과 다릅니다

호스트 이름으로 암호화 서비스에 접속할 때 연결 주소와 서버 신원 확인은 관련이 있지만 서로 대체할 수는 없습니다. 도메인을 다른 주소에 매핑해도 해당 주소의 임의 서비스가 올바른 인증서를 제공하거나 필요한 호스트 이름을 인식하게 되지는 않습니다. 인증서 또는 핸드셰이크 오류가 발생하면 도메인, 서비스 설정, 시스템 시간을 확인하세요. 검증 수준을 낮추는 방법을 일반적인 해결책으로 사용하면 안 됩니다. 기존 Trojan 서버 매개변수를 확인하고 있다면 비밀번호, SNI, TLS 매개변수 안내를 참고하세요.

마찬가지로 Host 매핑이 도메인 분류보다 항상 먼저 적용된다고 단순하게 이해해서는 안 됩니다. 도메인 조건이 주소 조건보다 먼저 매칭될 수 있고, 주소 매핑은 연결 대상을 바꾸지만 정책은 매칭 과정에서 결정됩니다. 두 기능의 관계를 확인하려면 교육용 또는 통제된 호스트 이름 하나에만 매핑을 설정하고 실제 연결 주소를 기록한 뒤 도메인 규칙과 주소 규칙의 매칭을 각각 확인하세요. 최종 표시 주소만 보고 그전에 일어난 모든 단계를 추정하지 마세요.

캐시, IPv4·IPv6 주소, 네트워크 전환

하나의 호스트 이름이 IPv4와 IPv6 주소를 모두 가질 수 있으며 실제로 어느 주소를 사용하는지는 네트워크 연결 가능 여부와 연결 과정에 따라 달라집니다. IPv4 규칙만 작성했다고 IPv6까지 자동으로 포함되는 것은 아닙니다. 반대로 IPv6 연결이 한 번 실패했다고 해서 주소 계열 설정 전체를 바꿔야 한다고 볼 수도 없습니다. 실제 요청이 어떤 유형의 주소를 사용했는지 확인한 다음 해당 규칙과 네트워크 조건을 살펴보세요. 두 주소 계열을 나누어 기록하면 한쪽은 성공하고 다른 쪽은 실패할 때 상반된 결론을 내리는 일을 줄일 수 있습니다.

네트워크를 바꾼 뒤에도 DNS 캐시, 앱의 연결 풀, 기존 연결이 잠시 결과에 영향을 줄 수 있습니다. 새 Config를 확인하려면 기존 테스트 연결을 종료하고 동일한 대상으로 다시 접속하세요. 필요하다면 앱에서 제공하는 기능으로 관련 캐시를 지우세요. 브라우저 페이지 캐시만 지워서는 모든 네트워크 연결이 새로 만들어지지 않을 수 있습니다. 특정 네트워크에서만 문제가 발생한다면 Config를 그대로 둔 채 비교 테스트를 진행하면 로컬 네트워크 차이와 Config 오류를 구분하는 데 도움이 됩니다.

최종적으로 DNS 설정의 출처와 고정 매핑을 둔 이유, DNS 응답에 의존하는 주소 규칙을 설명할 수 있어야 합니다. Config에 과거 설정과 용도를 모르는 매핑이 많을수록 문제가 생겼을 때 확인할 항목도 늘어납니다. 용도를 설명할 수 없는 설정을 작업용 사본에 계속 추가하지 말고, 우선 최소한으로 작동하는 상태로 되돌린 뒤 필요한 내용을 하나씩 복구하세요.

7. URL Rewrite 문법과 처리 범위

요청 주소 변경과 연결 정책 선택은 별개입니다

[URL Rewrite]는 조건에 맞는 표시 가능한 요청 주소를 처리하고, [Rule]은 연결 정책을 처리합니다. 두 섹션은 서로 대체할 수 없습니다. 주소를 다른 호스트 이름으로 바꿔도 프록시 연결 방향이 지정되는 것은 아닙니다. 새 대상은 관련 Config와 실제 처리 단계에 따라 판단해야 합니다. 반대로 도메인 규칙은 연결 방향만 결정하며 특정 경로를 다른 경로로 자동 변경하지 않습니다. 주소를 바꾸려는 문제인지 연결 방향을 바꾸려는 문제인지 먼저 구분한 다음 섹션을 선택하세요.

Rewrite 규칙은 보통 매칭 표현식, 대상, 동작으로 구성됩니다. 표현식에 특수 문자가 포함되어 있다면 일반 문자열처럼 읽지 말고 정규 표현식의 의미를 확인해야 합니다. 마침표는 정규 표현식에서 특별한 역할을 하므로 도메인의 실제 점을 매칭하려면 올바르게 이스케이프해야 합니다. 시작 앵커는 매칭 시작 위치를 제한하고 끝 앵커는 전체 범위를 제한합니다. 경계를 빠뜨리면 예상보다 더 많은 내용이 매칭될 수 있습니다.

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

예시를 항목별로 이해하기

예시는 주소의 시작 부분에서 지정된 프로토콜과 호스트 이름을 매칭하고, 슬래시 뒤의 내용을 그룹으로 캡처한 다음 $1을 사용해 대상 주소에 넣습니다. 동작 302는 임시 리디렉션을 뜻합니다. 여기에는 문서 예시용 예약 도메인을 사용했으며 개인 Config에 추가하라는 의미는 아닙니다. 실제로 사용하기 전에 대상 서비스가 해당 프로토콜과 경로를 지원하는지 확인하세요. 리디렉션은 요청자에게 다른 주소로 이동하라고 알려줄 뿐, 존재하지 않는 서비스를 사용할 수 있게 만들지는 않습니다.

표현식과 대상 사이의 공백은 구분 역할을 하므로 표현식에 처리되지 않은 공백을 임의로 넣지 마세요. 규칙을 복사할 때 텍스트 편집기가 따옴표, 백슬래시, 문장 부호를 바꾸지 않았는지도 확인해야 합니다. 간단한 도메인 규칙보다 정규식 Rewrite는 “문법은 읽히지만 범위가 예상과 다른” 문제가 쉽게 생깁니다. 성공 사례 하나만 테스트하지 말고 매칭되면 안 되는 유사 주소도 함께 확인해 경계가 충분히 엄격한지 살펴보세요.

요청이 보여야 Rewrite를 적용할 수 있습니다

암호화된 연결의 전체 경로와 쿼리 매개변수는 도메인 라우팅만으로 확인할 수 없는 경우가 많습니다. 앱이 해당 요청 정보를 제공하고 요청이 처리 가능한 조건에 있을 때만 Rewrite가 실행될 수 있습니다. 연결 도메인이 보인다고 전체 주소까지 보이는 것은 아니며, 주소 하나가 보인다고 모든 앱의 요청이 같은 방식으로 처리되는 것도 아닙니다. 규칙이 실행되지 않는다면 동작과 대상을 바꾸기 전에 요청 정보가 보이는지, 표현식에 맞는지부터 확인하세요.

일반적인 Rewrite 규칙을 확인하기 위해 모든 도메인의 콘텐츠 처리 범위를 넓히거나 인증서 신뢰 설정을 바꾸지 마세요. 암호화된 콘텐츠를 처리하는 데는 별도의 보안 경계가 있고 앱 자체 검증의 영향을 받을 수 있습니다. 이러한 조건을 일반적인 트래픽 분기에 필요한 절차로 취급해서는 안 됩니다. 도메인에 따라 프록시, 직접 연결 또는 거부를 선택하려는 경우에는 [Rule]을 사용하면 되며 같은 목적을 위해 주소 Rewrite를 추가할 필요는 없습니다.

순환, 경로 누락, 민감 정보 전달 방지

리디렉션 대상이 다시 원래 표현식에 매칭되면 순환이 발생할 수 있습니다. 프로토콜만 바꾸는 것처럼 보여도 대상 서비스가 요청을 원래 주소로 다시 리디렉션하는지 확인하세요. 경로와 쿼리 매개변수를 유지할지도 명확히 해야 합니다. 캡처 범위가 너무 좁으면 필요한 매개변수가 사라지고, 너무 넓으면 새 대상에 전달하면 안 되는 내용까지 함께 넘어갈 수 있습니다. 특히 인증과 관련된 요청은 매개변수의 용도를 모르는 상태에서 다른 호스트 이름으로 바꾸면 안 됩니다.

여러 Rewrite가 동시에 있으면 매칭 범위를 하나씩 분석하고 먼저 단일 규칙을 테스트한 다음 조합을 복원하세요. 같은 시작 주소를 반복해서 테스트할 때는 요청자가 리디렉션 결과를 캐시했는지도 고려해야 합니다. 페이지가 새 주소로 바로 이동한다고 해서 현재 규칙이 계속 실행되고 있다는 뜻은 아닙니다. 요청자가 이전 결과를 재사용했을 수 있습니다. 혼동을 피하려면 처음 입력한 주소, 최종 주소, 실제 매칭된 규칙을 기록하고 필요한 경우 새 세션에서 다시 확인하세요.

목표가 알려진 호스트 이름의 연결을 차단하는 것이라면 복잡한 Rewrite보다 명확한 REJECT 규칙을 유지하기 쉽습니다. 정책만 바꾸려는 경우에도 규칙 섹션으로 돌아가야 합니다. 주소를 실제로 변경해야 하고, 매칭 조건과 대상의 관계를 설명할 수 있으며, 안정적으로 테스트할 수 있을 때만 Rewrite를 유지하세요. 시험 삼아 추가한 규칙은 삭제하는 것도 중요합니다. 나중에 접속할 때 오래된 규칙이 다시 실행될 수 있습니다.

8. Config 검증, 문제 원인 파악, 유지 관리

반복 가능한 테스트 기준 만들기

수정하기 전에 현재 네트워크에서 기본 접속이 되는지 확인하고 사용 중인 네트워크, Config, Global Routing 모드, 선택한 서버를 기록하세요. 테스트 대상을 고정하고 정확한 규칙에 해당하는 대상, 접미사 규칙에 해당하는 대상, 기본 규칙을 사용하는 대상을 각각 준비합니다. 한 번에 조건 하나만 수정하고 저장한 뒤 새 연결을 시작하세요. 이런 기준을 세우면 규칙을 계속 추가하는 것보다 결과가 달라졌을 때 어떤 수정이 영향을 줬는지 명확하게 알 수 있습니다.

테스트 통과의 의미도 명확히 정의해야 합니다. 페이지가 열린다는 것은 일부 요청이 성공했다는 뜻일 뿐입니다. 로그인, API, 리소스 로드에는 각각 별도의 문제가 있을 수 있습니다. 먼저 요청이 예상한 정책에 매칭됐는지, 다음으로 연결이 성립했는지, 마지막으로 서비스 기능이 정상 작동하는지 확인하세요. 세 결과를 따로 기록하면 “규칙 방향은 맞지만 서버에 연결할 수 없음”과 “연결은 정상이나 서비스 API가 오류를 반환함”을 구분할 수 있어 잘못된 단계의 설정을 반복해서 바꾸지 않게 됩니다.

조건, 매칭, 연결, 서비스 단계별 확인

  1. 조건 단계:앱이 연결되어 있는지, 올바른 Config를 선택했는지, Config 모드인지 확인합니다.
  2. 매칭 단계:실제 호스트 이름 또는 주소를 확인하고 규칙 상단부터 처음 매칭되는 항목을 찾습니다.
  3. 연결 단계:DNS 응답, 대상 연결 가능 여부, 서버 인증, 전송 매개변수를 확인합니다.
  4. 서비스 단계:대상 서비스의 응답, 계정 상태, 관련 요청이 모두 완료됐는지 확인합니다.

예상한 규칙이 매칭되지 않는다면 범위가 넓은 규칙에 가려졌는지, 기본 규칙 뒤에 배치됐는지, 잘못된 파일을 저장했는지, 테스트가 기존 연결을 재사용하는지부터 확인하세요. 예상한 정책에 매칭됐는데 연결이 실패했다면 규칙 수정을 멈추고 해당 연결 방향에서 실제로 접속할 수 있는지 확인해야 합니다. Connectivity Test는 보유한 서버의 연결 상태를 비교하는 데 도움이 되지만 테스트 성공이 모든 서비스 대상에 연결할 수 있다는 보장은 아닙니다. 테스트 실패만으로 어떤 프로토콜 매개변수가 잘못됐는지도 알 수 없습니다.

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

이 짧은 예시로 검증 방법을 살펴볼 수 있습니다. 정확한 대상은 먼저 프록시에 매칭되고, 같은 접미사의 다른 호스트 이름은 직접 연결되며, 범위 밖 요청에는 기본 정책이 적용되어야 합니다. 실제로는 테스트 권한이 있고 존재하는 대상의 주소로 교육용 도메인을 바꿔야 합니다. 교육용 주소의 접속 가능 여부로 Config가 올바른지 판단하지 마세요. 도메인과 문서 주소는 문법을 설명하기 위한 값이지 네트워크 연결 검사 서비스가 아닙니다.

규칙 문제와 속도 문제 구분하기

연결 방향이 맞는데도 속도가 느리다면 프록시 범위를 계속 넓히기보다 로컬 네트워크 품질, 대상 서비스, 서버 부하, 프로토콜 매개변수를 비교하세요. 지연 시간 테스트와 실제 전송 속도는 서로 다른 지표입니다. 연결이 한 번 빠르게 설정됐다고 해서 장시간 전송도 안정적이라고 볼 수 없습니다. Config를 그대로 둔 채 여러 네트워크에서 동일한 대상을 확인하면 Config와 서버를 동시에 바꾸는 것보다 원인을 파악하기 쉽습니다. 자세한 방법은 속도 저하 단계별 문제 해결을 참고하세요.

네트워크를 전환한 뒤에만 문제가 발생한다면 연결이 새로 설정됐는지, DNS 응답이 달라졌는지, On Demand가 연결 시점에 영향을 주는지 확인하세요. On Demand는 연결을 시작하는 조건을 담당할 뿐, 도메인 규칙을 대신해 정책을 결정하지 않습니다. 자동 연결 시점과 규칙 매칭을 하나의 설정으로 혼동하지 마세요. 이 부분을 조정하려면 On Demand와 백그라운드 배터리 소모 확인을 참고한 뒤 같은 테스트 대상으로 다시 검증하세요.

수정 기록과 복구용 사본 보관

안정적으로 사용하는 Config는 명확한 복구용 사본을 남겨야 합니다. 전체 구독 주소를 기록할 필요는 없습니다. 수정 목적, 관련 섹션, 적용 범위, 검증 결과만 적으면 됩니다. 원격 Config가 업데이트되면 정식으로 사용하기 전에 기본 정책, 일반 설정, 개인 예외가 달라졌는지 비교하세요. 용도를 모르는 규칙을 한 번에 많이 합치면 설명과 관리가 어려워지고 중복 조건이나 오래된 매핑이 추가될 수 있습니다. 실제로 필요한 항목을 하나씩 추가해야 나중에 여전히 필요한 설정인지 판단하기 쉽습니다.

문제 해결 정보를 공유하기 전에 본인의 구독 인증 매개변수, 서버 비밀번호, 개인 주소, 서비스의 민감한 경로를 삭제하세요. 스크린샷이나 텍스트에는 문제 파악에 필요한 모드, 규칙 유형, 민감 정보를 가린 대상 정보만 남기면 됩니다. 이 사이트는 Shadowrocket 공식 사이트이자 공식 매뉴얼입니다. 앱은 클로즈드 소스 상용 앱이며 iPhone 및 iPad의 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 합니다. 구매 확인은 정품 확인 3가지 항목을 참고하고, 처음 연결할 때 흔히 발생하는 문제는 사용법으로 돌아가 순서대로 확인하세요.

유지 관리의 목표는 규칙을 많이 추가하는 것이 아닙니다. 각 규칙의 용도를 설명할 수 있고, 예외마다 검증 가능한 범위가 있으며, 업데이트할 때 복구할 방법이 있어야 합니다. 새 문제가 발생하면 먼저 재현하고 기대와 달라지기 시작한 단계를 찾은 뒤 필요한 부분만 수정하세요. 요청 대상부터 정책과 연결 결과까지 설명할 수 있어야 Config 검증이 완료된 것입니다.