Shadowrocket 설정 가이드 규칙과 매칭 순서

설정 파일 구조: 데이터와 규칙 구분하기

Shadowrocket에서 서버 정보와 설정 파일은 서로 다른 역할을 합니다. 서버 정보는 연결 대상, 프로토콜, 인증 방식을 지정하고, 설정 파일은 요청 처리 방식과 직접 연결할 대상, 프록시 정책을 적용할 대상을 정합니다. 구독을 가져와 서버 목록이 표시되더라도 원하는 규칙 파일이 선택된 것은 아닙니다. 반대로 규칙이 모두 들어 있는 파일을 저장해도 참조된 프록시 출구에 필요한 연결 정보가 갖춰져 있다는 뜻은 아닙니다. 문제를 확인할 때는 두 항목을 따로 점검하세요.

Config의 파일과 실제 적용 중인 파일

Config로 이동한 뒤 현재 사용 중인 파일을 확인하고, 편집할 파일도 점검하세요. 목록에 설정 파일이 여러 개 있으면 파일 이름만으로 내용을 구분할 수 있을 뿐, 내용이 같다고 단정할 수는 없습니다. 수정 전에 사본을 저장하고 현재 Global Routing 모드와 선택된 서버를 기록해 두세요. 수정 후 접속 문제가 생기면 원본과 비교해 되돌릴 수 있습니다. 원격 설정 파일은 업데이트 방식도 확인해 로컬 수정 내용이 원본 파일에 의해 덮어쓰이지 않도록 하세요.

설정 파일은 보통 섹션별 구조를 사용합니다. 대괄호로 섹션 이름을 감싸고, 각 섹션에 설정이나 규칙을 한 줄씩 작성합니다. General에는 공통 옵션, Rule에는 요청 라우팅 규칙, Host에는 정적 호스트 매핑, URL Rewrite에는 조건에 맞는 URL 처리 규칙을 작성합니다. 각 섹션의 역할은 서로 다릅니다. 한 파일에 함께 들어 있다고 해서 처음부터 끝까지 실행되는 단일 규칙 목록으로 이해하면 안 됩니다. 특히 Host 항목을 Rule 섹션에 그대로 붙여 넣지 마세요.

[General]
bypass-system = true
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
FINAL,PROXY

예시를 읽을 때 문맥 유지하기

위 내용은 참고용 최소 예시입니다. General의 두 줄은 등호로 값을 지정하고, Rule 항목은 영문 쉼표로 구분합니다. 공통 옵션, 도메인 규칙, 사설 주소 규칙과 기본 처리 규칙의 관계만 보여 줄 뿐, 사용자의 서버 정보는 포함하지 않습니다. PROXY는 프록시 정책으로 요청을 전달한다는 뜻이며, 최종 출구는 현재 설정과 선택된 서버에 따라 달라집니다. example.com은 문서용 예시 도메인입니다. 실제 설정에서는 서비스 제공업체의 서버 주소가 아니라 처리하려는 대상을 입력하세요.

규칙 한 줄을 읽을 때는 먼저 첫 번째 필드의 규칙 유형을 확인하고, 다음으로 매칭 대상을 본 뒤 정책과 선택적 매개변수를 살펴보세요. 예를 들어 IP-CIDR 행에는 DOMAIN-SUFFIX 행과 달리 no-resolve가 추가되어 있는데, 이는 도메인 조회를 일으키는지와 관련된 옵션이지 정책 이름이 아닙니다. FINAL은 매칭 대상 필드가 없는 별도 형식입니다. 복사할 때 영문 문장 부호와 필드 순서를 유지하세요. 입력기가 쉼표를 전각 쉼표로 바꾸거나 섹션 이름에 불필요한 문자를 추가하지 않도록 주의하세요.

주석은 별도 줄에 작성하고, 규칙 내용을 그대로 반복하기보다 해당 예외가 필요한 이유를 설명하세요. 다른 곳에서 가져온 설정은 어느 섹션에 속하는지, 어떤 전제 조건이 필요한지 먼저 확인한 뒤 삽입 위치를 정하세요. 섹션 이름이 비슷한 설정 파일이라고 해서 모두 그대로 호환되는 것은 아닙니다. 설정 항목, 선택적 매개변수와 기능 지원 여부는 Shadowrocket 앱 내의 최신 설명을 기준으로 확인하세요. 인식되지 않는 항목은 한 줄씩 범위를 좁혀 검증하세요.

