2026-10-15 · 규칙과 라우팅 · 약 12분

Shadowrocket 사용자 규칙 설정 방법: 규칙 매칭 순서와 FINAL, PROXY/DIRECT/REJECT

DOMAIN-SUFFIX, IP-CIDR, GEOIP 규칙의 매칭 순서와 FINAL을 마지막에 두는 이유, PROXY·DIRECT·REJECT의 용도를 설명합니다.

이 글의 핵심 내용

사용자 규칙은 요청에 적용할 연결 정책을 정합니다. Shadowrocket에 사용할 서비스를 이미 설정했고 라우팅 결과를 조정하려는 경우에 유용합니다. 먼저 Global Routing의 작동 방식을 확인하고, 규칙 문법과 예외 순서, FINAL의 위치를 살펴본 뒤 저장 및 검증 절차를 안내합니다. 기본 정책은 현재 Config 설정에 따르며, 예시를 모든 네트워크 환경에 그대로 적용할 수 있는 설정으로 간주하지 않습니다.

Global Routing: 규칙 적용 여부부터 확인하기

Global Routing은 Home에서 전체 라우팅 방식을 제어하는 설정이며, 개별 규칙의 정책과는 다릅니다. Shadowrocket의 사용자 규칙은 주로 Config 모드에서 라우팅에 적용됩니다. 편집하기 전에 Home → Global Routing에서 현재 선택된 항목을 확인하고, Config에서 사용 중인 구성 파일을 확인하세요. 기본 선택 항목은 앱에 현재 표시되는 값을 기준으로 하며, 이 글의 규칙 검증은 Config 모드에서 진행합니다.

Config

권장

현재 구성의 규칙에 따라 요청의 경로를 결정합니다. Config를 선택해도 모든 요청이 PROXY를 사용하는 것은 아닙니다. 실제 적용 결과는 일치하는 규칙에 따라 달라집니다.

적합한 용도: 사용자 규칙 작성, 도메인 예외 및 최종 정책 검증

Proxy

전체 라우팅을 프록시 모드로 설정합니다. 이 모드에서는 이 글에서 다루는 일반 규칙 목록에 따라 요청을 하나씩 분기하지 않습니다. 같은 대상에 프록시로 접속한 결과를 비교할 때 임시로 사용할 수 있지만, 테스트 후에는 기존 설정으로 되돌리세요.

적합한 용도: 규칙의 영향을 배제하고 기존 프록시 연결이 작동하는지 확인

Direct

전체 라우팅을 직접 연결 모드로 설정합니다. 이 상태에서는 일반 라우팅 규칙을 변경해도 규칙이 올바르게 적용되는지 판단할 수 없습니다.

적합한 용도: 현재 네트워크에서 대상에 직접 접속할 수 있는지 확인

Scene

설정된 Scene에 따라 라우팅 방식을 선택합니다. 문제를 확인할 때는 Scene 조건과 해당 동작을 함께 점검해야 합니다. 특정 구성의 규칙 문구만 확인해서는 안 됩니다.

적합한 용도: Scene 조건을 설정해 두었으며 환경에 따라 방식을 전환하려는 경우

On Demand는 연결을 시작하는 조건이며 DOMAIN-SUFFIX 등의 규칙을 대신하지 않습니다. 연결을 끊은 뒤 자동으로 다시 연결된다면 Settings → On Demand의 현재 조건을 별도로 확인하세요. 연결은 유지되지만 요청이 예상과 다른 경로로 간다면 Global Routing, 현재 Config, 일치한 규칙을 먼저 살펴보세요. 두 문제는 구분해서 해결해야 합니다.

규칙 문법: 매칭 조건과 처리 정책 구분하기

규칙 한 줄은 규칙 유형, 매칭 값, 정책으로 구성되며 일반적인 형식은 유형,매칭 값,정책입니다. FINAL에는 매칭 값이 없으며 최종 정책만 지정합니다. 일반 텍스트로 편집할 때는 영문 반각 쉼표를 사용하고, URL의 프로토콜 접두사·경로·쿼리 매개변수는 도메인 매칭 값에 넣지 마세요. 아래 내용은 구성 파일의 [Rule] 섹션에 해당하며 Home의 서버 주소 입력란에 넣는 것이 아닙니다.

