Shadowrocket
규칙 및 설정 참고

02 / 일반 설정

General, Global Routing 및 DNS

라우팅 모드에 따라 규칙 참여 여부가 달라집니다

Global Routing은 규칙을 살펴보기 전에 먼저 확인해야 할 항목입니다. Config는 현재 설정 파일에 따라 정책을 선택하고, Proxy는 클라이언트가 처리하는 요청에 현재 선택된 프록시를 사용하며, Direct는 직접 연결하는 방향으로 처리합니다. 서로 다른 처리 모드이지, 같은 규칙 파일의 우선순위 세 단계가 아닙니다. Proxy에서는 요청이 연결되지만 Config에서 실패한다면 서버가 작동하지 않는다고 단정하지 말고 실제로 매칭된 규칙을 살펴보세요. 반대로 Direct에서 접속된다고 해서 프록시 경로도 사용할 수 있다는 뜻은 아닙니다.

여기서 ‘클라이언트가 처리하는 요청’이라는 표현은 중요한 경계를 나타냅니다. 앱 외부의 시스템 동작, 기존 연결, 설정에 포함된 특수 처리 조건이 실제로 관찰되는 요청에 영향을 줄 수 있습니다. 모드를 전환한 뒤에는 같은 대상과 같은 요청 방식으로 다시 테스트하세요. 웹페이지 접근과 앱의 백그라운드 연결을 서로 비교해서는 안 됩니다. 전환 방법을 단계별로 알아보려면 Global Routing의 Config, Proxy, Direct 설명을 읽은 다음, 이 페이지의 규칙 섹션에서 매칭 결과를 확인하세요.

General은 일반 조건을 지정하는 섹션이지 규칙 우선순위 스위치가 아닙니다

General에서 자주 사용하는 필드는 key = value 형식입니다. 사용할 수 있는 옵션은 앱 내 설정 편집기와 설명을 기준으로 확인하세요. 다른 문법 체계에서 쓰이는 동명의 필드를 그대로 옮기지 말고, 이름이 비슷하다는 이유만으로 의미도 같다고 판단하지 마세요. 아래는 최소한의 DNS 예시입니다. system은 시스템에서 제공하는 DNS 설정을 사용한다는 뜻이지, 특정 DNS 서버 주소를 고정으로 입력한다는 뜻이 아닙니다. DNS를 수정하기 전에 문제가 이름 해석 단계에서 발생하는지 연결 단계에서 발생하는지 확인하세요.

[General]
dns-server = system

[Rule]
DOMAIN,api.example.org,DIRECT
FINAL,PROXY

DNS는 이름을 주소로 변환하고, 정책은 요청을 어떤 경로로 처리할지 정합니다. 서로 연동되지만 같은 개념은 아닙니다. 도메인이 DIRECT 규칙에 매칭되더라도 DNS 조회에 실패할 수 있고, 주소를 정상적으로 얻었더라도 프록시 인증, 대상 포트 또는 원격 연결 문제로 실패할 수 있습니다. 문제를 확인할 때는 먼저 도메인과 해석 결과를 살펴보고, 이어서 매칭 규칙과 연결 오류를 확인하세요. DNS를 바꾼 뒤 잠시 정상화되었다는 이유만으로 기존 규칙이 모두 올바르다고 결론 내릴 수는 없습니다.

주소 규칙은 DNS 조회에 의존할 수 있습니다

도메인으로 요청했지만 뒤에 오는 규칙에서 대상 IP 또는 GEOIP를 확인해야 한다면, 매칭 과정에서 먼저 주소를 조회해야 할 수 있습니다. 이 조회는 처리 시간뿐 아니라 로그에 대상 요청과 관련된 DNS 기록이 나타나는지에도 영향을 줍니다. 도메인 규칙보다 주소 규칙을 많이 앞에 두면, 도메인으로 바로 결정할 수 있는 요청도 추가 주소 판정을 거칠 수 있습니다. 일반적으로 명확한 도메인 예외를 먼저 두고 주소 정보가 필요한 범위 규칙을 뒤에 두면 설정 의도를 더 쉽게 파악할 수 있습니다.

