이 글은 Shadowrocket에서 연결을 설정하고 Config를 수정하려는 사용자를 위한 안내입니다. 먼저 Global Routing을 확인한 뒤, 구체적인 예외를 앞에 두고 일반 규칙을 이어 배치한 다음 FINAL을 맨 끝에 둡니다. 도메인과 IP 예시를 통해 매칭 조건과 처리 정책을 구분하고, 새 연결로 결과를 확인합니다. 구독은 서비스 제공업체에서 별도로 받아야 하며, 연결 서비스와 앱 구매는 각각 별도로 관리됩니다.
먼저 Global Routing 확인
사용자 지정 규칙이 적용되는지는 먼저 Home → Global Routing에서 현재 선택한 항목에 따라 달라집니다. Config는 현재 활성화된 설정에 따라 연결을 처리합니다. Proxy와 Direct는 전체 연결을 다르게 처리하는 모드입니다. Proxy 모드에서는 규칙 순서를 테스트하지 말고, Direct 모드에서 대상에 접속된다는 이유만으로 특정 DIRECT 규칙이 적용됐다고 판단하지 마세요.
Config
권장현재 활성화된 Config의 규칙에 따라 연결 정책을 결정합니다. 결과는 PROXY, DIRECT 또는 REJECT일 수 있으며, 규칙에 일치하지 않는 연결이 반드시 직접 연결되는 것은 아닙니다.
용도: 사용자 지정 규칙을 작성하고 확인한 뒤 일상적으로 사용합니다.
Proxy
전체 연결을 프록시로 처리하며, 이 글에서 설명하는 일반 규칙 순서에 따른 라우팅 테스트에는 적합하지 않습니다. 설정된 프록시 연결이 작동하는지 확인하는 데 활용할 수 있습니다.
용도: 프록시 연결 문제와 규칙 문제를 잠시 분리해 확인합니다.
Direct
전체 연결을 직접 연결로 처리합니다. 대상에 접속할 수 있어도 현재 직접 연결 경로가 작동한다는 뜻일 뿐, Config의 특정 규칙이 적용됐다는 증거는 아닙니다.
용도: 현재 네트워크에서 직접 연결이 되는지 비교합니다.
Global Routing에서 Scene을 사용할 수도 있습니다. Scene은 설정된 조건에 따라 작동합니다. 문제를 확인할 때는 먼저 기존 설정을 기록하고, Scene 전환으로 생긴 변화를 규칙 변경으로 오해하지 않도록 Config를 임시로 명시 선택하세요. Settings → On Demand에서는 연결이 시작되는 조건을 관리하며, [Rule]의 매칭 순서는 조정하지 않습니다. 테스트 중에는 네트워크와 연결 조건을 가능한 한 그대로 유지하세요.
결론: 테스트 조건부터 고정
Global Routing이 Config로 설정되어 있고 대상 설정이 활성화되어 있는지 확인한 뒤 규칙을 하나 수정하세요. 그렇지 않으면 설정 문구가 올바르더라도 접속 결과만으로 변경 사항의 적용 여부를 판단할 수 없습니다.
규칙 문법과 첫 번째 일치 항목
일반적인 규칙은 “유형,매칭 내용,정책” 형식이며, 영문 쉼표로 구분합니다. FINAL에는 매칭 내용이 필요하지 않으므로 보통 필드가 두 개뿐입니다. 규칙 키워드와 정책은 영문 그대로 쓰고, 키워드 안에 한국어 문장 부호를 넣지 마세요. 아래는 설정 텍스트 예시이며 앱 화면이 아니고 모든 네트워크에 적용되는 완성된 설정도 아닙니다.
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
확인할 도메인이 login.example.com이라고 가정해 보겠습니다. 첫 번째 DOMAIN 규칙이 일치하면 DIRECT가 적용되고, 다음 DOMAIN-SUFFIX 규칙에서 PROXY로 바뀌지 않습니다. 두 규칙의 순서를 바꾸면 더 넓은 범위를 대상으로 하는 접미사 규칙이 먼저 일치해 같은 도메인에 PROXY가 적용됩니다. 더 구체적인 규칙은 앞에 배치해야 예외로 작동하며, 앞선 규칙을 자동으로 덮어쓰는 우선순위는 없습니다.
DOMAIN,example.com,DIRECT: 해당 도메인과 정확히 일치하며 하위 도메인을 자동으로 포함하지 않습니다.DOMAIN-SUFFIX,example.com,PROXY:example.com자체와 하위 도메인에 일치합니다. 이 문자열이 포함된 모든 도메인을 대상으로 하는 규칙은 아닙니다.FINAL,PROXY: 앞선 규칙에 하나도 일치하지 않는 경우 PROXY를 적용합니다. 각 규칙에 추가로 적용되는 두 번째 판정 조건은 아닙니다.
PROXY, DIRECT, REJECT
매칭 조건은 “이 규칙이 어떤 대상을 처리하는가”를, 정책은 “일치한 뒤 어떻게 처리하는가”를 나타냅니다. DOMAIN-SUFFIX 자체가 프록시를 의미하지 않고, IP-CIDR 자체가 직접 연결을 의미하지도 않습니다. 같은 매칭 유형에도 서로 다른 정책을 지정할 수 있습니다. 수정할 때는 조건과 정책을 따로 확인하고, 줄의 첫 키워드만 보고 판단하지 마세요.
| 정책 | 처리 방식 | 확인할 사항 |
|---|---|---|
PROXY | 프록시 경로를 통해 처리합니다. | 현재 선택된 프록시, 정책 참조 및 연결 상태를 확인합니다. |
DIRECT | 대상에 직접 연결합니다. | 현재 네트워크에서 대상에 연결할 수 있는지 확인합니다. |
REJECT | 일치한 연결을 거부합니다. | 차단 범위에 필요한 도메인이 잘못 포함되지 않았는지 확인합니다. |
PROXY는 연결 서비스를 만들지 않으며, 사용할 수 없는 연결을 자동으로 복구하지도 않습니다. 설정에서 사용자 지정 정책 그룹 이름을 사용하는 경우에는 해당 이름의 정의와 선택 상태도 확인해야 합니다. 다른 설정의 그룹 이름을 규칙 끝에 그대로 붙이지 마세요. 여기서는 규칙 순서를 쉽게 확인할 수 있도록 세 가지 기본 정책만 사용하며, 기존 정책 그룹을 모두 바꾸라는 뜻은 아닙니다.
[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
이 예시에서는 blocked.example.com이 첫 번째 규칙에서 차단되고, login.example.com에는 DIRECT, docs.example.com에는 PROXY가 적용됩니다. 나머지 일치하지 않는 대상에는 FINAL에 따라 직접 연결이 적용됩니다. 도메인은 문법 설명용이며, 사용자가 접속해야 하는 주소가 아니고 연결 서비스를 제공한다는 의미도 없습니다.
IP-CIDR와 GEOIP의 적용 범위
IP-CIDR은 IPv4 주소가 지정된 네트워크 대역에 포함되는지 판단하며, 웹사이트 이름을 기준으로 분류하지 않습니다. 192.168.0.0/16은 192.168.0.0부터 192.168.255.255까지의 주소를 포함하지만 10.0.0.0/8은 포함하지 않습니다. 로컬 기기를 직접 연결하려면 실제 주소와 서브넷을 확인하세요. 한 대역이 모든 로컬 네트워크를 포함한다고 가정하지 마세요.
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
GEOIP,CN,DIRECT
FINAL,PROXY
- no-resolve: 해당 IP 규칙을 매칭하기 위해서만 도메인 조회를 시작하지 않도록 합니다. 설정 전체에서 DNS 사용을 중단한다는 뜻은 아닙니다. 이미 사용할 수 있는 대상 IP가 있다면 해당 주소에 대한 판단에는 계속 적용될 수 있습니다.
- GEOIP: 대상 IP의 지리적 위치 정보를 기준으로 판단합니다. 웹페이지 언어, 도메인 접미사 또는 사용자의 위치를 기준으로 하지 않습니다. CDN 주소, DNS 조회 결과, 위치 정보 데이터에 따라 결과가 달라질 수 있습니다.
- IPv6: IPv4 네트워크 대역 규칙은 IPv6 주소에 자동으로 적용되지 않습니다. IPv6를 사용하는 경우 주소 규칙과 네트워크 설정을 별도로 확인해야 하며, 위의 세 가지 예만으로 전체 주소 범위가 처리된다고 볼 수 없습니다.
특정 도메인에 항상 지정된 정책을 적용하려면 명확한 DOMAIN 또는 DOMAIN-SUFFIX 규칙을 사용하고, 먼저 일치할 수 있는 일반 규칙보다 앞에 배치하세요. 도메인 하나의 라우팅 문제를 해결하려고 GEOIP 규칙을 모두 삭제하지 마세요. 실제로 어떤 규칙이 적용됐는지 확인한 뒤 수정 범위를 정하세요.
FINAL 기본 처리와 안전한 수정 절차
FINAL은 보통 [Rule] 맨 끝에 둡니다. 앞선 규칙에 일치하지 않은 연결만 FINAL까지 도달하므로, 그 뒤에 일반 규칙을 추가해도 대개 기대한 결과를 얻을 수 없습니다. FINAL,PROXY와 FINAL,DIRECT 중 무엇을 선택할지는 분류되지 않은 연결을 어떻게 처리할지에 따라 달라집니다. 둘 다 명시적인 정책이며 모든 사용자에게 맞는 하나의 정답은 없습니다.
-
백업 보관
Config로 이동해 현재 활성화된 파일을 확인하고, 먼저 복구할 수 있는 사본을 보관하세요. 원래 FINAL, 정책 그룹 이름 및 규칙 순서를 기록해 원격 설정을 덮어쓸 때 사용자 지정 내용이 사라지지 않도록 합니다.
-
모드 고정
Home → Global Routing에서 Config를 선택하세요. Config로 돌아가 편집하려는 파일과 실제 활성화된 파일이 같은지 확인하세요. 이름만 비슷한 다른 사본을 수정하지 않도록 주의합니다.
-
예외 규칙 추가
해당 파일의 [Rule] 섹션에서 정확한 DOMAIN 예외를 관련 DOMAIN-SUFFIX 규칙보다 앞에 두세요. 새 규칙은 FINAL보다 위에 있어야 하며, 영문 쉼표와 기존 섹션 경계를 유지해야 합니다.
-
기본 처리 확인
[Rule] 끝에 있는 FINAL이 의도한 정책인지 확인하세요. 같은 목적으로 FINAL을 여러 개 연달아 추가하거나 도메인을 포함한 3개 필드 규칙으로 작성하지 마세요.
-
새 연결로 확인
저장한 뒤 설정이 활성화됐는지 확인하고, 대상 앱에서 연결을 새로 만드세요. 연결 기록에서 대상 도메인 또는 IP, 일치한 규칙, 적용된 정책을 확인합니다. 결과가 다르면 먼저 백업을 복원한 다음 항목별로 수정하세요.
규칙 수정은 주로 이후에 새로 만들어지는 연결의 판단에 영향을 줍니다. 이미 연결된 장시간 세션은 이전 경로를 계속 사용할 수 있습니다. 테스트할 때는 기존 세션을 종료하고, 중단해도 되는 작업이라면 다시 연결한 뒤 같은 대상에 접속하세요. 파일 전송이나 통화 중에는 모드를 반복해서 바꾸지 마세요. 연결 중단을 규칙 문법 오류로 오해할 수 있습니다.
규칙이 적용되지 않을 때 확인할 사항
먼저 “이 설정 파일을 사용 중인가”를 확인하고, 다음으로 “어떤 대상이 매칭됐는가”, 마지막으로 “정책을 적용한 뒤 연결할 수 있는가”를 살펴보세요. 웹페이지가 열리지 않는다고 REJECT가 적용된 것은 아닙니다. 페이지가 열려도 관련된 모든 도메인에 같은 정책이 적용됐다는 뜻은 아닙니다. 로그인, 이미지, 동영상 요청은 서로 다른 도메인을 사용할 수 있으므로 실제 연결별로 확인해야 합니다.
DIRECT를 지정했는데 왜 PROXY로 연결되나요?
먼저 Home → Global Routing이 Config인지 확인한 다음, DIRECT 규칙보다 앞에 있는 DOMAIN-SUFFIX 등의 규칙이 같은 대상에 일치하는지 살펴보세요. 구체적인 예외를 범위가 넓은 규칙보다 앞에 옮기고 저장한 뒤 연결을 새로 만드세요. 목록에서 프록시 선택만 반복해서 바꾸지는 마세요.
규칙을 맨 아래에 추가했는데 왜 달라지지 않나요?
현재 Config의 [Rule]을 열어 FINAL을 찾으세요. 새 규칙이 FINAL 뒤에 있다면 앞으로 옮기세요. 앞에 더 넓은 범위의 매칭 규칙이 있으면 상대적인 순서도 조정해야 합니다. 한 번에 한 규칙씩 옮기면 어떤 변경이 결과에 영향을 줬는지 확인하기 쉽습니다.
IP-CIDR에 no-resolve를 넣었는데 왜 도메인이 일치하지 않나요?
해당 연결을 판단할 때 사용할 수 있는 대상 IP가 이미 있는지 확인하세요. no-resolve는 이 규칙을 위해 도메인을 추가로 조회하지 않습니다. 특정 도메인에 고정 정책을 적용하려는 목적이라면 명확한 DOMAIN 또는 DOMAIN-SUFFIX를 사용해 일반 IP 규칙보다 앞에 두세요.
REJECT 규칙 하나 때문에 페이지가 제대로 작동하지 않습니다. 어떻게 되돌리나요?
먼저 백업에서 해당 변경을 복원하거나 방금 추가한 REJECT 규칙만 삭제한 뒤 연결을 새로 만들어 확인하세요. 차단된 도메인이 로그인, 스크립트 또는 리소스도 제공하는지 살펴보세요. 범위를 좁혀야 한다면 지나치게 넓은 접미사 규칙 대신 정확한 DOMAIN을 사용하세요.
업데이트 후 규칙이 원래대로 돌아갔습니다. 무엇을 확인해야 하나요?
Config에서 현재 활성화된 파일, 원격 출처, [Rule] 내용을 확인해 업데이트가 로컬 수정 사항을 덮어썼는지 확인하세요. 보관해 둔 사본을 먼저 복원한 다음 사용자 지정 규칙을 관리할 방법을 정하세요. 연결 구독을 반복해서 업데이트하는 것은 설정 규칙을 복원하는 방법이 아닙니다.
문제 확인이 끝나면 결과를 설명할 수 있는 최소한의 규칙만 남기세요. 각 예외에는 명확한 대상과 목적이 있어야 하며, FINAL은 규칙에 일치하지 않는 연결의 기본 처리만 담당해야 합니다. 화면 용어를 더 확인하려면 용어집을 참고하세요. 연결 경로가 계속 작동하지 않으면 규칙을 더 추가하기보다 문제 해결 안내에 따라 네트워크와 프록시 연결을 점검하세요.