3가지
이 글에서 다루는 매칭 조건: DOMAIN-SUFFIX / IP-CIDR / GEOIP
3가지
이 글에서 다루는 기본 정책: PROXY / DIRECT / REJECT
1개
예시에는 FINAL을 하나만 두고 규칙 맨 마지막에 배치합니다.
키워드예시 형식매칭 내용
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.com,PROXYexample.com 자체와 하위 도메인에 매칭되며 notexample.com에는 매칭되지 않습니다.
IP-CIDRIP-CIDR,192.168.1.0/24,DIRECT,no-resolve지정한 IPv4 네트워크 대역에 매칭됩니다. no-resolve는 이 규칙만을 위해 도메인을 별도로 조회하지 않도록 합니다.
GEOIPGEOIP,CN,DIRECTIP 지리 데이터베이스를 기준으로 주소의 지역을 판단합니다. 웹페이지 언어나 도메인 접미사로 판단하지 않습니다.
FINALFINAL,PROXY앞선 규칙에 매칭되지 않은 요청에 지정한 정책을 적용합니다.

IP-CIDR의 /24는 네트워크 프리픽스 길이입니다. 위 예시는 192.168.1.0부터 192.168.1.255까지 포함합니다. IPv4 주소 하나만 지정하려면 /32를 사용할 수 있습니다. 이 숫자는 서버 포트가 아닙니다. 도메인 규칙에도 example.com:443처럼 포트를 붙이지 마세요. 포트별로 요청을 구분하는 것은 별도의 매칭 조건이며 DOMAIN-SUFFIX의 값을 바꾸는 방식으로 구현할 수 없습니다.

매칭 순서: 구체적인 예외를 먼저, 넓은 조건은 나중에

규칙 순서는 위에서부터 차례로 확인하는 우선순위이며, 시스템이 자동으로 ‘가장 정확한 규칙’을 선택하는 방식이 아닙니다. 일반적인 규칙 라우팅에서는 요청이 앞쪽의 유효한 규칙에 매칭되면 해당 정책이 적용되고, 뒤에 있는 일반 규칙으로 덮어쓰지 않습니다. 따라서 구체적인 도메인 예외를 넓은 도메인 범위보다 앞에 두고, 네트워크 대역 및 지역 규칙은 적절한 위치에 배치하며, FINAL은 맨 끝에 두세요.

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.1.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

아래는 규칙 순서를 이해하기 위한 예시입니다. api.example.com은 첫 번째 규칙에 매칭되어 DIRECT를 사용하고, www.example.com은 두 번째 규칙에 매칭되어 PROXY를 사용합니다. 192.168.1.20에 직접 접속하면 네트워크 대역 규칙이 적용됩니다. 그 밖의 요청이 GEOIP에 매칭되는지는 대상 주소와 데이터베이스 결과에 따라 달라집니다. 앞선 규칙 어디에도 매칭되지 않아야 FINAL이 적용됩니다. example.com은 설명용 도메인이며 실제로 이용할 수 있는 서비스를 뜻하지 않습니다.

PROXY, DIRECT, REJECT: 대상에 맞는 정책 선택하기

정책은 규칙 매칭 후 수행할 동작을 지정하며, 매칭 범위를 나타내지는 않습니다. PROXY는 요청을 프록시 경로로 보내고, DIRECT는 현재 네트워크를 통해 직접 연결하며, REJECT는 요청을 거부합니다. 기본 최종 정책은 현재 Config 설정에 따릅니다. 먼저 분류되지 않은 트래픽이 어디로 가야 하는지 정한 다음 FINAL을 선택하세요. 검증 없이 모든 설정을 일괄 변경하지 마세요.

정책적용 조건확인할 사항
PROXY해당 대상에 사용자가 이미 보유한 프록시 서비스를 통해 접속해야 하는 경우현재 선택한 서비스 또는 정책 그룹과 연결 상태를 확인하세요. 규칙에 매칭되었다고 원격 연결까지 성공한 것은 아닙니다.
DIRECT로컬 네트워크 기기 또는 현재 네트워크에서 직접 접속할 수 있음을 확인한 대상로컬 라우팅, 네트워크 권한, 대상 서비스 자체를 확인하세요. DIRECT 연결에도 정상적인 DNS와 네트워크 연결이 필요합니다.
REJECT연결을 명확히 차단하려는 대상이며 거부로 인한 영향을 확인한 경우먼저 정확한 DOMAIN 범위로 테스트해 로그인, 결제 또는 페이지 작동에 필요한 공용 도메인까지 잘못 차단하지 않도록 하세요.