주소 규칙의 no-resolve는 해당 규칙 때문에 도메인을 직접 조회하는 동작을 제한할 수 있지만, 모든 DNS를 끄는 스위치는 아닙니다. 요청에 대상 IP가 이미 있으면 주소 매칭이 계속 적용될 수 있으며, 사용 가능한 주소가 없는 도메인 요청은 뒤쪽 규칙으로 넘어갈 수 있습니다. 이 옵션을 사용한 뒤에는 도메인으로 시작한 요청과 IP로 시작한 요청을 각각 테스트하세요. 한쪽만 확인해서는 안 됩니다. 구체적인 형식은 주소 섹션을 참고하고, 로그 한 줄을 줄이기 위해 모든 IP 규칙에 이 매개변수를 무작정 추가하지 마세요.

IPv4와 IPv6의 실제 연결 대상도 구분해야 합니다. 같은 도메인에서 여러 주소가 반환될 수 있으며, 앱이 선택하는 주소가 직접 조회했을 때 처음 표시된 주소와 다를 수 있습니다. IPv4 사설 네트워크만 처리하는 규칙이 모든 IPv6 상황까지 자동으로 처리하는 것은 아닙니다. 같은 도메인이 가끔 다른 경로로 연결된다면 실제 대상 주소, DNS 캐시, 연결 재사용 여부를 먼저 확인한 다음 다른 주소 체계에 규칙을 추가할지 판단하세요. 관찰 조건을 기록해야 결과를 재현할 수 있습니다.

04 / 주소 및 요청 특성

IP-CIDR, GEOIP, USER-AGENT 및 FINAL

IP-CIDR 및 IP-CIDR6: 대상 주소 범위 매칭

IP-CIDR은 주소와 프리픽스 길이로 IPv4 네트워크 범위를 나타냅니다. 192.168.0.0/16은 해당 사설 주소 대역을 포함하고, 192.168.1.20/32는 IPv4 주소 하나만 나타냅니다. 프리픽스가 길수록 범위는 좁아지지만, 여기서 ‘더 구체적’이라는 말은 주소 집합의 크기를 나타낼 뿐 규칙 순서를 바꾸지는 않습니다. IP-CIDR6은 IPv6에 사용합니다. 예를 들어 fd00::/8은 해당 로컬 주소 범위를 표현합니다. 프리픽스를 잘못 입력하면 의도보다 훨씬 넓은 대상까지 예외가 적용될 수 있습니다.

[Rule]
IP-CIDR,192.168.1.20/32,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fd00::/8,DIRECT,no-resolve
FINAL,PROXY

위 예시는 일부 주소 범위만 보여주며, 로컬 네트워크 처리 규칙 전체를 나타내지는 않습니다. DIRECT는 프록시 서버를 거치지 않고 요청을 보낸다는 뜻일 뿐, 대상 장치가 온라인이거나 라우팅이 설정되어 있거나 접근 권한이 허용된다는 보장은 없습니다. 프린터나 로컬 서비스에 접근할 수 없다면 장치 주소가 바뀌었는지, 현재 네트워크에서 장치 간 통신을 허용하는지, 필요한 시스템 권한이 있는지 확인하세요. 규칙이 매칭되었다는 이유만으로 이후 오류를 모두 앱 문제로 돌리지 마세요.

no-resolve는 선택적으로 사용하는 매칭 수정자이며, 해당 주소 판정을 위해 도메인을 직접 조회하지 않도록 합니다. 요청에 대상 주소가 포함되어 있으면 여전히 매칭될 수 있습니다. 도메인만 있고 적용할 주소 정보가 없으면 뒤쪽 항목을 계속 확인할 수 있습니다. 로컬 네트워크 서비스를 도메인으로 접속한다면 이 매개변수가 붙은 사설 주소 규칙만으로는 예상한 대로 처리되지 않을 수 있습니다. 먼저 정확한 DOMAIN 규칙으로 알고 있는 호스트를 처리한 다음 주소 범위 규칙을 필요한 경우에 유지하세요.

GEOIP: 주소 데이터베이스를 기준으로 지역 판별

