Shadowrocket 규칙 및 설정 가이드

1. 설정 파일 구조와 편집 범위

먼저 현재 활성화된 설정 파일을 확인한 뒤 필드를 수정하세요. Shadowrocket에는 여러 설정 파일을 저장할 수 있습니다. Config 목록에 파일이 있다고 해서 현재 연결에 사용 중인 것은 아닙니다. Config에서 현재 선택된 항목을 확인하고 파일 이름과 출처를 기록한 다음 해당 파일의 내용을 살펴보세요. 화면에 표시된 규칙이 예상과 다르면 비슷한 규칙을 더 추가하기보다 파일을 잘못 선택했는지 먼저 확인해야 합니다. 원격 출처의 파일은 로컬에서 수정한 내용과 다시 업데이트한 뒤의 내용을 구분하세요.

섹션 이름에 따라 필드 해석이 달라집니다

설정 텍스트는 대괄호로 묶인 섹션 이름을 기준으로 나뉩니다. [General]에는 전반적인 동작과 관련된 옵션을, [Rule]에는 순서대로 판단하는 분기 조건을, [Host]에는 지정된 호스트 이름의 주소 매핑을, [URL Rewrite]에는 URL 재작성 항목을 입력합니다. 같은 줄이라도 어느 섹션에 들어가느냐에 따라 의미가 달라집니다. 도메인 규칙을 General 아래에 잘못 붙여 넣으면 문법이 그럴듯해 보여도 규칙으로 적용되지 않습니다. 구조를 확인할 때는 섹션 이름부터 다음 섹션 이름 전까지 차례로 살펴보세요.

[General]
bypass-system = true

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

[Host]
example.com = 192.0.2.10

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

위 텍스트는 네 섹션이 어떻게 이어지는지 보여주는 예시이며, 전체 내용을 그대로 활성화하라는 뜻은 아닙니다. Host의 주소는 문서용 예시 주소이고 URL Rewrite는 명시적인 HTTP 주소 리디렉션만 보여줍니다. 줄바꿈은 항목을 구분하고, 영문 쉼표는 규칙의 필드를 구분하며, 등호는 일부 설정의 이름과 값을 연결합니다. 테스트 연결 전에 전각 문장부호, 복사 과정에서 섞인 보이지 않는 문자, 잘못된 섹션 이름을 먼저 확인하세요. 그래야 텍스트 오류를 네트워크 문제로 오인하지 않습니다.

로컬 사본과 원격 업데이트

편집을 시작하기 전에 되돌릴 수 있는 사본을 저장하세요. 원격 설정을 사용한다면 업데이트 작업이 어떤 내용을 바꾸는지 먼저 확인해야 합니다. 출처 파일에 개인 규칙을 직접 추가하면 나중에 새로고침할 때 원본 내용으로 다시 덮어써질 수 있습니다. 원본 파일은 참고용으로 보관하고 명확히 구분되는 로컬 사본에서 테스트하며, 수정할 때마다 목적을 기록하는 편이 안전합니다. General을 바꾸고 Rule 순서를 재정렬하고 Host를 추가한 뒤, 한 번 접속해 본 결과만으로 모든 수정이 맞다고 판단하지 마세요.

Subscribe와 설정 파일은 별개로 이해해야 합니다. 기존 구독은 보통 서버 항목을 관리하고 설정 파일은 연결 처리 방식을 지정합니다. 사용 과정에서 서로 연결될 수는 있지만, 한쪽을 업데이트했다고 다른 쪽도 바뀌었다는 뜻은 아닙니다. 서버 목록은 새로고침됐는데 규칙이 그대로라면 Subscribe를 반복해서 새로고침하지 말고 Config에서 실제 설정 파일을 확인하세요. 반대로 도메인 정책을 수정해도 서버 주소, 포트 또는 인증 정보가 자동으로 채워지지는 않습니다.

작은 범위의 수정으로 검증 가능한 결과 만들기

한 번에 하나의 명확한 목표만 조정하세요. 예를 들어 테스트 도메인 하나를 DIRECT로 바꾸거나 범위가 너무 넓은 REJECT 조건을 좁힐 수 있습니다. 수정 전에 예상되는 규칙과 정책, 새 연결을 확인할 방법을 기록하세요. 설정을 저장하고 확인한 뒤 해당 연결을 새로 만들고 결과가 예상과 일치하는지 살펴봅니다. 기존 연결은 이전 처리 경로를 계속 사용할 수 있습니다. 이미 열려 있는 페이지를 새로고침한 결과만으로 새 규칙이 모든 요청에 적용됐다고 판단하지 마세요.

설정을 공유하기 전에 개인 연결 정보와 구독 주소, 인증 정보를 삭제하세요. 규칙 예시에는 테스트 도메인을 남기고 문제 설명에는 필요한 필드 이름을 포함할 수 있지만, 전체 설정에는 문제와 무관한 정보가 더 많이 들어 있는 경우가 많습니다. 다른 사람의 도움을 받을 때는 관련 섹션과 규칙의 상대적 순서, 민감한 정보를 가린 연결 기록을 우선 공유하세요. 재현이 쉬워지고 불필요한 항목 때문에 논의가 흐려지는 것도 막을 수 있습니다. 특히 특정 도메인이 잘못 분기되는 문제를 찾을 때 유용합니다.

2. General: 전역 옵션과 DNS 전제

