Shadowrocket 사용자 규칙 설정 및 우선순위: 위에서 아래로 매칭, FINAL 기본 처리와 PROXY/DIRECT/REJECT

이 글의 핵심

Shadowrocket에서 직접 준비한 서비스를 가져온 뒤 Config 분할 라우팅을 조정하려는 사용자를 위한 안내입니다. 현재 Config와 Global Routing을 확인하고, 예시 도메인으로 규칙 순서와 정책 동작, FINAL의 역할을 살펴본 다음 요청 기록으로 매칭 결과를 확인합니다. 예시는 문법 설명용이며 연결 서비스를 제공하지 않습니다.

1. 규칙 적용 전 Config와 Global Routing 확인하기

사용자 규칙은 구성 파일의 [Rule] 섹션에 작성합니다. 편집을 시작하기 전에 하단의 Config 화면에서 현재 사용 중인 구성을 확인하세요. 다른 파일을 열어 내용을 확인하는 것만으로는 해당 구성이 적용되지 않습니다. 먼저 원본 구성을 보관하고 복사본을 편집하면 구문 오류나 의도치 않은 차단이 발생했을 때 복구하기 쉽습니다.

Home으로 돌아가 Global Routing을 확인합니다. 이 글의 규칙을 검증할 때는 Config를 사용합니다. Proxy와 Direct는 전역 라우팅 선택이므로 이 상태에서의 접속 결과만으로 사용자 규칙의 적용 여부를 판단할 수 없습니다. Scene을 사용 중이라면 실제 라우팅 선택을 확인하세요. 문제를 점검하는 동안에는 Config로 고정해 변수를 줄일 수 있습니다.

Config로 이동해 현재 사용 중인 구성의 이름을 기록하고 원본 내용을 저장합니다.
해당 구성의 [Rule] 섹션을 편집하되 다른 섹션의 제목과 필수 설정은 그대로 둡니다.
저장한 뒤 방금 편집한 구성이 계속 선택되어 있는지 확인합니다.
Home → Global Routing으로 이동해 Config를 선택한 다음 새 테스트 요청을 만듭니다.

2. 위에서 아래로 매칭: 위치가 ‘구체성’보다 우선

같은 구성의 규칙 목록은 위에서부터 차례로 확인합니다. 조건에 맞는 첫 번째 규칙의 정책을 적용하고, 뒤에 있는 ‘더 구체적인’ 규칙을 계속 찾지 않습니다. 따라서 정확한 도메인 규칙은 보통 넓은 접미사 규칙보다 앞에, 예외 규칙은 일반 규칙보다 앞에 두고 FINAL은 맨 마지막에 배치합니다.

요청 정보 첫 번째 규칙 순서대로 확인 첫 매칭 정책 적용

다음은 규칙 순서가 잘못된 예입니다. api.example.com에 접속하면 첫 번째 행의 DOMAIN-SUFFIX가 이미 매칭되어 PROXY가 적용됩니다. 뒤에 있는 DOMAIN 규칙은 범위가 더 좁다는 이유만으로 우선 적용되지 않습니다.

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

이 하위 도메인만 직접 연결하려면 앞의 두 행 순서를 바꾸세요. 여기서 example.com은 예시용으로 예약된 도메인입니다. 실제 대상에 맞게 규칙을 작성하고, 예시를 접속 테스트 서비스로 사용하지 마세요.

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

결론: 예외 규칙은 적용 범위가 넓은 규칙보다 앞에 배치

정책을 바꿨는데도 적용되지 않는다면 목록 끝에 같은 도메인을 추가하기보다 위쪽의 넓은 DOMAIN-SUFFIX, IP 대역 규칙 또는 먼저 나온 FINAL부터 확인하세요.

3. DOMAIN-SUFFIX, IP-CIDR, GEOIP의 매칭 대상