GEOIP,CN,DIRECT는 사용 중인 데이터베이스에서 대상 주소를 CN으로 분류할 경우 DIRECT를 적용한다는 뜻입니다. 도메인 접미사, 웹페이지 언어, 계정 지역 또는 서비스 소유자를 판별하는 규칙이 아닙니다. 중국어 페이지가 다른 지역의 인프라를 사용할 수 있으며, 같은 도메인도 DNS 조회 조건에 따라 서로 다른 주소를 반환할 수 있습니다. 따라서 GEOIP는 넓은 주소 분류 조건으로 사용하는 것이 적합하며, 서비스별로 명확히 지정해야 하는 도메인 예외를 대신해서는 안 됩니다.

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

주소 데이터베이스의 지역 분류와 실제 연결 경로의 접근 가능성은 별개의 문제입니다. 특정 지역으로 분류되었다고 해서 직접 연결 속도가 빠르거나 연결이 성공하는 것은 아니며, 네트워크에 따라 관찰되는 대상 주소가 달라질 수도 있습니다. 문제를 확인할 때는 실제 대상 IP, 매칭된 규칙, 오류 유형을 함께 기록하세요. 특정 서비스에 고정 정책이 필요하다면 한 번의 예상 밖 결과만으로 모든 GEOIP 규칙을 바꾸기보다 서비스 범위를 설명할 수 있는 도메인 규칙을 추가하는 편이 낫습니다.

USER-AGENT: 요청 특성을 확인할 수 있을 때만 유효합니다

USER-AGENT는 확인 가능한 User-Agent 특성을 기준으로 매칭합니다. 예를 들어 USER-AGENT,ExampleApp*,DIRECT는 별표를 와일드카드로 사용합니다. 앱 이름이나 프로세스 기준으로 트래픽을 식별하는 것과는 다르며, 암호화된 모든 연결에서 이 요청 헤더를 확인할 수 있다고 가정해서도 안 됩니다. 일반적인 HTTPS 연결에서는 헤더가 암호화된 콘텐츠 안에 있어 클라이언트가 확인하지 못할 수 있습니다. 따라서 이 규칙은 조건이 명확한 경우에 보조적으로 사용해야 하며, 특정 앱의 모든 요청이 동일하게 분기된다고 보장하는 용도로는 적합하지 않습니다.

FINAL: 앞에서 매칭되지 않은 요청의 처리 방향 지정

FINAL에는 도메인이나 주소 매개변수가 필요하지 않습니다. 형식은 FINAL,PROXY 또는 FINAL,DIRECT입니다. 매칭 목록의 마지막에 두어 앞선 조건에 일치하지 않는 요청의 처리 방향을 지정하세요. 중간에 두면 뒤에 있는 일반 규칙은 매칭에 참여할 기회를 잃을 수 있습니다. 기본 정책을 선택할 때는 설정의 목적을 고려하세요. PROXY는 사용 가능한 프록시가 필요하고, DIRECT는 로컬 네트워크에서 직접 접근할 수 있어야 합니다. 어느 쪽도 연결 성공을 보장하지는 않습니다.

규칙을 조합할 때는 현재 요청에서 신뢰할 수 있는 정보가 무엇인지 먼저 확인하세요. 도메인을 알고 있다면 도메인 기준으로 의도를 표현하고, 주소 범위 처리가 필요한 경우에만 CIDR을 사용하며, 지역 분류는 더 넓은 범위에 두고 마지막에 FINAL로 마무리합니다. USER-AGENT처럼 요청 정보를 확인할 수 있어야 하는 규칙에는 해당 정보가 없을 때의 처리 방식도 마련하세요. 그러면 ‘매칭되면 어떻게 처리할지’뿐 아니라 ‘매칭되지 않으면 어디로 갈지’도 설정에 명확히 드러납니다.

06 / 우선순위

위에서 아래로 매칭하며, 첫 번째 일치 항목에서 멈춥니다

‘더 구체적인 규칙 우선’은 자동으로 적용되지 않습니다