General은 설정의 전반적인 동작에 영향을 주며 도메인별 정책을 선택하는 역할은 하지 않습니다. 이 섹션을 확인할 때는 먼저 필드 이름과 값의 유형을 살펴보고, 현재 문제와 관련이 있는지 판단하세요. 예를 들어 도메인 해석 실패라면 DNS 경로를 확인해야 하고, 특정 도메인이 잘못 DIRECT로 연결된다면 Rule과 현재 Global Routing을 먼저 살펴보는 편이 좋습니다. 모든 문제를 General 탓으로 돌리면 변수가 늘어나고 명확한 규칙 순서 문제가 가려질 수 있습니다.

필드에는 유형에 맞는 값을 입력합니다

General은 보통 필드 이름, 등호, 값 순서로 작성합니다. 불리언 옵션에는 true 또는 false를 사용하고 주소 관련 옵션은 해당 필드에서 허용하는 형식으로 입력하세요. 한국어 설명을 값으로 직접 넣거나 다른 사람의 설정에 있는 옵션을 무조건 현재 네트워크에도 적합하다고 가정하지 마세요. 확실하지 않은 필드는 앱 내 설정 편집 안내에서 의미와 사용 가능한 값을 먼저 확인하세요. 이름만 보고 추측하는 것보다 기존 값을 유지하는 편이 결과를 이해하기 쉽습니다.

[General]
bypass-system = true
dns-server = system

bypass-system은 시스템 관련 트래픽의 우회 동작을 제어하는 옵션입니다. “모든 연결을 직접 접속”한다는 뜻이 아니며 Global Routing의 Direct를 대신하지도 않습니다. 이 값을 변경할 때는 모든 요청이 똑같이 바뀐다고 가정하지 말고, 시스템 트래픽 경로에 미치는 영향을 확인하세요. 일반 웹사이트 접속 문제의 원인이 시스템 서비스와 관련 없다면 도메인 하나를 고치려고 설정 범위를 넓히지 말고 기존 값을 유지할 수 있습니다.

DNS 해석과 규칙 판단은 별개의 단계입니다

dns-server = system은 시스템 DNS 경로를 사용한다는 뜻입니다. 사용자 지정 DNS 주소는 현재 네트워크에서 연결 가능한지와 설정 안내를 함께 확인해야 합니다. 규칙이 판단하려면 요청 정보를 확인할 수 있어야 합니다. 조건에 따라 도메인을 사용하기도 하고 대상 IP를 사용하기도 합니다. DNS는 도메인을 주소로 해석하고 Rule은 처리 정책을 선택합니다. 서로 영향을 주지만 대체할 수는 없습니다. PROXY 규칙을 추가해도 연결할 수 없는 DNS 서버가 복구되는 것은 아닙니다.

DNS over HTTPS를 사용할 때는 DNS 요청의 전송 방식과 최종 웹사이트 연결 정책을 구분해야 합니다. DNS 요청이 HTTPS로 전송된다고 해서 이후 모든 웹 트래픽에 같은 정책이 적용되는 것은 아닙니다. 웹사이트가 PROXY로 연결되는지는 현재 모드와 적용된 규칙에 따라 달라집니다. DNS 서버의 호스트 이름을 먼저 해석해야 한다면 초기 해석 경로도 고려하세요. 출처가 다른 주소를 여러 개 한꺼번에 입력한 뒤 한 번 접속에 성공했다고 모든 주소가 정상 작동한다고 판단하지 마세요.

비교 가능한 기본 설정부터 시작하기

DNS를 조정하기 전에 복구할 수 있도록 기존 설정을 보관하고, 문제가 안정적으로 재현되는 테스트 도메인 하나와 당시 네트워크 유형을 기록하세요. 같은 네트워크와 서버, 규칙을 유지한 채 DNS 설정만 바꾸고 해석 결과와 연결 기록이 달라지는지 확인합니다. 셀룰러 네트워크와 서버, DNS를 동시에 바꾸면 어떤 요소가 차이를 만들었는지 알기 어렵습니다. 네트워크를 바꾼 뒤에는 캐시된 결과가 남을 수 있으므로 검증할 때 새 요청을 만들고 기존 탭만 확인하지 마세요.

지연 시간 테스트에 수치가 표시되는데 웹페이지가 열리지 않더라도, 이는 특정 테스트 요청이 응답을 받았다는 뜻일 뿐 도메인 해석과 대상 연결, 페이지의 모든 리소스가 정상이라는 증거는 아닙니다. 웹페이지는 여러 호스트 이름에 요청을 보낼 수 있으며 그중 하나만 해석에 실패해도 화면에 문제가 생길 수 있습니다. 실제로 실패한 도메인을 찾아 주소를 받았는지, 어떤 정책을 사용했는지, 연결이 어느 단계에서 끊겼는지 확인하세요. 이와 관련해서는 DNS 해석 실패 문제 해결 순서도 참고하세요.

앱에 표시된 필드가 예시와 다르면 현재 앱의 안내를 따르고 알 수 없는 옵션을 억지로 추가하지 마세요. General은 내용을 많이 복사해 “채우는” 곳이 아닙니다. 간결하고 이유를 설명할 수 있는 설정일수록 관리하기 쉽습니다. 유지하는 각 필드에 대해 어떤 동작을 바꾸는지, 왜 바꿔야 하는지, 어떻게 되돌리는지 답할 수 있어야 합니다. DNS 선택에 관한 자세한 내용은 시스템 DNS, 사용자 지정 DNS 및 DNS over HTTPS를 참고하세요. 이 페이지에서는 분기 판단에 필요한 전제를 중심으로 설명합니다.

3. 도메인 규칙과 USER-AGENT 조건