로컬 관리와 구독 업데이트의 범위

Subscribe는 주로 서버 항목 업데이트에 사용하며, Config 파일 업데이트는 규칙, DNS 또는 기타 공통 동작을 바꿀 수 있습니다. 두 항목이 같은 서비스 제공업체에서 제공되더라도 업데이트 범위는 다를 수 있습니다. 업데이트하기 전에 어떤 종류의 콘텐츠를 갱신하는지 확인하고, 업데이트 후 서버 선택과 규칙 파일이 바뀌었는지 살펴보세요. 연결 문제를 모두 구독 만료 탓으로 돌리면 파일 전환이나 로컬 예외 규칙 교체가 원인인 경우를 놓칠 수 있습니다.

설정을 저장한 뒤에는 편집기가 닫혔는지만 확인하지 말고 실제 사용 화면으로 돌아가 적용 상태를 점검하세요. 일부 옵션은 새 연결부터 적용되므로 기존 연결에는 이전 통신 경로가 계속 사용될 수 있습니다. 비교 테스트는 기존 요청을 종료한 뒤 새로 시작하세요. 연결을 다시 설정해야 한다면 진행 중인 작업을 먼저 저장하세요. 전체 절차는 사용 설명서를 참고하세요. 이후 내용에서는 각 설정을 판단하는 기준을 설명합니다.

도메인 규칙: 정확 일치, 접미사 및 키워드

도메인 규칙은 '이 서비스에 어떤 정책을 적용할지' 표현하기에 적합하며, 계속 바뀌는 서비스 주소를 관리하는 것보다 이해하기 쉬운 경우가 많습니다. 규칙 유형을 고르기 전에 하나의 호스트 이름, 도메인과 그 하위 도메인 전체, 또는 특정 문자열을 포함하는 모든 도메인 중 어느 범위를 다룰지 정하세요. 세 유형은 적용 범위가 점차 넓어지므로 짧게 작성할 수 있다는 이유만으로 가장 넓은 유형을 선택하지 마세요. 범위가 넓을수록 관련 없는 요청이 매칭되지 않는지 더 꼼꼼히 확인해야 합니다.

DOMAIN: 전체 도메인 정확히 일치

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

DOMAIN은 전체 도메인 이름과 일치하는 요청을 찾습니다. 첫 번째 줄은 api.example.com의 처리 방식만 지정하며 example.com이나 그 하위 도메인을 자동으로 포함하지 않습니다. 단일 API에 적용하거나 넓은 범위의 규칙보다 앞에 둘 특정 예외에 적합합니다. 호스트 이름만 입력하고 https://, 포트, 경로, 쿼리 매개변수는 넣지 마세요. 이런 URL 구성 요소는 DOMAIN의 매칭 필드가 아니므로 함께 입력하면 의도한 대상과 달라질 수 있습니다.

정확 일치 규칙은 각 항목을 구체적인 서비스와 연결할 수 있어 검토하기 쉽습니다. 다만 페이지에서 다른 도메인도 요청한다면 각각 어떤 정책을 적용할지 확인해야 합니다. 기본 도메인이 매칭되었다고 해서 로그인, 이미지, 인증, API 요청도 같은 출구를 사용한다고 단정하지 마세요. 문제를 확인할 때는 실패한 요청 기록에서 실제 호스트 이름을 확인하고 규칙 추가 여부를 결정하세요. URL만 보고 의존 도메인을 추측하면 실제 장애 지점을 놓치기 쉽습니다.

DOMAIN-SUFFIX: 도메인 범위에 따른 매칭

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