Rule은 파일에 작성된 순서대로 확인합니다. 대상이 어떤 조건에 한 번 매칭되면 해당 규칙의 정책을 사용하고, 뒤의 일반 규칙에서는 정책을 다시 선택하지 않습니다. DOMAIN이 DOMAIN-SUFFIX보다 본질적으로 우선하지 않으며, 단일 주소 규칙이 넓은 대역보다 자동으로 앞서지 않습니다. REJECT도 의미가 강하다고 먼저 적용되지 않습니다. 우선순위를 결정하는 첫 번째 기준은 설정 파일에서의 위치입니다. 이 원칙을 이해하면 ‘규칙을 작성했는데 효과가 없는’ 경우 대부분 더 앞에서 매칭된 규칙으로 설명할 수 있습니다.

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

api.example.com은 첫 번째 줄에서 DIRECT로 처리됩니다. www.example.com은 첫 번째 줄에 매칭되지 않아 두 번째 줄에서 PROXY가 적용됩니다. 그 밖의 도메인만 GEOIP를 확인하고 마지막에 FINAL로 처리됩니다. 이는 점수를 매겨 모든 규칙을 비교하는 방식이 아니라, 중간에 종료 지점이 있는 판단 흐름입니다. www.example.com이 뒤쪽 GEOIP 규칙에 해당하는 주소를 반환하더라도 앞의 접미사 규칙에서 정책 선택이 끝났으므로 DIRECT로 바뀌지 않습니다.

반례로 순서 충돌 살펴보기

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

이 반례에서는 api.example.com이 접미사 규칙에 먼저 매칭되어 아래의 정확한 도메인 규칙이 예외를 적용하지 못합니다. 해결하려면 동일한 규칙을 파일 끝에 복사하는 대신 정확한 예외를 범위 규칙보다 앞에 두세요. 동일한 조건의 규칙이 여러 개라면 일반적으로 먼저 나오는 규칙이 결과를 결정합니다. 중복 항목은 읽기 어렵게 만들고 나중에 추가한 설정이 기존 설정을 덮어썼다고 오해하게 할 수 있습니다. 정리할 때 중복 규칙과 범위가 서로 포함되는 규칙을 확인하세요.

구체적인 예외, 서비스 범위, 넓은 분류 순으로 배치

관리하기 쉬운 구성 방법은 명확한 허용 또는 거부 예외를 먼저 두고, 서비스 도메인 범위, 대상 주소와 지역 조건을 차례로 처리한 뒤 마지막에 FINAL을 작성하는 것입니다. 앱에서 강제하는 고정 템플릿은 아니며, 규칙의 의도를 읽기 쉽게 정리하는 방법입니다. 서비스 요구 사항에 따라 순서를 바꿀 수 있지만, 각 규칙을 왜 앞에 두어야 하는지 설명할 수 있어야 합니다. 보기 좋게 정리하려고 Rule 전체를 알파벳순으로 정렬하면 기존 순서가 바뀔 수 있으므로 피하세요.

예외 규칙끼리 범위가 겹칠 수도 있습니다. 기본 도메인에는 PROXY를 적용하고 그중 한 API에는 DIRECT를 적용하며 또 다른 특정 호스트는 REJECT하려는 경우, 두 개의 정확한 호스트 규칙을 기본 도메인의 접미사 규칙보다 앞에 두어야 합니다. 같은 문자열이 포함된 DOMAIN-KEYWORD를 추가한다면 기존 예외보다 먼저 매칭되지 않는지도 확인하세요. 검토할 때 각 규칙이 따로 올바른지만 보지 말고, 위쪽에 더 넓은 조건이 있는지, 이 규칙 때문에 아래 항목들이 매칭되지 못하는지도 살펴보세요.

설정을 업데이트한 뒤 실제 규칙 목록을 다시 확인하세요

원격 설정을 업데이트하면 항목 순서가 바뀌거나 로컬 수정이 삭제되거나 새로운 범위 규칙이 추가될 수 있습니다. 업데이트 성공은 콘텐츠를 가져왔다는 뜻이지 기존 사용자 지정 내용이 유지되었다는 뜻이 아닙니다. 업데이트 후에는 중요한 예외, 마지막 FINAL, 사용자 지정 그룹 참조를 확인하고 자주 쓰는 대상으로 검증하세요. 개인 예외를 계속 관리해야 한다면 안정적으로 관리할 수 있는 설정 방식을 사용하고 수정 내용을 기록해 두세요. 업데이트할 때마다 기억에 의존해 변경 사항을 되살리지 마세요.