FINAL,PROXY는 분류되지 않은 요청도 프록시로 보내므로 이 동작을 유지하려는 구성에 적합합니다. FINAL,DIRECT는 분류되지 않은 요청을 직접 연결하므로 프록시로 보낼 대상을 충분히 지정한 구성에 적합합니다. 사용 목적을 고려하지 않고 어느 한쪽이 항상 더 낫다고 할 수는 없습니다. FINAL을 REJECT로 설정하면 목록에 없는 모든 요청이 거부되어 새 도메인도 바로 접속할 수 없게 될 수 있습니다. 따라서 처음 규칙을 작성할 때 기본 선택으로 삼는 것은 권장하지 않습니다.

DOMAIN,blocked.example.com,REJECT
DOMAIN,printer.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

위 예시는 같은 도메인 범위에 적용되는 정책 예외를 보여 주며, 그대로 복사해 사용할 수 있는 연결 설정이 아닙니다. PROXY의 실제 출구는 현재 선택한 서비스와 구성에서 참조하는 정책 이름을 함께 확인해야 합니다. 사용자 지정 정책 그룹을 참조하는 규칙은 이름이 구성에 정의된 값과 일치해야 합니다. Global Routing의 Proxy 모드와 규칙 행의 PROXY는 서로 다른 단계의 설정입니다.

저장 및 검증: 한 번에 한 항목씩 변경하기

검증은 ‘편집한 내용’, ‘현재 활성화된 파일’, ‘실제 요청 결과’를 서로 대조하는 과정입니다. 시작하기 전에 Config에서 원본 파일을 복사해 두고 기존 Global Routing 선택 항목을 기록하세요. 이 글은 사용자가 이미 자신의 서비스와 구독을 보유한 상태에서 라우팅 규칙만 조정하는 경우를 전제로 합니다. Home의 Subscribe 업데이트와 Config 파일 업데이트는 서로 다른 작업입니다. 서버 구독을 새로고침했다고 해서 현재 사용 중인 규칙까지 교체되는 것은 아닙니다.

  1. 모드 확인

    Home → Global Routing → Config로 이동합니다. Home에서 현재 선택된 서비스도 기록해 두세요. 규칙 변경과 서비스 전환을 동시에 하면 결과를 비교하기 어려워집니다.

  2. 파일 찾기

    Config로 이동해 현재 선택된 구성을 확인합니다. 해당 파일의 편집 화면을 열고 Rule 목록 또는 일반 텍스트에서 [Rule] 섹션을 확인하세요. 편집 화면마다 항목 이름이 다를 수 있으므로 현재 앱에 표시되는 문구를 기준으로 합니다.

  3. 예외 추가

    범위가 넓은 규칙과 FINAL 앞에 대상이 명확한 규칙을 추가합니다. 일반 텍스트로 편집한다면 기존 [Rule] 섹션만 수정하고, 예시를 붙여 넣어 규칙 섹션이 중복으로 생기지 않도록 하세요.

  4. 저장 및 적용

    저장한 뒤 Config로 돌아가 수정한 파일이 계속 선택되어 있는지 확인한 다음 Home으로 돌아갑니다. 필요한 경우 연결을 끊었다가 다시 연결하고 새 요청으로 검증하세요. 기존 장시간 연결은 변경 내용이 즉시 적용되었는지 확인하기에 적합하지 않습니다.

  5. 기록 확인

    대상에 다시 접속한 뒤 앱의 요청 기록에서 도메인 또는 IP, 적용된 정책, 확인 가능한 규칙 정보를 확인합니다. 추가 진단 정보는 Settings → Log에서 확인할 수 있습니다. 기록에 표시되는 항목은 현재 인터페이스를 기준으로 합니다.

검증 기록에는 최소한 대상, 기대 정책, 실제 정책이 포함되어야 합니다. 예를 들어 테스트 대상에 대해 ‘정확한 도메인 규칙에서 기대한 정책은 DIRECT이고 기록에도 DIRECT로 표시됨’이라고 남길 수 있습니다. 결과가 PROXY라면 DNS를 바로 바꾸지 말고 먼저 현재 파일과 앞쪽의 넓은 범위 규칙을 확인하세요. 이 글의 예시는 동작을 설명하기 위한 것이며 실제 네트워크에서 테스트한 결과가 아니고, 바로 접속해 볼 수 있는 테스트 서비스도 제공하지 않습니다.

