Shadowrocket 사용자 규칙 설정: 규칙 우선순위와 FINAL 기본 처리, PROXY/DIRECT/REJECT 정책

01 Config 모드를 확인한 뒤 규칙 수정하기

Shadowrocket의 규칙은 실행 모드와 별개로 작동하는 스위치가 아닙니다. Home에서 Global Routing을 확인하세요. Config 파일의 트래픽 분배 규칙을 확인하려면 Config를 사용해야 합니다. Proxy와 Direct는 각각 전체 트래픽을 프록시로 보내거나 직접 연결하는 라우팅 방식이므로, 두 모드에서의 접속 결과만으로 사용자 규칙이 예상대로 적용됐는지 판단할 수 없습니다. Scene을 사용 중이라면 먼저 해당 Scene의 실제 라우팅 설정을 확인한 다음 규칙을 테스트하세요.

Home에서는 연결 상태와 서버 선택을 확인하고, Config에서는 구성 파일을 관리하며, Settings에서는 앱 설정을 확인합니다. 먼저 Config에서 현재 활성화된 파일을 확인한 다음 해당 파일의 편집 화면으로 이동하세요. 같은 이름의 사본만 수정하고 다른 구성 파일을 계속 사용하지 않도록 주의하세요.

1. 현재 구성 파일을 복사해 보관하고, 기존 Global Routing 설정과 서버 선택을 기록합니다.
2. Config에서 수정할 구성을 열고 [Rule] 섹션을 찾습니다.
3. 전체 규칙을 한꺼번에 바꾸지 말고, 먼저 구분하기 쉬운 테스트 규칙 하나를 추가합니다.
4. 저장한 뒤 수정된 구성이 사용 중인지 확인하고, Home으로 돌아가 Global Routing을 Config로 설정합니다.
5. 연결을 유지한 상태에서 새 요청을 보내세요. 이미 연결된 세션은 방금 수정한 라우팅을 확인하는 데 적합하지 않습니다.

02 규칙은 위에서 아래로 적용되며, 예외를 먼저 배치해야 합니다

규칙은 일반적으로 매칭 유형, 매칭 값, 정책으로 구성되며, 각 필드는 영문 쉼표로 구분합니다. 예를 들어 DOMAIN-SUFFIX,example.com,PROXY는 일치하는 도메인을 PROXY로 처리합니다. 구성에 적힌 순서대로 규칙을 확인하며, 처음 일치하는 규칙의 정책을 적용한 뒤에는 뒤에 있는 더 구체적인 규칙을 계속 찾지 않습니다.

따라서 ‘구체적인 규칙을 먼저 둔다’는 것은 규칙 배열 방식에 대한 권장 사항이지, 자동 정렬 기능이 아닙니다. status.example.com은 직접 연결하고 같은 도메인의 다른 요청은 프록시로 보내려면, 구체적인 DOMAIN 규칙을 DOMAIN-SUFFIX보다 앞에 배치해야 합니다.

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

• status.example.com은 첫 번째 규칙에 일치하므로 DIRECT가 적용됩니다.
• www.example.com은 첫 번째 규칙에 일치하지 않고 두 번째 규칙에 일치하므로 PROXY가 적용됩니다.
• example.com 자체도 두 번째 규칙에 일치합니다.
• 앞의 두 규칙에 일치하지 않는 요청은 마지막 FINAL이 처리합니다.

앞의 두 규칙 순서를 바꾸면 status.example.com이 먼저 DOMAIN-SUFFIX에 일치하므로 뒤에 있는 DOMAIN 규칙은 실행되지 않습니다. 예시 도메인은 문법 설명용이므로, 해당 주소에서 웹페이지가 열리는지로 프록시 서비스의 작동 여부를 판단할 수 없습니다.

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

도메인 규칙과 IP 규칙은 서로 다른 대상을 처리합니다. DOMAIN-SUFFIX는 도메인 접미사를 기준으로 매칭하며, 문자열이 포함되기만 하면 일치하는 방식이 아닙니다. example.com과 img.example.com은 조건에 맞지만 notexample.com은 일치하지 않습니다. 완전한 호스트 이름 하나만 매칭하려면 DOMAIN을 사용하세요.

192.0.2.0/24는 문서 예시용 주소 범위로, 192.0.2.0부터 192.0.2.255까지 포함합니다. 실제로 사용할 수 있는 서버 주소가 아닙니다. no-resolve는 이 IP 규칙을 적용하기 위해 도메인 조회를 새로 시작하지 않는다는 뜻입니다. 매칭 가능한 대상 IP가 이미 있으면 판단에 사용할 수 있습니다. 모든 DNS를 끄는 설정으로 이해하거나, 사용할 수 있는 IP 없이 도메인만 있는 경우에도 강제로 일치한다고 기대하지 마세요.

GEOIP는 대상 IP와 IP 위치 데이터에 따라 작동하므로, 특정 언어로 된 웹사이트나 특정 지역의 도메인 접미사에 항상 같은 정책을 적용한다고 보장할 수 없습니다. 인프라를 공유하는 웹사이트는 서로 다른 IP 주소로 확인될 수 있습니다. 특정 도메인의 라우팅을 고정하려면 당시 확인된 지역에 의존하기보다 도메인 규칙을 명시하세요.

04 PROXY, DIRECT, REJECT와 FINAL의 역할