규칙 순서 문제를 찾을 때는 요청의 예상 판단 과정을 먼저 정리해 보세요. 대상 이름이 무엇인지, 주소 정보가 있는지, 가장 먼저 매칭될 수 있는 규칙이 무엇인지, 어떤 정책을 예상하는지 확인합니다. 그런 다음 이 과정을 로그 결과와 하나씩 대조하세요. 예상과 다르면 잘못된 파일을 사용하고 있는지, Global Routing이 Config인지, 새 연결을 관찰한 것인지 먼저 확인하세요. 이런 기본 조건이 일치한 뒤에야 특정 키워드의 매칭 범위를 살펴볼 필요가 있습니다.

성능과 가독성 사이의 균형도 고려해야 합니다. 정확한 도메인 규칙을 조회가 필요한 주소 판정보다 앞에 두면 불필요한 판정 의존성을 줄일 수 있지만, 줄 수를 줄이려고 명확한 대상을 하나의 넓은 키워드로 묶어서는 안 됩니다. 설명하고 재현할 수 있는 동작을 우선 관리하고 실제 중복만 정리하세요. 짧지만 범위를 설명할 수 없는 파일이 역할이 분명한 조금 긴 파일보다 관리하기 쉬운 것은 아닙니다.

08 / 검증 및 유지 관리

Logs로 문제를 찾고 사본에서 설정을 복원하세요

먼저 반복 가능한 관찰 조건을 마련하세요

검증을 시작하기 전에 현재 네트워크, Global Routing, 사용 중인 설정 파일, 실제 프록시 선택을 기록하세요. 그런 다음 특정 페이지를 열거나 API를 요청하는 것처럼 대상과 동작을 하나로 정합니다. ‘앱 전체가 작동하지 않는다’처럼 범위가 모호한 표현은 피하세요. Connectivity Test는 연결 상태를 확인하는 데 참고할 수 있지만, 한 번의 테스트 성공이 실제 서비스 요청의 검증을 대신하지는 않습니다. 프록시 연결 설정, 도메인 조회, 대상 API 응답은 각각 따로 확인해야 합니다.

테스트할 때는 가능한 한 다른 조건을 바꾸지 마세요. 네트워크를 전환하고 서버를 바꾸면서 DNS와 규칙까지 동시에 수정하면 결과가 개선되어도 어떤 변경이 영향을 줬는지 판단하기 어렵습니다. 규칙을 저장한 뒤 요청을 다시 보내고 연결 재사용과 캐시를 고려하세요. 필요한 경우 현재 작업을 안전하게 종료할 수 있는지 확인한 다음 연결을 새로 설정합니다. 특정 네트워크에서만 문제가 발생한다면 네트워크별 관찰 결과를 각각 보관하세요. 한 번의 성공으로 이전 실패를 무시하지 마세요.

‘요청, 매칭, 연결’ 순서로 기록을 확인하세요

Logs에 표시되는 구체적인 필드는 앱 내 내용을 기준으로 확인하세요. 먼저 요청 대상을 찾아 이번에 테스트한 호스트가 맞는지 확인합니다. 다음으로 적용된 정책과 확인 가능한 규칙 정보를 살펴보고 마지막으로 연결 오류나 응답 상태를 확인하세요. 기록에 IP만 있다면 도메인 규칙이 실패했다고 단정하지 말고 요청에서 사용할 수 있는 이름을 제공했는지 확인하세요. REJECT에 매칭된 사실이 확인되었다면 서버 포트를 조정하기보다 거부 규칙의 범위를 먼저 살펴보세요.