도메인 규칙은 “특정 호스트 이름이나 관련 호스트 이름 그룹에 어떤 정책을 적용할지” 지정할 때 적합합니다. 기본 규칙은 유형, 매칭 값, 정책으로 구성되며 필드는 영문 쉼표로 구분합니다. 매칭 값에는 보통 호스트 이름을 입력하며 프로토콜, 포트, 경로가 포함된 전체 웹 주소는 입력하지 않습니다. 한 웹사이트의 특정 페이지만 다른 정책을 적용하려는 경우 도메인 규칙에 필요한 정보가 있는지 먼저 확인하세요. 같은 호스트의 두 페이지를 경로만으로 구분할 수는 없습니다.

DOMAIN과 DOMAIN-SUFFIX의 적용 범위

DOMAIN은 호스트 이름을 정확히 일치시킬 때 사용하며, 명확한 대상 하나를 따로 처리하기에 적합합니다. DOMAIN-SUFFIX는 지정한 도메인과 그 하위 도메인을 함께 일치시켜 같은 도메인 체계의 요청을 묶어 처리합니다. 아무 문자열이나 끝부분이 일치하는 규칙은 아니며 도메인 경계를 고려합니다. 마지막 글자가 같기만 하면 적용된다고 이해해서는 안 됩니다. 유형을 선택하기 전에 포함하려는 호스트 이름을 나열하면 적용 범위가 지나치게 넓은지 확인하기 쉽습니다.

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

이 규칙에서는 api.example.com이 먼저 DOMAIN에 일치해 DIRECT를 사용합니다. www.example.com은 첫 번째 줄에 일치하지 않고 다음 DOMAIN-SUFFIX에 일치해 PROXY를 사용합니다. 두 줄의 순서를 바꾸면 정확한 도메인도 접미사 규칙이 먼저 처리합니다. 이는 정확 일치 유형이 작동하지 않는다는 뜻이 아니라 앞선 줄에서 이미 매칭이 끝난다는 뜻입니다. 예외를 유지하려면 유형 이름이 우선순위를 자동으로 정해 주길 기대하지 말고 범위가 좁은 조건을 넓은 조건보다 앞에 두세요.

DOMAIN-KEYWORD의 매칭 범위

DOMAIN-KEYWORD는 도메인에 지정한 키워드가 포함되어 있는지 확인하며 특정 조직이나 도메인 체계에 한정되지 않습니다. 키워드가 짧을수록 의도하지 않은 요청까지 포함될 가능성이 커집니다. 문자열 조건이 꼭 필요한 경우에 사용하고, 이미 확인된 정확한 도메인 목록을 흔한 단어 하나로 대체하는 용도로는 적합하지 않습니다. REJECT로 설정할 때는 특히 주의하세요. 잘못 일치한 정상 요청까지 차단되어 이미지 누락, 로그인 실패, 페이지 로딩 지연이 발생할 수 있습니다.

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

예시에서는 확인된 호스트 이름에 예외를 먼저 적용한 다음 키워드 차단을 적용합니다. downloads.example.com에도 ads라는 문자열이 포함되어 있으므로 예외의 위치가 결과를 좌우합니다. 실제 문제를 확인할 때는 “광고 도메인인가?”라는 주관적인 판단만으로 결론 내리지 말고, 실제 비교 대상인 호스트 이름과 규칙 내용을 확인하세요. 매칭 범위가 예상보다 넓다면 예외를 계속 추가해 넓은 조건을 보완하기보다 DOMAIN이나 DOMAIN-SUFFIX를 사용하세요.

USER-AGENT의 적용 한계

USER-AGENT는 요청에서 확인할 수 있는 User-Agent 필드를 기준으로 매칭하며 지원되는 와일드카드 형식으로 조건 값을 입력할 수 있습니다. 앱의 신원을 식별하는 기능이 아니며 특정 프로세스를 정확히 나타내지도 않습니다. 요청에 해당 필드가 없을 수 있고 여러 앱이 비슷한 값을 사용할 수도 있습니다. 암호화되어 필드를 볼 수 없는 트래픽에서는 규칙이 값을 읽을 수 있다고 기대해서는 안 됩니다. 안정적으로 분기해야 한다면 명확한 도메인이나 대상 주소를 먼저 고려하고 이 조건이 적합한지 따져보세요.

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

표의 ExampleClient는 필드 접두어 예시일 뿐 실제 앱을 가리키지 않습니다. USER-AGENT 규칙을 검증하려면 요청에 해당 필드가 실제로 포함되어 있고 앱에서 값을 확인할 수 있는지 먼저 확인하세요. 규칙 한 줄을 적용하려고 추가 트래픽 복호화 설정을 바로 도입해서는 안 됩니다. 암호화된 트래픽에서 확인할 수 있는 정보는 일반 도메인 분기와 별도로 검토하세요. 필드 내용을 확인하기 어렵다면 관찰 가능한 도메인 규칙으로 테스트 조건과 되돌리는 방법을 명확하게 설정할 수 있습니다.

4. IP-CIDR, IP-CIDR6 및 GEOIP

IP 규칙은 웹사이트의 문자 이름이 아니라 대상 주소를 비교합니다. 한 도메인이 여러 주소로 해석될 수 있고 하나의 주소가 여러 도메인에서 사용될 수도 있으므로 주소 조건과 도메인 조건은 같지 않습니다. 특정 웹사이트에 안정적으로 정책을 적용하려는 목적이라면 도메인 규칙이 더 적합한지 먼저 판단하세요. 명확한 로컬 네트워크 대역이나 단일 대상 주소, 주소 소속 범위를 처리하려면 IP 조건을 사용하면 됩니다. 짧은 문법보다 실제로 표현하려는 경계를 기준으로 선택하세요.

