Shadowrocket 사용자 규칙 설정: 위에서부터 매칭되는 순서, FINAL 기본 처리와 PROXY/DIRECT/REJECT 정책

이 글의 핵심

Shadowrocket에서 사용자 규칙이 적용되는지는 먼저 Global Routing, 현재 구성 파일, 규칙 순서를 확인해야 합니다. 자체 서버와 연결 구성을 이미 갖춘 사용자를 대상으로, 규칙 작성법과 기본 처리 정책, 확인 방법을 예약된 도메인 및 문서용 예시 IP 대역으로 설명합니다. 예시는 문법 이해를 위한 것이며 일상적인 구성에 그대로 적용할 수 있는 완성된 설정이 아닙니다.

규칙을 수정하기 전에 Global Routing부터 확인

규칙을 수정하기 전에 Home → Global Routing에서 현재 선택 항목을 확인하세요. 현재 구성 파일의 규칙에 따라 트래픽을 라우팅하려면 Config를 사용해야 합니다. Proxy나 Direct가 선택되어 있으면 현재 파일의 규칙을 하나씩 적용해 경로를 결정하는 방식이 아니므로, 규칙 순서를 계속 바꿔도 기대한 결과가 나오지 않을 수 있습니다.

Config

권장

현재 적용 중인 구성의 규칙에 따라 정책을 선택합니다. 직접 연결, 프록시 또는 거부 여부는 매칭된 규칙이 결정하며, 규칙에 매칭되지 않으면 직접 연결된다는 뜻은 아닙니다.

적합한 용도: 사용자 규칙 작성, 확인 및 일상적인 사용

Proxy

앱이 처리하는 연결에 전역 프록시 방식을 적용합니다. 프록시 연결이 가능한지 비교할 때 사용할 수 있지만, 이 상태의 결과만으로 특정 규칙이 매칭되었다고 판단할 수는 없습니다.

적합한 용도: 프록시 경로와 규칙 경로를 일시적으로 비교

Direct

앱이 처리하는 연결에 직접 연결 방식을 적용합니다. Direct는 시스템 VPN 구성을 끄는 것과 같은 뜻이 아니며, 현재 구성 파일을 삭제하는 것도 아닙니다.

적합한 용도: 현재 네트워크에서 대상에 직접 연결했을 때의 결과 비교

Global Routing에서 Scene을 사용할 수도 있습니다. Scene은 장면 선택과 관련되므로, 이 글의 예제를 확인할 때는 먼저 Config로 전환해 장면 변경과 규칙 변경을 혼동하지 않도록 하세요. 이름이 같은 두 항목도 구분해야 합니다. Global Routing의 Config는 실행 모드이고, 하단의 Config는 구성 파일을 관리하는 위치입니다. 파일이 목록에 있다고 해서 현재 사용 중인 파일이라는 뜻은 아닙니다.

규칙 문법: 조건 다음에 정책

구성 파일의 규칙은 [Rule] 섹션에 작성합니다. 일반적인 조건 규칙은 유형, 매칭 값, 정책으로 구성되며 각 항목은 영문 쉼표로 구분합니다. 쉼표를 잘못 입력하거나, 정책 이름에 공백을 넣거나, 규칙을 다른 섹션에 작성하면 파싱 또는 매칭 결과가 예상과 달라질 수 있습니다. 다음 네 가지 키워드를 구분하세요:

키워드	예시	확인할 내용
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,PROXY`	example.com 자체와 하위 도메인에 매칭됩니다. URL 경로는 입력하지 않습니다.
`IP-CIDR`	`IP-CIDR,192.0.2.0/24,DIRECT`	IPv4 대역에 매칭됩니다. /24는 앞의 24비트가 네트워크 접두부라는 뜻입니다.
`GEOIP`	`GEOIP,CN,DIRECT`	대상 IP의 지리 데이터베이스상 위치를 기준으로 판단하며, 도메인 문자열을 기준으로 하지 않습니다.
`FINAL`	`FINAL,PROXY`	매칭 값 항목 없이 사용하며, 앞선 조건에 모두 매칭되지 않은 트래픽을 처리합니다.

DOMAIN-SUFFIX,example.com,PROXY는 api.example.com에 매칭되지만, 다른 도메인 문자열의 끝에 “example.com”이 우연히 들어 있다고 해서 자동으로 매칭되지는 않습니다. 도메인 계층 경계를 확인하기 때문입니다. https://example.com/path를 입력하거나 매칭 값에 :443을 덧붙이지 마세요. 이 규칙은 도메인을 기준으로 매칭하며 웹페이지 경로나 포트는 기준으로 삼지 않습니다.

IP-CIDR와 GEOIP를 사용하려면 대상 IP 정보를 확인할 수 있어야 합니다. 도메인 연결에서 IP 조회가 실행되는지, IP를 언제 판단하는지는 구성 파일의 DNS 설정과 규칙 옵션에도 영향을 받습니다. GEOIP 결과를 웹사이트 운영자의 소재지로 해석하지 말고, 한 도메인이 항상 같은 IP 대역으로 해석될 것이라고 기대하지 마세요.

4개

이 글의 규칙 키워드: DOMAIN-SUFFIX / IP-CIDR / GEOIP / FINAL

3가지

이 글의 대상 정책: PROXY / DIRECT / REJECT

256개

192.0.2.0/24에 포함된 IPv4 주소 수

위에서부터 매칭: 구체적인 예외를 먼저 배치

규칙은 순서대로 하나씩 확인하며, 매칭되면 해당 규칙의 정책을 적용하고 더 적합한 규칙을 찾기 위해 아래로 계속 진행하지 않습니다. 시스템이 더 긴 도메인 접미사나 더 작은 IP 대역을 자동으로 위로 옮겨 주지도 않습니다. 따라서 구체적인 예외를 먼저 작성하고, 적용 범위가 넓은 조건을 그다음에 둔 뒤, 마지막에 기본 처리 규칙을 배치하세요.

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

이 예시에서는 api.example.com과 그 하위 도메인이 첫 번째 규칙에 먼저 매칭되어 직접 연결되고, www.example.com은 두 번째 규칙에 매칭됩니다. 앞의 두 규칙 순서를 바꾸면 api.example.com은 더 넓은 조건인 example.com에 먼저 해당되어 PROXY를 사용합니다. 아래쪽의 DIRECT 예외는 이번 판단에 적용되지 않습니다.

IP 대역도 같은 순서를 따릅니다

[Rule]
IP-CIDR,192.0.2.128/25,REJECT,no-resolve
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

192.0.2.128/25는 192.0.2.0/24에 포함됩니다. 대상 IP를 확인할 수 있는 연결의 경우 192.0.2.130은 먼저 REJECT에 매칭되지만, 192.0.2.20은 계속 아래로 내려가 DIRECT에 매칭됩니다. 두 규칙의 순서를 바꾸면 더 큰 /24가 전체 범위에 먼저 적용되어 원래의 거부 예외가 작동하지 않습니다.

PROXY, DIRECT, REJECT와 FINAL의 관계

앞의 세 키워드는 매칭된 연결을 어떻게 처리할지 나타내고, FINAL은 앞선 규칙에 하나도 매칭되지 않았을 때의 처리를 나타냅니다. 이들은 서로 같은 종류의 매칭 조건이 아닙니다. 특히 FINAL,PROXY에는 도메인이나 지역을 판단하는 조건이 없으므로 너무 앞에 두면 뒤에 있는 규칙을 가로막습니다.

PROXY: 프록시 경로로 처리합니다. 실제 연결 여부는 현재 선택한 프록시 또는 구성에서 참조하는 정책을 사용할 수 있는지에 달려 있습니다. PROXY를 작성한다고 연결 서비스가 자동으로 만들어지는 것은 아닙니다.
DIRECT: 선택한 프록시 서버를 거치지 않고 대상에 직접 연결합니다. 대상에 반드시 접속할 수 있다는 뜻은 아니며, 대상 서비스와 DNS, 로컬 네트워크 상태도 결과에 영향을 줍니다.
REJECT: 매칭된 연결을 거부합니다. 웹페이지에서 요청이 거부되면 리소스가 없거나 로드 오류가 발생한 것처럼 보일 수 있으며, 이것이 앱의 오류를 뜻하지는 않습니다.
FINAL: 규칙 끝에 배치해 앞선 규칙에 매칭되지 않은 트래픽을 처리합니다. 흔히 FINAL,PROXY 또는 FINAL,DIRECT로 작성하며, 선택은 명확한 라우팅 목적에 따라 달라집니다.

목록에 있는 도메인만 프록시를 사용하고 나머지는 직접 연결하려면 규칙을 모두 확인한 뒤 FINAL,DIRECT를 사용할 수 있습니다. 목록에 없는 대상도 프록시를 사용하게 하려면 FINAL,PROXY를 사용하세요. 요구 사항과 무관하게 정해진 하나의 답은 없습니다. FINAL을 바꾸면 앞선 규칙에 매칭되지 않은 모든 연결의 경로가 달라지므로, 도메인 규칙 하나를 추가하는 것보다 영향 범위가 큰 경우가 많습니다.

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

이 예시에서는 특정 하위 도메인을 먼저 거부하고, 나머지 example.com 도메인은 프록시로 보내며, 다른 대상은 직접 연결합니다. 세 가지 처리 결과를 조합하는 방법만 보여 주는 예시이며, 완전한 개인정보 보호나 네트워크 접속 설정은 아닙니다. 자신의 구성에 복사하기 전에 기존에 필요한 규칙을 유지하고 프록시 정책 참조가 현재 구성과 일치하는지 확인하세요.

수정 및 확인: 한 번에 변수 하나만 변경

현재 사용 중인 구성을 바로 덮어쓰지 마세요. 먼저 원본을 보존한 다음 복사본을 수정하세요. 원격 업데이트 파일이라면 이후 업데이트가 로컬 수정 사항을 덮어쓸 수 있다는 점도 고려해야 합니다. 다음 순서대로 진행하세요. 화면에 표시되는 파일 이름은 실제로 저장한 이름을 기준으로 합니다.

모드 확인
Home → Global Routing → Config를 열고 현재 선택된 프록시를 기록하세요. DNS, 프록시 선택, On Demand는 동시에 변경하지 마세요.
원본 파일 보존
하단의 Config로 이동해 현재 적용 중인 파일을 확인하세요. 수정 전에 파일 관리 기능을 이용해 복사본을 만들거나 백업을 내보내 복구할 수 있는 기준본을 보존하세요.
규칙 수정
Config에서 수정할 파일을 열고 편집 화면으로 이동한 다음 [Rule] 섹션을 찾으세요. 예외 규칙 하나를 추가하거나 규칙 두 개의 순서만 바꾸고, 마지막의 FINAL은 유지하세요. 저장한 뒤 수정한 파일이 실제로 사용 중인지 확인합니다.
요청 다시 보내기
Home으로 돌아가 연결 상태를 확인한 뒤 대상 앱의 기존 요청을 종료하고 새 연결을 시작하세요. 이미 연결된 장시간 요청은 텍스트를 수정했다고 자동으로 새 연결로 바뀌지 않습니다.
연결 기록 확인
Data에서 해당 시간대의 연결 기록을 확인하고 대상 도메인 또는 IP, 매칭된 규칙, 실제 정책을 함께 살펴보세요. 테스트 대상과 변경 전후 결과를 기록하고 웹페이지가 열리는지만 확인하지 마세요.

예를 들어 도메인 예외를 확인하려면 예외 하위 도메인 하나와 일반 하위 도메인 하나를 각각 점검하세요. FINAL을 확인할 때는 앞선 조건에 해당하지 않는 대상을 선택합니다. 자체 테스트 서비스를 사용한다면 HTTPS의 일반적인 포트는 443, HTTP는 80입니다. 이 글의 도메인 접미사 규칙은 이 두 포트를 기준으로 트래픽을 구분하지 않습니다.

접속할 수 없다는 사실만으로 규칙이 실패했다고 단정할 수는 없습니다. PROXY에 매칭됐지만 프록시 경로를 사용할 수 없거나, DIRECT에 매칭됐지만 로컬 네트워크에 연결할 수 없거나, REJECT에 매칭되어 요청이 거부되어도 비슷한 페이지 오류가 나타날 수 있습니다. ‘예상한 조건에 매칭되었는가 → 예상한 정책이 적용되었는가 → 해당 경로에 연결할 수 있는가’ 순서로 확인하세요. 페이지 결과만 보고 규칙을 추측하지 마세요.

자주 묻는 질문: 규칙을 작성했는데 왜 결과가 바뀌지 않나요?

규칙을 바꿨는데 왜 모든 대상이 여전히 프록시를 사용하나요?

먼저 Home → Global Routing에서 Proxy가 선택되어 있는지 확인한 다음 Config에서 현재 적용 중인 파일을 확인하세요. Config를 사용 중이라면 첫 번째 규칙부터 차례대로 확인해 범위가 너무 넓은 조건이 먼저 매칭되는지, 또는 FINAL이 예외 규칙보다 위에 있는지 살펴보세요.

DIRECT를 아래에 뒀는데 왜 앞의 PROXY를 덮어쓰지 않나요?

규칙은 나중에 작성한 항목이 앞선 항목을 덮어쓰는 방식이 아닙니다. 더 구체적인 DIRECT 조건을 해당 범위를 포함하는 PROXY 조건보다 위로 옮긴 뒤 저장하고 연결을 다시 시작하세요. 목록에 표시되는 이름만 바꾼 것이 아니라 실제 규칙 순서를 변경했는지도 확인합니다.

IP-CIDR를 추가했는데 도메인 접속에 매칭되지 않는 이유는 무엇인가요?

실제 대상 IP가 해당 대역에 포함되는지, no-resolve를 사용했는지 확인하세요. 도메인은 여러 주소를 반환하거나 IPv6를 사용할 수 있습니다. IPv4용 IP-CIDR 예시는 IPv6를 포함하지 않습니다. 도메인 기준으로 라우팅하려는 경우에는 명확한 도메인 조건을 우선 사용하세요.

업데이트 후 직접 추가한 규칙이 사라졌다면 어떻게 해야 하나요?

먼저 Config에서 업데이트된 항목이 원격 구성 파일인지 다른 항목인지 확인한 뒤 백업과 비교하세요. 구독의 서버 목록과 구성 파일의 규칙은 서로 다른 데이터입니다. 로컬에서 수정한 별도 복사본을 보존하고 복구한 뒤에는 현재 적용 중인 파일을 다시 확인해 원격 내용으로 덮어써질 파일을 반복해서 수정하지 않도록 하세요.

연결을 끈 뒤 왜 다시 자동으로 켜지나요?

Settings → On Demand에서 필요에 따라 연결하는 조건을 확인하세요. On Demand는 연결을 언제 설정할지 관리하며, [Rule]의 개별 규칙 매칭을 대신하지 않습니다. 먼저 연결 상태를 일정하게 유지한 다음 Global Routing과 규칙을 확인해 서로 다른 두 동작을 동시에 점검하지 않도록 하세요.

목적을 설명할 수 있는 최소한의 수정 사항만 남기세요. 예외를 먼저, 범위가 넓은 조건을 다음에, FINAL은 마지막에 둡니다. 확인할 때마다 현재 모드, 적용 파일, 대상, 매칭 정책을 기록하세요. 규칙이 많다고 정확도가 저절로 높아지는 것은 아닙니다. 각 규칙이 무엇을 다루고 왜 그 위치에 있는지 설명할 수 있어야 나중에 관리하기 쉽습니다. 화면과 연결 관련 용어는 용어 안내서에서 확인할 수 있습니다. 문제가 계속되면 문제 해결 항목을 순서대로 확인하세요.