DOMAIN-SUFFIX,example.com,DIRECT는 example.com과 그 하위 도메인을 대상으로 합니다. 도메인 접미사 관계를 확인하는 규칙이므로 임의의 문자열 포함 검색과는 다릅니다. 이름에 example.com이라는 글자가 들어 있다는 이유만으로 다른 도메인을 같은 범위로 취급하지 마세요. 위 예시에서는 api.example.com에 먼저 PROXY를 지정하고 해당 도메인의 다른 요청은 DIRECT로 처리합니다. 구체적인 예외를 먼저, 포괄적인 규칙을 나중에 배치하면 예외와 기본 동작을 쉽게 구분할 수 있습니다.

접미사 규칙에는 일반적으로 example.com을 입력하세요. 브라우저의 전체 URL을 그대로 복사하거나 웹페이지 경로를 도메인 일부로 넣지 마세요. 다른 문법에서 쓰던 습관대로 *.example.com을 적용해서도 안 됩니다. 호스트 이름 하나만 필요하면 DOMAIN을 사용하고, 하위 도메인 전체를 다뤄야 할 때는 DOMAIN-SUFFIX를 사용하세요. 규칙의 개수보다 실제 서비스 요구사항에 따라 범위를 정해야 합니다.

DOMAIN-KEYWORD: 더 넓은 문자열 범위