접두사 길이로 주소 범위 지정하기

IP-CIDR은 IPv4 주소 범위에 사용합니다. 슬래시 뒤 숫자는 네트워크 접두사 길이이며 포트나 사용 가능한 주소 개수가 아닙니다. 예를 들어 192.168.0.0/16은 사설 주소 범위를, 192.0.2.10/32는 특정 IPv4 주소 하나를 나타냅니다. 입력할 때는 네트워크 주소와 접두사 길이를 명확하게 지정하고 현재 기기에 할당된 주소 하나를 전체 네트워크 대역으로 오해하지 마세요. 대역 경계를 잘못 입력하면 예상보다 훨씬 많은 대상에 규칙이 적용될 수 있습니다.

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

IP-CIDR6은 IPv6 주소 범위에 사용합니다. 예시의 2001:db8::/32는 문서용 예시 범위이며 실제 네트워크를 나타내지 않습니다. 대상이 IPv4와 IPv6를 모두 제공한다면 IPv4 조건만 설정했다고 해서 다른 유형의 연결에도 같은 처리가 적용되는 것은 아닙니다. 연결 기록에서 대상 주소 유형을 확인하세요. 같은 웹페이지에서 결과가 달라지는 것은 규칙 순서가 무작위로 바뀐 것이 아니라 주소 선택이 달라졌기 때문일 수 있습니다.

no-resolve는 DNS를 끄는 옵션이 아닙니다

no-resolve는 일부 주소 규칙에 추가할 수 있는 옵션으로, 해당 규칙의 판단을 위해 도메인 해석을 새로 요청하지 않도록 합니다. 설정 전체에서 해석을 중단하거나 대상에 주소가 영원히 생기지 않는다는 뜻은 아닙니다. 요청 자체가 IP 주소이거나 판단 시점에 사용할 수 있는 주소가 이미 있으면 주소 조건에 따라 비교할 수 있습니다. 로컬 네트워크 주소 규칙에서는 대역 판단을 위해 추가 해석을 하지 않도록 사용할 수 있지만, 추가 여부는 구체적인 매칭 대상을 고려해 결정하세요.

사용할 수 있는 IP 주소가 없다면 no-resolve가 포함된 규칙은 도메인 문자열만으로 대상이 어느 대역에 속하는지 판단할 수 없습니다. 반대로 이 옵션이 없는 주소 조건은 해석을 거칠 수 있으므로 DNS 경로가 판단에 관여할 수 있습니다. 도메인 규칙보다 앞에 많은 주소 규칙을 두면 해석 동작을 이해하기 어려워질 수도 있습니다. 처리 경로를 명확히 제어하려면 알려진 대상은 명확한 도메인 조건으로 먼저 처리하고 나머지 연결을 주소 조건으로 처리하는 편이 확인하기 쉽습니다.

GEOIP는 주소의 지역 정보를 기준으로 판단합니다

GEOIP,CN,DIRECT는 주소 지리 정보 데이터베이스에서 CN으로 분류된 대상을 DIRECT로 처리한다는 뜻입니다. 웹페이지 언어나 도메인 접미사, 회사 등록 국가, 사용자의 현재 위치를 기준으로 판단하지 않습니다. 중국어 콘텐츠를 제공하는 웹사이트가 다른 지역의 주소에 연결될 수 있고, 같은 도메인도 해석 결과가 달라지면 주소 소속이 달라질 수 있습니다. GEOIP 결과를 해석할 때는 웹사이트 이름만 보고 오작동이라고 판단하지 말고 실제 대상 IP도 확인하세요.

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

이 규칙은 example.com 도메인 체계의 요청을 먼저 처리하고 나머지 요청에 GEOIP를 적용합니다. GEOIP를 앞에 두면 해석된 주소가 먼저 GEOIP에 일치해 뒤에 있는 도메인 규칙이 적용되지 않을 수 있습니다. 주소 지리 정보 데이터베이스에는 업데이트 주기와 분류 경계가 있으므로 정확한 서비스 분류 기준으로 간주해서는 안 됩니다. 정책을 반드시 고정해야 하는 일부 주요 도메인은 모든 주소가 계속 같은 지역으로 분류되길 기대하기보다 명확한 예외 조건을 앞에 두는 편이 제어하기 쉽습니다.

로컬 네트워크 대상을 확인할 때는 “규칙에서 DIRECT를 선택함”과 “기기에서 해당 대상에 연결할 수 있음”을 구분해야 합니다. DIRECT는 직접 연결을 선택할 뿐 로컬 네트워크 경로를 만들거나 대상 포트를 수정하거나 접근 권한을 바꾸지 않습니다. 규칙이 올바르게 적용됐는데도 접속할 수 없다면 현재 Wi-Fi와 대상 기기의 상태, 주소가 변경됐는지 확인하세요. 실제 요청이 어떤 주소로 전송되는지 먼저 살펴본 다음 네트워크 대역 규칙을 확인하면, 주소가 만료됐거나 서비스가 수신 대기 중이지 않은 문제를 IP-CIDR 문법 오류로 오인하지 않을 수 있습니다.

5. PROXY, DIRECT, REJECT 및 Global Routing