‘이름 해석 실패’라면 기록에서 주소를 얻었는지 확인하고 General 및 Host의 관련 설정을 살펴보세요. ‘연결 시간 초과’라면 프록시 경로를 설정하지 못한 것인지 대상 서비스가 응답하지 않은 것인지 구분합니다. ‘인증 실패’라면 기존 서버 정보가 빠짐없이 입력되었는지 확인하세요. 서로 다른 오류에 동일한 만능 해결 방법을 적용해서는 안 됩니다. 한 줄의 기록만으로 결론을 내리기 어렵다면 시간대를 기준으로 인접한 DNS 및 연결 기록을 함께 살펴볼 수 있습니다. 다만 같은 시각에 발생한 모든 백그라운드 요청을 테스트 요청으로 취급하지 마세요.

설정을 최소화한 뒤 항목별로 복원하세요

복사본을 간소화하면 복잡한 설정의 문제를 찾는 데 도움이 됩니다. 단, 간소화할 때 연결에 필요한 기존 정보는 유지하세요. 먼저 대상과 관련 없는 임시 변경 및 주소 매핑을 제거한 다음, 정확한 도메인 규칙 하나와 FINAL로 판단 흐름을 단순화합니다. 최소 설정 사본이 예상대로 작동하면 기존 항목을 몇 개씩 복원하고, 복원할 때마다 같은 대상을 다시 테스트하세요. 이렇게 하면 전체 파일에 계속 수정 사항을 추가하는 대신 어느 조건이 결과를 바꾸었는지 찾을 수 있습니다.

[Rule]
DOMAIN,api.example.org,DIRECT
FINAL,PROXY

이 예시는 규칙 선택을 확인하기 위한 것이며 백업하지 않은 전체 파일을 대체해서는 안 됩니다. 예상 결과는 api.example.org가 DIRECT에 매칭되고, 매칭되지 않은 나머지 요청은 PROXY를 사용하는 것입니다. 결과가 여전히 다르면 사본이 실제로 선택되었는지, Global Routing이 Config인지, 새 요청에 해당하는 기록을 확인하고 있는지 먼저 살펴보세요. 결과는 예상과 일치하지만 대상에 연결되지 않는다면 규칙 키워드를 더 추가하지 말고 연결 경로를 확인하세요.

변경 기록과 개인정보 보호 범위를 관리하세요

수정할 때마다 대상, 관련 규칙, 예상 결과, 실제 결과, 복원 방법을 간단히 기록하세요. 설정을 내보낼 때 서버 주소, 인증 정보, 비공개 구독 링크, 민감한 Host 매핑이 포함되어 있는지 확인합니다. 다른 사람과 공유할 때는 필요한 부분만 남기고 민감 정보를 가린 뒤 제공하세요. 로그에도 방문 대상과 쿼리 정보가 포함될 수 있으므로 문제를 설명하는 데 꼭 필요한 내용만 보관하세요. 가져오기와 연결 관련 문제는 자주 묻는 질문에서 확인할 수 있으며, 처음 설정하는 경우 시작하기로 돌아가세요.

기기를 바꾸기 전에 앱을 다시 받는 방법, 서버 정보, 설정 파일의 복구 방법을 각각 확인하세요. App Store에서 앱을 다시 받는다고 개인 설정까지 모두 자동으로 복원되는 것은 아닙니다. 시스템 요구 사항과 구매 가능 범위는 App Store 페이지에 표시된 내용을 기준으로 확인하세요. 설정 이동 방법은 설정 백업 및 기기 변경 후 복원 안내를 참고하세요. 복원한 뒤에는 파일과 인증 정보를 먼저 확인하고 주요 규칙을 다시 테스트하세요. 파일 이름이 같다는 이유만으로 내용도 동일하다고 판단하지 마세요.

유지 관리가 끝났다는 기준은 ‘더 이상 수정하지 않는 것’이 아닙니다. 중요한 대상이 예상한 규칙에 매칭되고, 매칭되지 않은 요청에는 명확한 기본 처리가 적용되며, 각 예외의 용도를 설명할 수 있고, 문제가 발생하면 사용 가능한 사본으로 돌아갈 수 있어야 합니다. 규칙 선택과 연결 결과를 나눠 검증하고 원격 설정과 직접 수정한 내용을 구분해 관리하면 네트워크 환경이나 설정이 바뀌어도 같은 관찰 절차를 따라 문제를 찾을 수 있습니다.