[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

DOMAIN-KEYWORD는 도메인에 지정된 문자열이 포함되어 있는지 확인합니다. 해당 문자열이 브랜드명, 조직명 또는 도메인 경계인지 구분하지 않으므로 example은 서로 관련 없는 여러 도메인에 포함될 수 있습니다. 키워드 규칙은 적용 범위를 정확히 알고 있는 경우에 적합하며 임시 진단에도 사용할 수 있습니다. 다만 대상 도메인을 검토하는 절차를 대신하지는 않습니다. 짧거나 흔한 단어, 업무와 관련된 포괄적인 단어는 의도하지 않은 매칭을 일으키기 쉽습니다.

키워드 규칙을 정확 일치 규칙보다 앞에 두면 뒤의 정확 일치 규칙은 해당 요청을 처리할 기회를 잃습니다. 정확 일치 규칙이 더 구체적으로 보여도 자동으로 우선순위가 높아지지는 않습니다. 테스트할 때는 실제로 포함해야 하는 도메인, 같은 문자열이 들어 있지만 제외해야 하는 도메인, 전혀 관련 없는 도메인을 각각 확인하세요. 포함과 제외가 모두 예상대로 작동해야 현재 설정에 적합한 범위라고 판단할 수 있습니다.

규칙의 매칭 대상은 서버 이름이 아닙니다

도메인 규칙의 매칭 대상은 요청 대상이며 Home에 표시된 서버 별칭이 아닙니다. 서버 이름을 바꿔도 DOMAIN-SUFFIX의 매칭 대상은 바뀌지 않습니다. 반대로 대상 도메인 규칙을 수정해도 서버 인증 매개변수가 바뀌지는 않습니다. 같은 대상에 Proxy 모드에서는 접속되지만 Config 모드에서는 실패한다면 Add Server 정보를 다시 입력하기 전에 매칭 정책과 출구부터 비교하세요. 두 영역의 변경은 나누어 검증해야 합니다.

기존 도메인 규칙은 '정확한 예외, 분명한 접미사, 필요한 키워드' 순으로 정리하고 각 그룹의 목적을 기록해 보세요. 중복 항목을 삭제하기 전에 정책부터 비교해야 합니다. 같은 도메인이라도 정책이 다르면 임의로 합칠 수 있는 중복이 아닙니다. 대상을 차단하려면 정책을 REJECT로 바꿀 수 있지만 매칭 범위를 판단하는 방식은 같습니다. 자세한 내용은 REJECT 규칙과 차단 원리를 참고하세요.

연결 정책과 Global Routing의 세 가지 모드

규칙은 클라이언트에 '어떤 요청이 이 유형에 해당하는지' 알려 주고, 정책은 '해당 요청을 어떻게 처리할지' 정합니다. PROXY, DIRECT, REJECT는 규칙에서 사용하는 정책 키워드입니다. Global Routing의 Config, Proxy, Direct는 전체 동작 모드입니다. 서로 관련된 이름이지만 같은 계층은 아닙니다. 문제를 확인하기 전에 현재 모드와 매칭된 정책을 함께 기록해야 모드 변경으로 생긴 결과를 규칙 수정 효과로 오해하지 않습니다.

PROXY, DIRECT 및 REJECT

PROXY는 매칭된 요청을 프록시 정책으로 전달합니다. 실제 연결 여부는 출구 선택, 프로토콜 매개변수, 인증 정보와 현재 네트워크에 따라 달라집니다. 모든 대상에 접속할 수 있다고 보장하거나 서버를 자동으로 생성하지 않습니다. DIRECT는 대상에 직접 연결한다는 뜻이며, 연결은 현재 기기가 접속한 네트워크를 통해 이루어집니다. REJECT는 매칭된 요청을 거부합니다. 클라이언트는 해당 요청을 실패로 종료할 수 있으며, 다른 서버로 요청을 전달하는 동작은 아닙니다.

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,local.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
FINAL,PROXY

세 가지 예시는 각각 프록시, 직접 연결, 거부 처리를 나타내며 도메인은 설명용입니다. api.example.com이 PROXY에 매칭된 뒤 실패한다면 다음으로 출구를 확인하세요. 클라이언트가 자동으로 DIRECT로 되돌아간다고 가정하지 마세요. blocked.example.com이 REJECT에 매칭된다면 연결 실패는 정책이 의도한 결과이므로 서버 장애의 증거로 볼 수 없습니다. 테스트 전에 성공 기준을 정하세요. 접속 허용인지, 지정한 출구를 통한 연결인지, 예상대로 거부되는지 구분해야 합니다.

Config, Proxy 및 Direct를 비교하는 방법

세 가지 모드에 대한 설명은 문제를 체계적으로 확인하기 위한 것이며, 시스템의 모든 트래픽이 반드시 같은 방식으로 처리된다는 뜻은 아닙니다. 시스템 트래픽, 설정의 우회 항목과 특정 기능에 따라 처리 범위가 달라질 수 있습니다. 비교 테스트에서는 같은 네트워크 환경에서 동일한 대상에 새 요청을 보내고 실제 기록을 확인하세요. 상태 표시줄 아이콘이나 특정 페이지가 열린다는 사실만으로 모든 요청의 연결 경로를 확인할 수는 없습니다.

Proxy에서는 연결되는데 Config에서는 안 된다면 대상이 DIRECT, REJECT 또는 더 앞선 다른 규칙에 매칭되는지 먼저 확인하고, 현재 Config 파일이 맞는지도 살펴보세요. Config와 Proxy 모두 실패한다면 서버 주소, 포트, 프로토콜과 인증 정보를 확인하고, 접속 가능한 다른 대상으로 테스트해 출구 전체의 문제인지 특정 대상만의 문제인지 구분하세요. Direct에서 연결된다는 사실은 현재 네트워크에 가능한 경로가 있다는 뜻일 뿐, 프록시 설정이 올바르다는 증거는 아닙니다.

선택한 서버와 규칙 정책의 관계

Home에서 선택한 서버, 설정에 있는 정책 그룹, 규칙에서 참조하는 정책 이름은 같은 문맥에서 확인해야 합니다. 단순한 설정에서는 PROXY로 현재 프록시 정책에 요청을 전달할 수 있습니다. 복잡한 설정에서 사용자 지정 정책 이름을 참조한다면 그 이름이 실제로 존재하고 유효한 항목을 가리키는지 확인해야 합니다. 다른 사람의 설정 파일에 있는 사용자 지정 이름을 공통 키워드처럼 복사하지 마세요. 서버 별칭을 바꾸더라도 모든 참조가 자동으로 유효하게 유지되는 것은 아닙니다.

프로토콜 매개변수는 프록시 연결 자체를 설정하는 방식이며 규칙 정책과는 인접해 있지만 별개의 계층입니다. 예를 들어 Trojan을 사용하려면 기존 서버 정보에 따라 주소, 포트, 비밀번호와 TLS 관련 매개변수를 입력해야 합니다. 규칙을 DIRECT에서 PROXY로 바꿔도 인증 매개변수가 잘못된 문제는 해결되지 않습니다. 관련 필드의 입력 범위는 Trojan 매개변수 안내를 참고하세요. 문제를 확인할 때도 규칙과 서버 설정을 분리해 살펴봐야 합니다.

REJECT도 콘텐츠 필터링에 필요한 모든 기능을 대신하지는 않습니다. 한 도메인이 필수 기능과 거부하려는 요청을 함께 제공할 수 있으므로 도메인 전체를 거부하면 로그인, 로딩이나 동기화에 영향을 줄 수 있습니다. 암호화된 트래픽에서는 도메인 규칙만으로 같은 호스트의 서로 다른 웹페이지 경로를 구분하기 어렵습니다. 더 세밀한 제어가 필요하다면 매칭 대상 정보의 가시성과 기능 범위를 먼저 확인하세요. 범위가 더 넓은 키워드 규칙을 계속 추가해서는 안 됩니다.

비교 테스트를 마친 뒤에는 원래 사용하려던 모드로 복구하고 다시 테스트하세요. 연결 검증을 위해 Proxy를 임시로 사용한 뒤 Config로 돌아가지 않는 것은 규칙이 작동하지 않는 것처럼 보이는 흔한 원인입니다. Direct를 임시로 사용한 뒤 복구하지 않아도 비슷한 오해가 생길 수 있습니다. 테스트 기록 한 줄에 현재 모드, 서버와 파일을 함께 적어 두면 문맥 없이 성공한 스크린샷을 많이 보관하는 것보다 이후 관리에 도움이 됩니다.

Host 및 URL Rewrite: 주소 매핑과 요청 처리

Host, URL Rewrite와 Rule은 같은 설정 파일에 함께 나타날 수 있지만 같은 방식으로 이해해서는 안 됩니다. Host는 지정된 호스트 이름에 정적 주소를 매핑하고, URL Rewrite는 식별 가능한 URL의 매칭 조건에 따라 요청을 처리하며, Rule은 연결 정책을 선택합니다. 각각 '주소 출처', '요청 처리 방식', '연결 경로'를 다룹니다. 문제가 여러 계층에 걸쳐 있다면 각 계층이 예상대로 작동하는지 따로 확인하세요.

Host: 조회 결과 고정은 출구 지정과 다릅니다

[Host]
service.example.com = 192.0.2.10

이 예시는 service.example.com을 예시 주소 192.0.2.10에 매핑합니다. 이 주소는 문서용 예시 주소 대역에서 가져온 것으로 접속 가능한 서비스 주소가 아닙니다. Host 행은 등호를 사용하며 Rule의 쉼표 형식을 사용하지 않습니다. 뒤에 PROXY를 붙여 정책을 지정할 수도 없습니다. 같은 대상에 특정 연결 방식이 필요하다면 Rule에 별도 규칙을 작성하고 실제 연결 기록에서 대상 주소와 정책이 모두 예상대로 적용되는지 확인하세요.

Host는 대상 주소가 명확하고 관리할 수 있는 경우에 적합하며 자주 바뀌는 공용 서비스 주소를 임의로 고정하는 데는 적합하지 않습니다. 도메인 뒤에서 여러 지역으로 연결을 분산하거나 장애 시 다른 주소로 전환하고 주소를 순환할 수 있습니다. 주소 하나를 고정하면 이런 변경을 따르지 못해 시간이 지나면서 작동하지 않을 수 있습니다. 매핑을 추가할 때는 용도, 유효 조건과 제거 방법을 기록하고, 한 번 조회한 주소를 장기적인 해결책으로 사용하지 마세요.

HTTPS 요청에서는 도메인이 인증서 확인과 서비스 선택에도 사용됩니다. 매핑한 주소에 TCP 연결이 되더라도 인증서, SNI 또는 가상 호스트 설정 때문에 대상 서비스가 요청을 거부할 수 있습니다. Host 매핑이 임의의 주소에 해당 도메인의 유효한 인증서를 제공하거나 서버 인증 매개변수를 바꾸지는 않습니다. 인증서 오류가 발생하면 대상 서비스 설정을 확인하세요. 주소가 올바른지 확인하는 대신 인증서 검증을 끄지 마세요.

URL Rewrite: 먼저 매칭 범위 이해하기

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

위 예시는 일반 HTTP의 정확한 경로 하나를 대상으로 리디렉션을 보여 줍니다. 정규 표현식으로 이전 주소와 매칭하고, 새 URL을 대상 주소로 지정하며, 302는 임시 리디렉션 처리를 나타냅니다. 도메인 라우팅 규칙이 아니므로 Rule 섹션에 넣으면 안 됩니다. 마침표를 백슬래시와 마침표로 표기한 것은 도메인 구분 기호를 문자 그대로 매칭하기 위해서입니다. 앞뒤 앵커는 더 긴 경로나 추가 문자가 예시에 함께 매칭되지 않도록 범위를 제한합니다.

URL의 쿼리 매개변수도 매칭 결과에 영향을 줍니다. 위 예시의 마지막 달러 기호는 추가 쿼리 문자열이 있는 주소가 정확한 매칭 범위에 포함되지 않는다는 뜻입니다. 쿼리 문자열을 허용할지는 실제 요구사항에 맞게 표현식을 다시 설계하세요. '모두 매칭되게' 하려고 경계를 임의로 제거하거나 범위가 넓은 와일드카드를 추가하지 마세요. 수정 전에 포함해야 하는 사례와 제외해야 하는 사례를 적고 하나씩 검증하면 경로, 매개변수와 이스케이프 차이를 파악하는 데 도움이 됩니다.

HTTPS 가시성과 리디렉션 반복 위험

도메인을 라우팅에 사용할 수 있다고 해서 암호화된 요청의 전체 경로와 헤더까지 자동으로 보이는 것은 아닙니다. HTTPS에서는 경로가 암호화된 콘텐츠에 있으므로 도메인 규칙만으로 URL Rewrite가 처리할 수 있다고 단정할 수 없습니다. 암호화된 콘텐츠를 추가로 처리하려면 인증서 신뢰, 적용 도메인과 개인정보 보호 영향을 별도로 이해해야 합니다. 이 페이지의 예시가 HTTP를 사용하는 이유는 간단한 Rewrite 예시 뒤에 추가 전제 조건을 숨기지 않기 위해서입니다.

Rewrite 규칙은 이전 주소가 새 주소로 이동하고 새 주소가 다른 규칙에 의해 다시 이전 주소로 바뀌는 반복을 일으킬 수도 있습니다. 이 경우 브라우저가 계속 재시도하거나 리디렉션 횟수가 너무 많다는 오류가 표시됩니다. 대상 주소가 원래 매칭 표현식에 계속 해당되어 같은 규칙이 반복 적용될 수도 있습니다. 테스트할 때는 최종 페이지뿐 아니라 리디렉션 경로를 확인하세요. 각 단계를 설명할 수 없다면 표현식의 범위를 줄이고 겹치는 규칙을 잠시 제거하세요.

Host를 검증할 때는 기존 Rule을 그대로 두고 대상 주소의 출처만 비교하세요. URL Rewrite를 검증할 때는 먼저 명확한 HTTP 테스트 주소로 리디렉션을 확인한 다음 대상 주소의 라우팅 결과를 살펴보세요. 세 섹션을 한 번에 수정하면 결과가 성공해도 어떤 설정이 영향을 줬는지 확인하기 어렵습니다. 실제 서비스 요청을 테스트할 때는 로그인 리디렉션, 양식 제출이나 다른 상태 유지 요청에 영향을 주지 않도록 원본 설정 사본을 보존하세요.

설정 출처를 업데이트한 뒤에는 Rule만 바뀌었는지 볼 것이 아니라 Host와 URL Rewrite도 다시 확인해야 합니다. 주소 매핑이 만료되었거나 서비스 경로가 바뀌었을 수 있으며 이전에 필요했던 Rewrite가 새 동작과 충돌할 수도 있습니다. 관리 기록에는 최소한 대상, 용도와 되돌릴 조건을 포함하세요. 출처와 목적을 설명할 수 없는 항목은 장기간 유지하기보다 사본에서 먼저 비활성화해 테스트한 후 삭제 여부를 결정하는 편이 영향을 통제하기 쉽습니다.