규칙의 마지막 주요 필드는 보통 처리 정책입니다. 조건은 “어떤 요청인지”, 정책은 “일치한 뒤 어떻게 처리할지”를 정합니다. PROXY, DIRECT, REJECT는 서로 다른 처리 결과이지 속도 설정이나 연결 품질 등급이 아닙니다. 설정을 살펴볼 때는 먼저 정책을 따로 정리하고 각 결과가 용도에 맞는지 확인한 뒤, 조건이 요청을 올바른 경로로 보내는지 검토하세요.

정책 이름에 따라 처리 방식이 달라집니다

PROXY는 요청을 프록시 경로로 보내며 사용 가능한 서버 정보와 관련된 선택이 필요합니다. 규칙에 있는 테스트 도메인으로 서버를 만들어 주거나 구독에 포함된 만료 항목을 복구하지는 않습니다. DIRECT는 대상에 직접 연결하지만 로컬 네트워크와 해석 결과, 대상 서비스 상태에 따라 달라집니다. REJECT는 일치한 요청을 차단하며 차단해야 할 대상이 명확한 경우에 사용합니다. 범위가 불분명한 조건에 적용하면 산발적인 페이지 오류가 발생할 수 있습니다.

설정에서 사용자 지정 정책 이름을 지원하고 있다면 현재 설정에 해당 이름이 실제로 정의되어 있고 참조하는 이름과 완전히 일치하는지 확인하세요. 다른 사람의 파일에 있는 정책 그룹 이름을 자신의 규칙 끝에 붙여 넣고 기존 서버에 자동으로 연결되리라 기대하지 마세요. 공백과 대소문자, 이름 변경 여부도 하나씩 확인해야 합니다. 처음 문제를 점검할 때는 이해하기 쉬운 기본 정책으로 비교해 본 다음 복잡한 정책 구성을 도입하는 편이 오류를 찾기 쉽습니다.

Global Routing에서 설정 적용 방식을 결정합니다

Global Routing의 Config, Proxy, Direct는 각각 설정 기반 처리, 프록시 경로, 직접 연결 방식을 의미합니다. Rule에 따라 요청을 하나씩 분기하려면 Config를 선택하세요. Proxy와 Direct는 전체 연결 경로를 비교할 때 사용할 수 있지만 각 규칙의 정확성을 확인하는 방법은 아닙니다. 모드가 바뀌면 연결 결과만으로 특정 Rule이 적용됐다고 증명할 수 없습니다. 문제를 기록할 때는 모드와 설정 파일을 함께 적으세요. 둘 중 하나라도 빠지면 재현 조건이 불완전할 수 있습니다.

모드 비교로 문제 범위 좁히기

어떤 대상이 Proxy에서는 접속되지만 Config에서는 실패하더라도 설정 전체가 잘못됐다고 바로 판단하지 마세요. Config로 돌아가 해당 대상에 적용된 규칙을 확인하세요. REJECT로 차단됐거나 연결할 수 없는 DIRECT 경로로 전달됐을 수도 있고, 다른 사용자 지정 정책을 사용했을 수도 있습니다. 두 모드에서 모두 실패한다면 서버와 DNS, 대상 서비스 상태를 추가로 확인하세요. 모드 비교는 원인을 찾는 단서이지 특정 필드에 오류가 있다는 최종 결론은 아닙니다.

Global Routing을 전환한 뒤에는 새 연결을 확인해야 합니다. 이미 설정된 세션은 계속 데이터를 전송할 수 있고 앱이 기존 연결을 재사용할 수도 있습니다. 따라서 모드를 연달아 바꾸고 같은 페이지를 빠르게 새로고침하면 결과가 명확하지 않을 수 있습니다. 다른 조건은 그대로 둔 채 구분할 수 있는 요청을 새로 보내고 연결 기록으로 현재 경로를 확인하세요. 웹페이지에 내용이 표시되는지만 보면 캐시의 영향을 받을 수 있습니다. 이전 페이지가 보인다고 방금 요청한 네트워크 연결이 성공했다는 뜻은 아닙니다.

클라이언트 구매와 연결 서비스는 별개로 이해해야 합니다. Shadowrocket은 Apple 플랫폼용 유료 클라이언트이며 클라이언트 일회성 구매 ≠ 회선 요금제입니다. 사용자는 기존 구독 또는 서버 정보를 별도로 이용해야 합니다. 앱 받기와 정품 아이콘, 개발자 확인 방법은 App Store 정품 다운로드 안내를 참고하세요. 기기 호환성과 시스템 요구 사항은 App Store 페이지 표기를 기준으로 합니다. 설정 필드는 기존 연결 동작을 관리하며 별도의 연결 리소스를 제공하지 않습니다.

6. 매칭 순서, 예외 규칙 및 FINAL

Rule의 핵심은 위에서 아래로 조건을 차례로 비교하고 처음 일치한 규칙의 정책을 적용한 뒤 더 적절해 보이는 조건을 찾으러 내려가지 않는다는 점입니다. 규칙 유형 자체에는 “정확한 도메인이 항상 네트워크 대역보다 우선” 같은 자동 우선순위가 없습니다. 우선순위는 먼저 파일 안의 위치에 따라 결정됩니다. 규칙이 적용되지 않는 이유를 확인할 때는 해당 규칙 문법만 반복해서 살펴보지 말고 위쪽 항목부터 확인하세요.

예외를 먼저, 넓은 범위는 다음에 처리

