Shadowrocket에서 직접 설정을 가져온 뒤 특정 도메인의 연결 경로를 조정하려는 사용자를 위한 안내입니다. 규칙을 순서대로 확인하는 방법, 자주 쓰이는 세 가지 정책, FINAL의 기본 처리 방식을 예시로 살펴보고, 규칙이 예상대로 적용되지 않을 때 확인할 순서도 안내합니다.
먼저 규칙 모드 확인: Config와 규칙별 처리
Home에서 Global Routing을 확인하세요. Config를 선택하면 현재 구성 파일의 규칙에 따라 연결이 처리됩니다. Proxy 또는 Direct를 선택하면 각각 해당 전역 라우팅 모드가 적용되므로 특정 사용자 지정 분할 규칙을 확인하기에 적합하지 않습니다. Scene은 상황에 따라 라우팅을 선택하는 별도 모드로, Config에서 규칙을 하나씩 테스트하는 것과 혼동하지 마세요. 문제를 확인하기 전에 사용 중인 구성 파일과 선택된 프록시를 메모해 두면, 한 파일을 수정하고 다른 파일을 테스트하는 일을 피할 수 있습니다.
규칙은 목록 맨 위부터 요청이 각 행의 조건에 해당하는지 확인하는 방식으로 읽습니다. 조건과 일치하는 규칙을 찾으면 해당 행의 정책을 적용하고, 뒤에 있는 규칙은 더 이상 확인하지 않습니다. 도메인 접미사, 대상 IP의 대역, 지리적 위치는 서로 다른 판단 조건이므로 파일에 적힌 이름만 보고 우선순위를 추측해서는 안 됩니다. 하나의 요청이 두 규칙에 모두 해당할 수 있다면, 먼저 배치된 규칙이 결과를 결정합니다.
규칙 한 줄의 구성: 조건, 대상, 정책
일반적인 규칙은 필드를 영문 쉼표로 구분합니다. DOMAIN-SUFFIX,example.com,PROXY는 도메인이 example.com이거나 .example.com으로 끝나면 PROXY를 적용한다는 뜻입니다. GEOIP,CN,DIRECT는 IP의 지리적 위치가 조건과 일치하면 DIRECT를 적용한다는 뜻입니다. 여기서 example.com은 문서용 예시 도메인이며, 가져와야 하는 서비스 주소가 아닙니다. 규칙을 편집할 때는 키워드, 쉼표, 정책 이름을 영문 그대로 사용하고 한글 문장부호를 섞지 마세요.
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,ads.example.com,REJECT
IP-CIDR,192.0.2.0/24,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY위의 다섯 줄은 구조를 보여 주기 위한 예시이며, 기존 설정을 그대로 덮어쓰라는 뜻은 아닙니다. 192.0.2.0/24는 문서용 예시 대역입니다. IP-CIDR에서 슬래시 뒤 숫자는 프리픽스 길이를 나타내며, 실제 편집 시에는 일치시킬 대상 대역을 입력해야 합니다. REJECT는 조건에 해당하는 요청을 거부하고, DIRECT는 선택한 프록시를 거치지 않고 직접 연결하며, PROXY는 현재 구성에서 지정한 프록시 경로로 처리합니다. DIRECT로 대상에 접속할 수 있는지는 현재 네트워크와 대상에 실제로 연결할 수 있는지에 따라 달라집니다.
도메인 및 주소 조건
- DOMAIN-SUFFIX
- 지정된 도메인과 하위 도메인에 일치
- IP-CIDR
- 지정된 대상 IP 대역에 일치
- GEOIP
- 대상 IP의 지리적 위치 조건으로 일치
도메인 조건과 IP 조건은 확인 대상이 다릅니다. 규칙을 조정하기 전에 요청이 실제로 접속하는 대상을 확인하세요.
정책 및 기본 처리
- PROXY
- 선택한 프록시 경로로 처리
- DIRECT
- 대상에 직접 연결
- REJECT
- 요청 거부
- FINAL
- 앞선 규칙에 일치하지 않은 요청의 정책 지정
정책은 조건 뒤에 씁니다. FINAL에는 도메인이나 대역을 입력할 필요가 없습니다.
구체적인 예외를 먼저, 넓은 조건은 나중에
예를 들어 ads.example.com은 REJECT하고 나머지 example.com 도메인은 PROXY로 처리하려면, 더 구체적인 하위 도메인 규칙을 범위가 넓은 접미사 규칙보다 위에 배치해야 합니다. 앞의 코드 블록 순서대로라면 ads.example.com 요청은 첫 번째 줄인 DOMAIN-SUFFIX,example.com,PROXY에 먼저 일치하므로 두 번째 줄의 REJECT는 확인되지 않습니다. 규칙 이름이 더 구체적으로 보여도 뒤에 있는 규칙이 자동으로 앞서 적용되지는 않습니다.
- Config에서 현재 사용하는 구성 파일을 열고 수정할 규칙 구간을 찾으세요. 비교할 수 있도록 수정 전 규칙 내용을 따로 보관해 두세요.
ads.example.com만 대상으로 하는 규칙을example.com접미사 규칙 위에 배치하세요. 저장한 뒤 목록에 표시된 순서를 다시 확인합니다.- Global Routing을 Config로 유지한 상태에서 대상에 새 요청을 보내고, 앱 내 연결 기록에서 대상과 실제 적용된 정책을 확인하세요.
DOMAIN-SUFFIX,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY대역에도 같은 원칙이 적용됩니다. 더 넓은 대역이 PROXY로 처리되더라도 그 안의 더 작은 IP-CIDR 범위는 DIRECT로 처리해야 한다면, 작은 범위를 먼저 배치하세요. 순서를 바꿀 때는 실제로 범위가 겹치는 규칙만 이동하고, 도메인 하나의 문제를 해결하기 위해 구성 전체의 순서를 크게 바꾸지 마세요. 테스트는 새로 시작한 요청으로 해야 합니다. 이미 연결된 세션으로는 방금 저장한 규칙 순서가 적용됐는지 정확히 판단하기 어렵습니다.
판단 순서: 먼저 처음 일치할 수 있는 규칙 확인
결과가 예상과 다르면 목록 위에서부터 대상에 적용될 수 있는 규칙을 찾아보세요. 정책을 바꾸기 전에 해당 규칙과 원하는 규칙의 상대적인 순서부터 바로잡습니다.
FINAL을 마지막에 두는 이유
FINAL,PROXY는 앞선 규칙에 하나도 일치하지 않은 요청을 PROXY로 처리합니다. FINAL은 마무리용이지 PROXY의 우선순위를 높이는 규칙이 아닙니다. 특정 도메인이나 대역을 지정하지 않으므로 확인해야 할 구체적인 규칙보다 앞에 두면 뒤에 있는 규칙은 일치할 기회를 잃습니다. 분류되지 않은 요청을 직접 연결하려면 구성 목표에 따라 FINAL,DIRECT를 사용할 수 있습니다. 두 방식 중 어느 쪽이 항상 더 낫다고 할 수는 없으며, 미분류 트래픽을 어디로 보낼지 명확히 정하는 것이 중요합니다.
- 특정 대상: 별도로 처리할 도메인이나 IP-CIDR을 먼저 나열하세요. 겹치는 범위가 명확할수록 순서를 확인하기 쉽습니다.
- 넓은 범위: 그다음 일반적인 도메인 접미사나 GEOIP 등의 조건을 배치하고, 예외 규칙보다 먼저 일치하지 않는지 확인하세요.
- 마지막 줄: FINAL로 나머지 요청을 처리하세요. 기본 처리 정책을 바꿨다면 전용 규칙이 없는 대상도 함께 다시 테스트합니다.
예를 들어 목록에 DOMAIN-SUFFIX,example.com,DIRECT와 FINAL,PROXY만 있다면, 해당 접미사에 일치하는 요청은 DIRECT로 연결되고 나머지 미일치 요청은 PROXY로 처리됩니다. 두 줄 사이에 GEOIP,CN,DIRECT를 추가하면, 이 조건에 해당하면서 도메인 규칙에 먼저 일치하지 않은 요청에 GEOIP 규칙이 적용됩니다. 이렇게 규칙별로 결과를 설명하는 편이 단순히 “중국 내 트래픽은 직접 연결, 그 외에는 프록시”라고 말하는 것보다 정확합니다. 목록 앞쪽에 다른 일치 조건이 있을 수도 있기 때문입니다.
규칙을 저장한 뒤 예상대로 적용되지 않을 때 확인할 순서
먼저 ‘규칙이 적용되지 않은 경우’와 ‘선택한 경로로 연결할 수 없는 경우’를 구분하세요. 전자는 Global Routing, 현재 구성 파일, 더 앞에 있는 규칙을 확인해야 합니다. 후자는 선택한 프록시 또는 직접 연결 경로를 사용할 수 있는지 확인해야 합니다. Shadowrocket은 규칙을 처리하지만, 규칙만으로 접속할 수 없는 대상에 연결할 수 있게 되지는 않습니다. 이미 자체 서비스 제공업체와 구독을 이용 중이라면 테스트 대상과 현재 사용하는 구성 및 연결 정보가 일치하는지도 확인하세요. 문제를 해결하기 위해 구독 출처를 바꿀 필요는 없습니다.
- Home으로 돌아가 Global Routing이 Config인지 확인하고, 편집 중인 파일과 실제 사용 중인 파일이 같은지 확인하세요.
- 목록 첫 번째 줄부터 아래로 내려가 대상에 적용될 수 있는 조건을 찾으세요. 범위가 넓은 DOMAIN-SUFFIX, IP-CIDR, FINAL이 원하는 규칙보다 앞에 있는지 특히 확인합니다.
- 요청에 사용된 실제 도메인이나 대상 IP를 확인하세요. 웹페이지는 여러 도메인에 동시에 요청할 수 있으므로, 테스트 페이지에 문제가 나타났다고 해서 페이지의 기본 도메인에 해당하는 규칙이 적용되지 않았다고 단정할 수는 없습니다.
- 수정 사항을 저장한 뒤 새 연결을 시작하고 앱 내 기록을 확인하세요. PROXY 규칙이 적용됐는데도 접속할 수 없다면 선택한 프록시와 대상에 각각 연결할 수 있는지 확인합니다.
REJECT를 설정했는데 요청이 여전히 PROXY로 처리되는 이유는 무엇인가요?
목록 위에서부터 대상 범위를 포함하는 DOMAIN-SUFFIX 또는 FINAL이 먼저 있는지 확인하세요. 구체적인 REJECT 규칙을 범위가 넓은 규칙보다 앞에 옮긴 다음 저장하고 새 요청으로 다시 테스트합니다.
FINAL을 수정했는데 특정 도메인의 연결 경로가 바뀌지 않는 이유는 무엇인가요?
FINAL은 앞선 규칙에 일치하지 않은 요청만 처리합니다. 해당 도메인이 FINAL보다 앞에서 처음 일치하는 규칙을 찾으세요. 연결 경로를 바꾸려면 그 규칙의 정책이나 위치를 확인해야 합니다.
GEOIP,CN,DIRECT를 설정했는데 일부 웹페이지가 여전히 PROXY로 연결되는 이유는 무엇인가요?
먼저 해당 연결의 대상과 앞에 있는 규칙을 확인하세요. GEOIP는 대상 IP 조건을 판단하며 웹페이지에서 사용하는 언어를 기준으로 삼지 않습니다. 요청이 도메인 규칙에 먼저 일치하면 GEOIP는 확인하지 않습니다.
Proxy로 전환한 뒤 방금 작성한 규칙을 어떻게 확인하나요?
먼저 Home의 Global Routing을 Config로 되돌리고 현재 구성 파일을 확인한 뒤 새 요청을 보내세요. Proxy 전역 모드에서의 접속 결과로 Config의 특정 규칙이 적용됐는지 판단할 수는 없습니다.
구독에서 가져온 규칙을 확인하는 경우, 먼저 로컬에서 편집한 위치와 구독 업데이트 후의 구성 내용을 파악하세요. 업데이트로 사용 중인 규칙 내용이 달라질 수 있으므로 다시 테스트하기 전에 대상 규칙이 남아 있는지, 순서가 올바른지 확인해야 합니다. PROXY 정책은 규칙 일치 여부와 프록시 연결 상태를 따로 확인하세요. 규칙에 일치했다는 것은 요청이 해당 경로로 지정됐다는 뜻일 뿐, 그 경로를 당시 사용할 수 있었다는 보장은 아닙니다.