도메인 규칙과 IP 규칙은 확인하는 대상이 다릅니다. DOMAIN은 전체 도메인을, DOMAIN-SUFFIX는 도메인 접미사를 확인합니다. IP-CIDR은 대상 IPv4 주소가 지정된 대역에 포함되는지 확인하고, GEOIP는 IP 지리 데이터베이스를 기준으로 대상 주소의 지역을 판단합니다. GEOIP의 CN은 대상 IP의 지역 판정이며 기기의 위치나 선택한 서버의 위치를 뜻하지 않습니다.

키워드	구문 예시	매칭 의미
DOMAIN	`DOMAIN,api.example.com,DIRECT`	해당 전체 도메인만 매칭합니다.
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,PROXY`	example.com과 그 하위 도메인을 매칭하며 notexample.com은 매칭하지 않습니다.
IP-CIDR	`IP-CIDR,192.168.0.0/16,DIRECT,no-resolve`	지정한 IPv4 대역을 매칭합니다. 여기서는 사설 주소 범위를 예로 들었습니다.
GEOIP	`GEOIP,CN,DIRECT`	대상 IP의 지리 데이터베이스 판정에 따라 CN을 매칭합니다.
FINAL	`FINAL,PROXY`	앞선 규칙에 매칭되지 않은 요청을 처리합니다.

no-resolve는 이 IP 규칙의 매칭을 시도하기 위해서만 도메인 조회를 수행하지 말라는 뜻입니다. 전역 DNS를 끄는 설정이 아니며 앱이 도메인에 접속할 때 필요한 일반적인 조회도 차단하지 않습니다. 요청에 사용 가능한 대상 IP가 이미 있으면 주소 매칭에 적용될 수 있습니다. 따라서 모든 도메인 요청이 이 규칙을 건너뛰거나 매칭된다고 단정하지 마세요.

IP-CIDR의 /16은 접두사 길이이며 포트가 아닙니다. 예시 대역은 192.168.0.0부터 192.168.255.255까지이며 모든 사설 주소를 포함하지는 않습니다. 다른 로컬 네트워크 대역을 직접 연결하려면 실제 네트워크에 맞춰 각각 설정하세요. 도메인 규칙은 HTTPS의 443 포트와 HTTP의 80 포트를 구분하지 않습니다.

3가지

이 글에서 다루는 정책: PROXY / DIRECT / REJECT

/16

예시 사설 네트워크의 IPv4 접두사 길이

443

HTTPS에서 자주 쓰는 대상 포트이며 도메인 규칙 필드가 아닙니다.

4. PROXY, DIRECT, REJECT와 FINAL의 관계

PROXY, DIRECT, REJECT는 규칙이 매칭된 뒤 적용되는 정책입니다. PROXY는 현재 선택된 프록시로 요청을 전달합니다. 구성에서 사용자 지정 정책 그룹을 사용한다면 그룹 내 선택도 확인해야 합니다. DIRECT는 직접 연결 경로를 사용하며 시스템 VPN을 끄는 것은 아닙니다. REJECT는 요청을 거부하므로 명확히 차단할 대상에 사용하세요. 조회 실패를 해결하기 위한 방법으로 사용해서는 안 됩니다.

FINAL은 규칙 유형이지 네 번째 아웃바운드 방식이 아닙니다. 도메인이나 네트워크 대역 조건이 없으며, FINAL,정책 형식으로 작성합니다. 일반 규칙의 세 필드를 그대로 적용하면 안 됩니다. FINAL을 목록 앞부분에 두면 그 뒤의 일반 규칙은 매칭될 기회가 없습니다.

대상별 정책 지정

PROXY: 현재 선택된 프록시로 전달합니다. 사용할 수 있는 서비스가 설정되어 있어야 합니다.
DIRECT: 대상에 직접 연결합니다. 로컬 네트워크 상태의 영향을 받습니다.
REJECT: 요청을 거부합니다. 잘못 매칭되면 접속에 실패할 수 있습니다.

대상이 어떤 경로를 사용해야 하는지 먼저 정한 뒤 정책을 선택하세요.

목록 끝에 기본 규칙 배치

FINAL,PROXY: 앞선 규칙에 매칭되지 않은 요청을 프록시로 전달합니다.
FINAL,DIRECT: 앞선 규칙에 매칭되지 않은 요청을 직접 연결합니다.
배치 위치: 규칙 목록 맨 끝에 두고, 앞에는 필요한 예외와 일반 규칙을 배치합니다.

기본 경로는 예상되는 연결 방식에 따라 정하며 정답이 하나로 정해져 있지 않습니다.

‘목록에 지정한 도메인은 프록시로, 나머지는 직접 연결’하려면 도메인 규칙에 PROXY를 지정하고 마지막에 FINAL,DIRECT를 둡니다. ‘직접 연결을 명시한 대상은 직접 연결하고 나머지는 프록시로’ 처리하려면 반대로 구성합니다. 어느 쪽이든 필요한 로컬 접속 예외를 먼저 처리해야 합니다. 규칙 수만으로 적합한 구성을 판단하지 마세요.

5. 한 줄씩 결과를 추적할 수 있는 규칙 예시

다음 예시에는 정확한 예외, 차단 규칙, 도메인 접미사, 사설 네트워크 대역, 지역 판정, 기본 규칙이 모두 포함되어 있습니다. 규칙 순서를 보여 주기 위한 예시이며 완성된 구성은 아닙니다. 기존 구성의 [General] 등은 그대로 유지하세요. 사용 전 실제 대상에 맞게 조정하고 이 내용을 구성 파일 전체에 덮어쓰지 마세요.

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,telemetry.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: 첫 번째 행에 매칭되어 DIRECT가 적용되고 접미사 규칙은 더 이상 확인하지 않습니다.
telemetry.example.com: 두 번째 행에 매칭되어 REJECT가 적용됩니다. 문법을 보여 주기 위한 임의의 선택이며 해당 도메인의 용도에 대한 판단은 아닙니다.
www.example.com: 앞의 두 행에는 매칭되지 않고 세 번째 행에 매칭되어 PROXY가 적용됩니다.
대상 IP가 192.168.1.20인 경우: 먼저 매칭된 도메인 규칙이 없으면 네 번째 행에서 해당 사설 주소를 매칭할 수 있습니다.
그 밖의 대상: GEOIP에서 대상 주소가 CN으로 판정되면 DIRECT를 사용하고, 그렇지 않으면 FINAL로 이동해 PROXY를 사용합니다.

도메인 접미사 규칙을 GEOIP보다 앞에 두었으므로 example.com의 일반 하위 도메인은 먼저 PROXY로 처리되며 대상 IP의 지역에 따라 경로가 다시 결정되지 않습니다. 이는 순서에 담긴 의도입니다. 뒤에 있는 일반 지역 규칙보다 도메인 정책을 우선 적용합니다. 다른 의도를 표현하려면 순서를 다시 정하고 기존 예외에 영향이 없는지 확인하세요.

6. 새 요청과 매칭 기록으로 확인하기

웹페이지가 열렸다는 사실만으로는 이번 접속에 예상한 정책이 적용됐다고 단정할 수 없습니다. 웹페이지는 여러 도메인에 동시에 요청할 수도 있습니다. 기본 문서는 DIRECT에 매칭되더라도 정적 리소스는 PROXY나 REJECT에 매칭될 수 있습니다. 확인할 때는 요청 기록에서 실제 대상을 찾아 매칭된 규칙과 최종 정책을 확인하세요. Home의 연결 스위치만 보아서는 충분하지 않습니다.

환경 고정: 현재 Config, Global Routing, 선택한 프록시를 기록하고 테스트 중에는 네트워크와 정책을 동시에 바꾸지 마세요.
새 연결 시작: 구성을 저장한 다음 새 테스트 요청을 만드세요. 기존 장기 연결은 이전 경로를 계속 사용할 수 있으므로 새 규칙의 판단 기준으로 삼기 어렵습니다.
대상 확인: 실제 요청의 전체 도메인을 기준으로 확인하고 주소창에 표시된 기본 사이트 이름만 기록하지 마세요.
첫 매칭 규칙 확인: 결과가 예상과 다르면 목록 맨 위부터 먼저 매칭된 규칙을 찾으세요. 범위가 넓은 접미사 규칙과 앞쪽에 배치된 FINAL을 특히 확인합니다.
경로와 연결 가능성을 따로 점검: PROXY에 매칭된 뒤 연결되지 않으면 선택한 서비스와 조회를 확인하세요. DIRECT에 매칭된 뒤 연결되지 않으면 로컬 네트워크에서 대상에 접속할 수 있는지 확인합니다.
한 번에 한 항목만 변경: 규칙 하나의 위치나 정책만 조정하고 저장한 뒤 다시 확인하세요. 마지막으로 적용 결과를 기록합니다.

결론: 매칭이 올바른지 먼저 확인한 뒤 연결 실패를 점검

기록에서 대상이 예상한 규칙에 매칭된 것을 확인했다면 규칙 순서 변경을 잠시 멈추고 DNS, 대상 주소, 선택한 아웃바운드 경로를 점검하세요. 매칭 결과가 다를 때만 조건과 위치를 조정합니다.

원격으로 관리되는 구성에서 가져온 규칙이라면 업데이트 후 사용자 지정 행이 유지되었는지도 확인하세요. 서버 구독 업데이트와 구성 규칙 업데이트는 별개의 작업입니다. ‘서비스 목록이 새로고침됨’을 ‘현재 규칙이 교체됨’으로 해석하면 안 됩니다. 수정 전후의 내용과 테스트 대상을 보관해 두면 다음 업데이트 뒤에도 같은 기대 동작을 다시 확인할 수 있습니다.

7. 자주 발생하는 예외 상황: 규칙을 바꿔도 예상대로 동작하지 않는 경우

FINAL 뒤에 규칙을 추가했는데 왜 적용되지 않나요?

FINAL이 앞선 규칙에 매칭되지 않은 모든 요청을 처리하므로 그 뒤의 일반 규칙은 실행되지 않습니다. 사용자 규칙을 FINAL 앞으로 옮기고, 그 위에 대상과 매칭되는 규칙이 있는지도 확인하세요.

도메인에 DIRECT를 지정했는데 리소스는 왜 PROXY로 연결되나요?

먼저 해당 리소스가 다른 도메인에 요청을 보내는지 확인하세요. DOMAIN은 전체 도메인 하나만, DOMAIN-SUFFIX는 해당 접미사만 포함하며 페이지에서 참조하는 다른 사이트까지 자동으로 포함하지 않습니다. 실제 요청 기록에 따라 각각 판단하고 단일 리소스 문제를 해결하기 위해 범위를 지나치게 넓히지 마세요.

REJECT를 사용한 뒤 페이지가 비어 있으면 어떻게 복구하나요?

먼저 거부된 대상을 찾고 해당 규칙을 일시적으로 제거하거나 백업을 복원한 뒤 새 요청으로 다시 테스트하세요. 로그인, 인증 코드, 정적 리소스는 서로 다른 도메인을 사용할 수 있습니다. 차단 대상과 영향 범위를 확인한 다음에만 REJECT를 다시 사용하세요.

Shadowsocks, VMess 또는 다른 프로토콜로 바꾸면 규칙 우선순위도 달라지나요?

아웃바운드 프로토콜과 규칙 목록의 매칭 순서는 서로 다른 영역입니다. 프로토콜을 바꿔도 목록 뒤쪽의 DOMAIN 규칙이 앞쪽의 DOMAIN-SUFFIX 규칙보다 우선하지는 않습니다. 먼저 규칙이 어떤 정책을 선택하는지 확인한 다음 해당 정책에 연결된 서비스의 접속 조건을 점검하세요.