DNS 및 주소 규칙: 주소 변환 문제와 규칙 순서 문제 구분하기

DNS는 도메인을 주소로 변환하며 IP-CIDR과 GEOIP는 판단에 필요한 주소 정보를 사용합니다. DOMAIN-SUFFIX는 주로 도메인에 매칭되고, IP-CIDR은 주소 범위를 기준으로 판단합니다. 요청에 도메인이 포함되는지, 주소가 이미 조회되었는지, 구성의 DNS 옵션과 캐시 상태가 어떤지에 따라 문제를 확인할 때 표시되는 정보가 달라집니다. 따라서 웹페이지가 열리는지만으로 어떤 규칙에 매칭됐는지 판단할 수는 없습니다.

문제 확인은 먼저 모드와 파일을 점검하고, 다음으로 매칭된 규칙을 확인한 뒤, 마지막으로 주소 조회 결과와 서비스 연결 상태를 살펴보는 순서가 좋습니다. 기록에 기대한 정책이 표시되는데도 대상에 접속할 수 없다면 DNS, 원격 서비스, TLS 또는 현재 네트워크 경로가 원인일 수 있습니다. 이 경우 FINAL 위치를 계속 바꾸는 것만으로는 연결 문제를 해결하기 어렵습니다.

자주 묻는 질문: 규칙 미적용 및 업데이트 덮어쓰기

규칙을 추가했는데 왜 모든 요청이 여전히 프록시로 연결되나요?

먼저 Home → Global Routing에서 Proxy가 아닌 Config가 선택되어 있는지 확인한 뒤 Config에서 해당 파일이 선택되어 있는지도 확인하세요. 두 항목이 모두 맞다면 대상이 앞쪽의 DOMAIN-SUFFIX 또는 다른 넓은 범위 규칙에 먼저 매칭되는지 살펴보세요. 명확한 예외를 앞에 추가하고 저장한 뒤 새 요청을 보내세요.

FINAL 뒤에 있는 규칙도 적용되나요?

이 글에서 다루는 일반 규칙 목록에서는 FINAL 뒤의 규칙이 적용될 것이라고 기대하지 마세요. 모든 매칭 조건을 FINAL 앞으로 옮기고, 최종 정책은 명확한 규칙 하나만 남기세요. FINAL이 중복되었는지 확인할 때는 파일의 마지막 몇 줄만 보지 말고 규칙 섹션 전체를 검색해야 합니다.

구독을 업데이트한 뒤 사용자 규칙이 사라지는 이유는 무엇인가요?

먼저 업데이트 대상이 무엇인지 구분하세요. Home의 Subscribe는 일반적으로 서버 정보를 갱신하고, 원격 Config 업데이트는 구성 내용을 교체할 수 있습니다. Config에서 현재 파일이 업데이트되었거나 다른 파일로 전환되었는지 확인하세요. 로컬 변경 내용을 보존하려면 먼저 별도 사본을 저장하고, 업데이트할 때마다 규칙 섹션을 비교하세요.

웹사이트 홈은 열리는데 로그인은 실패합니다. FINAL을 바꿔야 하나요?

로그인할 때 새로 나타나는 도메인과 실제 적용된 정책부터 확인하세요. 로그인 과정에서 별도 도메인을 사용하거나 REJECT가 적용되거나 다른 출구로 연결될 수 있습니다. 관련성이 확인된 도메인에만 필요한 예외를 추가하고 넓은 범위 규칙보다 앞에 두세요. 전체 규칙을 한꺼번에 DIRECT 또는 PROXY로 바꾸지 마세요.

규칙 관리는 결과를 설명할 수 있고 변경을 되돌릴 수 있어야 완료된 것입니다. 각 예외는 명확한 대상에 대응하고, 매번 검증할 때 어떤 규칙에 매칭됐는지 확인할 수 있어야 하며, FINAL의 처리 방향도 예상과 일치해야 합니다. 결과를 설명하기 어렵다면 백업을 복원하고 규칙을 한 줄씩 추가하세요. 출처가 다른 구성 조각을 여러 개 한꺼번에 덧붙이지 마세요. 더 많은 화면 경로는 옵션 매뉴얼에서 확인할 수 있습니다.

App Store 정품 확인 →