조건은 명확한 예외를 앞에 두고, 범위가 넓은 도메인 또는 주소 조건을 그 뒤에 배치한 다음 마지막에 기본 처리 규칙을 두는 방식으로 정리하는 것이 좋습니다. 이는 관리하기 편한 구성 방법이지 모든 파일에 같은 분류 순서를 강제하는 규칙은 아닙니다. 실제 결과는 각 대상이 처음 일치하는 위치에 따라 결정됩니다. 예를 들어 특정 로컬 네트워크 서비스를 따로 처리하려면 넓은 도메인 또는 주소 조건이 먼저 적용되지 않는지 확인해야 합니다. 로컬 네트워크에 속한다는 이유만으로 자동 우선 처리된다고 가정해서는 안 됩니다.

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

이 예시에서는 api.example.com이 첫 번째 규칙에 일치해 접미사 조건까지 내려가지 않습니다. ads.example.com은 두 번째 규칙에서 차단되고, 나머지 example.com 하위 도메인은 PROXY를 사용합니다. 그 뒤에야 아직 일치하지 않은 주소 범위와 GEOIP를 처리합니다. 규칙을 살펴볼 때는 구체적인 대상 세 개를 골라 첫 줄부터 순서대로 판단하고 처음 성립하는 조건을 표시해 보세요. 이렇게 하면 예외 위치 오류와 조건 중복, 너무 앞에 놓인 기본 처리 규칙을 쉽게 찾을 수 있습니다.

FINAL은 조건 없는 기본 처리 규칙입니다

FINAL은 앞선 모든 조건에 일치하지 않은 연결을 처리합니다. 일반적인 작성 예시는 FINAL,PROXY 또는 FINAL,DIRECT입니다. 도메인이나 주소 매칭 값이 없으므로 일반 도메인 규칙과 필드 수가 다릅니다. Rule 섹션에서 유효한 규칙의 마지막에 배치하세요. 뒤에 DOMAIN 항목을 추가해도 더 구체적이라는 이유로 다시 판단되지 않습니다. 오히려 “작성했는데도 적용되지 않는다”는 혼란을 일으킬 수 있습니다.

FINAL의 정책을 선택하기 전에 기본 경로를 명확히 하세요. FINAL,PROXY는 별도로 분류되지 않은 연결을 프록시 경로로 보내고 FINAL,DIRECT는 직접 연결합니다. 어느 쪽이든 앞선 규칙과 함께 검토해야 합니다. 같은 앞쪽 조건이라도 기본 처리 방식을 바꾸면 적용 범위가 달라집니다. 기본 처리는 영향이 크므로 수정 전에 주요 대상 몇 개가 실제로 어떤 위치에서 일치하는지 확인하세요. 사이트 하나를 고치려다가 분류되지 않은 모든 트래픽의 경로를 바꾸지 않도록 주의해야 합니다.

중복 규칙과 원격 콘텐츠 정리

중복 항목이 반드시 문법 오류를 일으키는 것은 아니지만 읽고 관리하기는 더 어려워집니다. 조건이 완전히 같은데 정책이 다른 두 항목은 뒤의 항목이 앞선 항목에 가려지는 경우가 많습니다. 비슷하지만 범위가 다른 조건은 대상을 하나씩 확인해야 합니다. 정리할 때 알파벳순으로만 정렬하면 의도적으로 둔 예외의 순서가 깨질 수 있습니다. 각 규칙 그룹의 목적을 먼저 표시하고, 확실히 중복된 항목을 제거한 뒤 매번 주요 도메인을 다시 검증하세요.

서로 다른 출처의 조각을 합칠 때는 섹션 이름 중복과 FINAL 중복, 기존 기본 처리 규칙 뒤에 섹션 전체를 붙이는 문제가 자주 발생합니다. 먼저 각 조각이 어느 섹션에 속하는지 확인하고 불필요한 섹션 머리글을 제거한 뒤 예상한 위치에 규칙을 넣으세요. 사용자 지정 정책을 참조하는 조각이라면 필요한 정책이 현재 설정에 있는지 먼저 확인해야 합니다. 텍스트에 복사할 수 있다고 해서 현재 설정의 구조와 정책, 기본 경로에 맞는 것은 아닙니다.

긴 목록을 관리할 때는 변경 기록에 “무엇을 추가했는지”뿐 아니라 “왜 이 위치에 두었는지”도 적으세요. 예를 들어 정확한 도메인을 접미사 규칙보다 앞에 둔 것은 직접 연결 예외를 유지하기 위해서일 수 있고, 키워드 규칙을 제거한 것은 정상 리소스까지 포함했기 때문일 수 있습니다. 이런 배경은 나중에 문제를 해결할 때 규칙 개수보다 더 유용합니다. 예상하지 못한 규칙이 적용되면 관련 항목 몇 개로 범위를 좁혀 검증한 다음 전체 파일에 반영하세요. 반대되는 규칙을 계속 추가하며 운에 맡기지 마세요.

7. Host와 URL Rewrite의 역할 범위

Host, URL Rewrite, Rule은 각각 주소 매핑과 요청 주소 재작성, 정책 선택을 담당하므로 서로 혼동해서는 안 됩니다. 설정에 이 섹션들이 모두 있다고 해서 문제를 해결할 때마다 전부 수정할 필요는 없습니다. 특정 도메인을 PROXY로 보내려는 목적이라면 먼저 Rule을 사용하세요. 명확한 호스트 이름에 주소를 지정하려면 Host를 검토하고, 조건에 맞는 URL을 변경해야 할 때만 URL Rewrite를 확인하세요. 기능 범위를 구분하면 효과는 있어 보여도 이유를 설명하기 어려운 수정이 줄어듭니다.