PROXY, DIRECT, REJECT는 규칙이 실행될 때 적용되는 정책이고, FINAL은 규칙 유형입니다. 서로 같은 수준의 항목이 아닙니다. FINAL,PROXY는 ‘앞선 규칙에 일치하지 않으면 PROXY를 적용한다’는 뜻이며, FINAL 자체에 프록시 기능이 있는 것은 아닙니다.

• PROXY: 요청을 프록시 정책으로 처리합니다. 기본 구성에서는 Home에서 선택한 서버를 확인해야 합니다. 정책 그룹을 사용하는 구성이라면 그룹에서 실제로 선택된 항목도 확인하세요. PROXY만 적는다고 서버가 추가되는 것은 아닙니다.
• DIRECT: 프록시 서버를 거치지 않고 대상에 직접 연결합니다. 연결은 여전히 앱의 터널과 규칙 처리를 거칠 수 있으므로 DIRECT를 연결 스위치를 끄는 설정으로 생각하면 안 됩니다.
• REJECT: 일치하는 요청을 차단합니다. 명확하게 차단해야 하는 대상에 사용하며, 연결 실패를 해결하기 위한 범용 설정으로 사용해서는 안 됩니다.

두 예시는 라우팅 목표가 서로 다르므로 두 카드를 합쳐 복사하면 안 됩니다. FINAL에 적용할 정책을 선택하기 전에 ‘규칙에 명시되지 않은 요청을 어떻게 처리할 것인가’를 먼저 정하세요. FINAL을 규칙 섹션 앞부분에 두면 뒤에 있는 예외 규칙이 정상적으로 매칭되지 않습니다. 마지막에 명확한 기본 처리 규칙을 하나 두면 점검하기 쉽습니다.

05 전체 예시: 정확한 도메인부터 마지막 기본 처리까지

아래 구성 예시는 규칙 순서를 익히기 위한 것으로 [Rule] 섹션만 보여 줍니다. 서버 정의는 포함하지 않으며, 기존 구성의 다른 섹션을 덮어쓰는 데 사용해서는 안 됩니다. 예시 도메인과 주소는 문서 설명용이므로 실제 사용 시에는 매칭 대상을 확인한 뒤 입력하세요.

[Rule]
DOMAIN,status.example.com,DIRECT
DOMAIN-SUFFIX,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

1. 먼저 status.example.com인지 확인하고, 일치하면 직접 연결합니다.
2. 그다음 blocked.example.com 또는 그 하위 도메인인지 확인하고, 일치하면 차단합니다.
3. 이어서 나머지 example.com 도메인 요청을 프록시로 처리합니다.
4. 앞선 규칙에 일치하지 않았고 사용할 수 있는 대상 IP가 있는 요청은 예시 주소 범위와 비교합니다.
5. 나머지 요청은 마지막 PROXY 기본 규칙으로 처리합니다.

두 번째 규칙은 세 번째 규칙보다 앞에 있어야 합니다. blocked.example.com은 두 접미사 규칙 모두에 해당하기 때문입니다. IP-CIDR의 범위가 다르더라도 앞에서 이미 일치한 도메인 정책을 뒤집을 수는 없습니다. 규칙을 배열할 때는 같은 키워드끼리 모으기보다 ‘명확한 예외를 먼저, 포괄적인 범위를 나중에’ 처리하는 순서로 살펴보세요.

06 규칙 검증: 매칭 결과와 연결 결과를 따로 기록하기

웹페이지가 열리는지만으로 규칙 매칭 여부를 판단할 수는 없습니다. PROXY에 일치해도 서버에 연결할 수 없어 실패할 수 있고, DIRECT에 일치해도 현재 네트워크의 제한으로 접속이 안 될 수 있습니다. REJECT에 일치해 접속이 실패한 것은 의도한 결과일 수 있습니다. 문제를 확인할 때는 ‘어떤 정책이 적용됐는지’와 ‘정책 적용 후 어떤 결과가 발생했는지’를 따로 기록하세요.

1. 대상 준비: 직접 확인할 수 있는 실제 전체 도메인 이름을 하나 선택하고, 수정 전 접속 상태를 기록합니다. 예시 주소는 작동 여부를 테스트하는 데 사용하지 마세요.
2. 환경 고정: 같은 네트워크, 같은 서버, 같은 Config를 사용하고 Global Routing이 Config인지 확인합니다.
3. 새 요청: 규칙을 저장한 뒤 기존 페이지나 연결을 닫고 다시 접속해 연결 재사용이 관찰에 영향을 주지 않도록 합니다.
4. 기록 확인: 앱의 요청 기록에서 실제 도메인, 대상 IP, 규칙, 정책 등 표시되는 정보를 확인합니다. 기록 항목의 이름과 표시 내용은 현재 앱 화면을 기준으로 확인하세요.
5. 항목별 조정: 잘못된 규칙에 일치했다면 규칙 순서를 조정하세요. 올바른 규칙에 일치했는데도 연결이 실패한다면 DNS, 프록시 서버 또는 직접 연결 경로를 확인합니다.

한 페이지에서 여러 도메인에 요청을 보낼 수 있습니다. 기본 문서, 이미지, API, 미디어 리소스가 각각 다른 규칙에 일치할 수 있습니다. 주 도메인에 규칙 하나를 추가해도 관련 리소스 모두에 같은 정책이 적용되는 것은 아닙니다. 실패한 요청의 실제 호스트 이름부터 확인하고, 브라우저 주소 표시줄의 도메인만 보고 규칙 범위를 넓히지 마세요.

07 사용자 규칙 관련 자주 묻는 질문