Host는 호스트 이름의 주소를 지정합니다

Host의 기본 형식은 호스트 이름, 등호, 대상 주소이며 전체 웹 URL을 입력하지 않습니다. Host는 해당 호스트 이름에 연결되는 주소 정보를 바꾸며 PROXY 또는 DIRECT를 직접 지정하지 않습니다. Host에서 도메인에 주소를 지정해도 연결은 현재 모드와 관련 규칙에 따라 처리됩니다. Host 줄 끝에 정책 필드를 임의로 추가해 도메인 분기까지 처리하려 하지 마세요. 주소 매핑과 정책 조건은 각각 해당 섹션에 작성해야 합니다.

[Host]
service.example.com = 192.0.2.10

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

예시 주소는 문서 설명용이며 실제 접속에 사용할 수 없습니다. 실제 매핑을 설정하기 전에 대상 서비스의 신뢰할 수 있는 설정에서 주소를 확인하고 언제 되돌려야 하는지도 알아두세요. 웹사이트는 동적 주소나 여러 서비스 진입점을 사용하거나 주소마다 다른 콘텐츠를 제공할 수 있습니다. 과거에 작동했던 주소 하나를 계속 고정하면 서비스 변경 후 연결되지 않을 수 있습니다. 진단을 위해 임시로 Host를 사용한다면 기존 상태를 기록하고 테스트가 끝난 뒤 복구해 진단용 설정에 장기간 의존하지 않도록 하세요.

Host가 임의의 서버를 대상 웹사이트로 바꿔 주는 것은 아닙니다. HTTPS 연결에는 호스트 이름과 인증서, 서버 측 처리 방식이 관련되므로 주소에 연결할 수 있다고 해서 인증서와 콘텐츠도 일치하는 것은 아닙니다. 매핑을 바꾼 뒤 인증서 오류가 발생해도 접속을 유지하려고 인증서 검증을 약화하지 마세요. 도메인과 주소가 실제로 같은 서비스에 속하는지 확인해야 합니다. 원래 여러 주소를 사용하는 대상이라면 하나의 주소로 고정할 때 사용 가능성과 연결 선택 방식이 달라질 수도 있습니다.

URL Rewrite는 명확한 조건에 따라 주소를 재작성합니다

URL Rewrite 항목은 보통 매칭 표현식과 대체 대상, 처리 방식으로 구성됩니다. 아래 예시는 명확한 호스트 이름의 HTTP 주소를 HTTPS로 리디렉션하며 302는 임시 리디렉션을 뜻합니다. 정규식에서 점은 임의의 문자를 나타내므로 이스케이프해야 합니다. 앞쪽 앵커는 주소의 시작부터 일치하도록 제한합니다. 예시는 기본 구조만 보여줍니다. 활성화하기 전에 통제된 대상을 사용해 매칭 범위와 실제 응답을 확인하고 모든 도메인으로 바로 확대하지 마세요.

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

재작성 규칙이 대상에서 HTTPS를 제공하는지, 리디렉션 후에도 로그인과 경로, 요청 방식의 의미가 유지되는지를 보장하지는 않습니다. 경로를 유지해야 한다면 캡처 그룹과 대체 참조의 관계를 먼저 이해하고 웹사이트 첫 화면만 확인하지 말고 여러 주소로 검증하세요. 재작성된 대상이 반대 방향의 다른 규칙에 다시 걸려 리디렉션 루프가 발생하지 않도록 해야 합니다. 브라우저에 리디렉션이 너무 많다고 표시되면 조건과 대상이 서로 겹치는지 먼저 확인하세요.

요청 정보 확인 범위와 추가 설정을 따로 검토하세요

암호화된 요청에 URL 수준의 처리를 적용할 수 있는지는 앱에서 어떤 요청 정보를 확인할 수 있는지와 필요한 기능 전제가 충족됐는지에 따라 달라집니다. 도메인 분기가 작동한다고 해서 모든 URL 경로를 읽을 수 있는 것은 아닙니다. 예시의 재작성 규칙을 적용하려고 이해하지 못한 트래픽 복호화 설정을 함께 켜지 마세요. 인증서와 암호화 처리는 추가적인 신뢰 범위와 관련되므로 실제 필요와 영향을 이해한 뒤 별도로 설정해야 합니다. 이 페이지에서는 일반 규칙 분기의 전제 조건으로 다루지 않습니다.

Host, URL Rewrite, Rule을 함께 사용한다면 문제를 해결할 때 한 번에 한 종류의 변경만 비활성화하세요. 먼저 기존 주소 매핑을 복원하고 새 요청을 만들어 대상 IP를 확인합니다. 다음으로 URL이 예상대로 재작성됐는지 살펴보고 마지막으로 적용된 정책을 확인하세요. 이렇게 하면 “잘못된 주소에 접속함”, “잘못된 위치로 이동함”, “잘못된 경로를 선택함”을 구분할 수 있습니다. 정책 선택이 올바르더라도 주소 매핑 오류나 리디렉션 루프를 해결할 수 없으므로 세 가지 문제를 모두 DOMAIN-SUFFIX 추가로 해결하려 하지 마세요.

8. 설정 검증, 문제 원인 확인 및 복구

설정 검증의 목표는 테스트 페이지가 가끔 열리는 것이 아니라 결과를 재현할 수 있고 원인을 설명할 수 있으며 수정을 되돌릴 수 있는지 확인하는 것입니다. 시작하기 전에 현재 네트워크와 Global Routing, 설정 파일, 사용 중인 서버를 기록하고 문제가 안정적으로 재현되는 대상을 선택하세요. 그런 다음 설정이 저장되어 실제로 사용 중인지 확인하고 새 연결을 시작합니다. 이 단계가 확인되지 않으면 이후 결과가 이전 파일이나 기존 연결, 페이지 캐시에서 비롯됐을 수 있어 방금 수정한 규칙을 판단하는 근거로 삼기 어렵습니다.

연결 과정을 나눠 문제 확인하기

한 번의 접속은 도메인 해석과 조건 판단, 정책 선택, 대상 연결, 콘텐츠 응답 단계로 나눠 확인할 수 있습니다. 먼저 어느 단계에서 실패했는지 판단하세요. 해석 결과가 없으면 DNS를 확인하고, 잘못된 규칙에 일치하면 순서를 확인합니다. PROXY 연결이 실패하면 기존 서버 정보와 연결 가능성을 살펴보고 대상 응답에 문제가 있을 때는 웹사이트 서비스를 확인하세요. 모든 네트워크 구현이 반드시 같은 내부 순서를 거친다는 뜻이 아니라 작업할 때 변수를 하나씩 제외해 무관한 필드를 동시에 수정하지 않도록 하기 위한 순서입니다.

1. 현재 선택된 Config와 Global Routing을 확인해 파일과 모드가 일치하는지 살펴봅니다.
2. 주소 표시줄만 보지 말고 실제 요청의 호스트 이름과 대상 IP, 주소 유형을 확인합니다.
3. 적용된 규칙과 정책을 확인하고 파일 순서에 따라 직접 검토합니다.
4. 다른 조건은 유지하고 필드 하나만 조정한 뒤 새 연결을 만듭니다.
5. 주요 기능을 다시 테스트하고 복구를 확인한 뒤 변경 이유와 복원용 사본을 기록합니다.

웹페이지에는 기본 페이지 외에도 이미지와 API, 인증 등 여러 요청이 포함되는 경우가 많습니다. 첫 화면은 표시되는데 로그인에 실패한다면 관련 도메인 하나가 REJECT되거나 다른 경로를 사용하고 있을 수 있습니다. 주소 표시줄의 호스트 이름만 보고 모든 트래픽을 판단해서는 안 됩니다. 실제로 실패한 요청을 찾아 해당 조건을 확인하세요. 키워드 규칙이 여러 리소스에 일치한다면 웹사이트 전체와 모든 하위 도메인의 정책을 한꺼번에 바꾸기보다 해당 규칙 범위를 좁혀 비교하는 편이 원인을 찾기 쉽습니다.

증상에 따라 다음 확인 단계 선택하기

Connectivity Test는 서버 응답을 비교하는 데 도움이 되지만 실제 서비스 요청과 측정 대상 및 방식이 완전히 같지는 않습니다. 수치가 정상이라고 모든 대상과 프로토콜, 리소스가 성공한다고 볼 수 없습니다. 특정 테스트에 응답이 없다고 구체적인 서비스 상태와 관계없이 모든 연결이 실패했다고 판단해서도 안 됩니다. 테스트 결과를 단서로 삼고 실제 연결 기록과 함께 확인하세요. 기존 서버 필드를 확인하려면 가져온 출처로 돌아가 항목별로 살펴보세요. 주소나 인증 정보 오류를 감추려고 규칙을 바꾸지 마세요.

최소 재현 사례를 만든 뒤 전체 설정에 반영하기

전체 파일이 길다면 테스트 전용 파일을 복사해 현재 문제를 이해하는 데 필요한 General 설정과 명확한 대상 조건 하나, FINAL만 남기세요. 기본 경로를 먼저 검증한 뒤 기존 규칙을 그룹별로 추가하면서 문제가 다시 나타나는 시점을 확인합니다. 추가할 때마다 원래의 상대적 순서를 유지하고 포함한 범위를 기록하세요. 이렇게 하면 수백 줄을 계속 추측하는 대신 충돌을 일으킨 항목을 찾을 수 있습니다. 테스트 후에는 검증된 변경 사항을 정식 파일에 반영하고 실수로 테스트 파일을 계속 사용하지 않는지 확인하세요.

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

이 예시는 “지정한 대상과 나머지 연결을 분리해” 검증하는 방법을 설명하며 연결에 필요한 모든 정보는 포함하지 않습니다. 재현 기록에는 예상 정책과 실제 정책, 관련 규칙 위치를 적고 구독 주소와 인증 정보, 개인 식별 정보는 숨기세요. 설정 업데이트 후 문제가 다시 발생한다면 업데이트 전후의 관련 섹션을 비교해 출처의 내용이 수정을 덮어썼는지, 서버와 DNS 또는 대상 주소가 실제로 바뀌었는지 확인하세요. 모든 업데이트를 같은 원인으로 단정하지 마세요.

복구한 뒤에는 문제 해결을 마치기 전에 기존 주요 대상에 다시 접속할 수 있는지 확인하세요. 문제 증상과 처음 일치한 조건, 최종 수정 사항, 복구 방법을 간단히 기록해 두세요. 일반적인 질문은 문제 해결에서 확인할 수 있습니다. 첫 연결 과정은 사용 가이드를, 구매와 복원 및 App Store 확인은 정품 확인 안내를 참고하세요. 규칙 관리가 완료됐다는 기준은 기억에 의존해 다시 수정하는 것이 아니라 다음에 같은 문제가 생겼을 때 동일한 절차로 검증할 수 있는 것입니다.