Shadowrocket에서 일부 웹사이트만 프록시 사용: DOMAIN-SUFFIX 및 FINAL 규칙 작성 예시

이 글 한눈에 보기

이 글은 Shadowrocket에서 기본 연결을 완료하고 프록시 적용 범위를 줄이려는 사용자에게 적합합니다. 핵심은 Global Routing을 Config로 설정하고 지정한 웹사이트의 도메인 조건을 규칙 상단에 작성한 뒤 FINAL,DIRECT로 매칭되지 않은 트래픽을 처리하는 것입니다. 이후 임시 규칙, 요청 동작, 규칙 순서를 차례로 확인합니다.

먼저 Config가 요청을 처리하는 방식을 확인하세요

Shadowrocket의 규칙 분류는 Global Routing이 Config일 때 Config의 Rule 순서에 따라 실행됩니다. 현재 상태가 Proxy이면 트래픽이 모두 프록시 정책으로 전달되고, Direct이면 직접 연결됩니다. Scene은 조건에 따라 상태를 선택합니다. 일부 웹사이트만 프록시를 사용하려면 먼저 Home에서 Global Routing을 확인하고 Config를 선택하세요.

규칙 엔진은 위에서 아래로 검사하며 처음 일치한 규칙에서 멈춥니다. 요청이 적용 가능한 첫 번째 규칙과 일치하면 뒤의 DOMAIN-SUFFIX, GEOIP, FINAL은 더 이상 판단하지 않습니다. 따라서 범위가 좁은 예외 규칙은 넓은 규칙보다 앞에 두고, 기본 처리 규칙은 마지막에 배치해야 합니다.

앱이 요청을 시작함시스템 터널로 진입대상 정보 읽기규칙을 순서대로 매칭아웃바운드 정책 선택

1회

첫 일치 후 추가 매칭 중지

4가지 상태

Global Routing：Config / Proxy / Direct / Scene

2개 계층

도메인 규칙과 대상 IP 규칙

80 / 443

일반적인 HTTP 및 HTTPS 포트

규칙 매칭의 입력값은 도메인만이 아닙니다

도메인 정보: DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD에 사용됩니다. 이 규칙은 호스트 이름을 매칭하며 URL의 경로, 쿼리 매개변수 또는 웹페이지 제목은 매칭하지 않습니다.
대상 IP: IP-CIDR 및 GEOIP에 사용됩니다. 도메인 확인이 끝난 뒤 대상 주소가 IP 계층 규칙의 판단에 계속 사용될 수 있습니다.
대상 포트: DOMAIN-SUFFIX는 도메인 자체를 기준으로 합니다. 웹사이트가 일반적인 80, 443 또는 다른 포트를 사용하더라도 호스트 이름이 일치하면 도메인 규칙이 적용됩니다.
최종 기본 규칙: FINAL은 앞선 모든 규칙이 처리하지 못한 트래픽을 처리하므로 반드시 규칙 목록의 마지막에 배치해야 합니다.

DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOIP 및 FINAL의 차이

이 네 가지 규칙의 적용 범위는 서로 다릅니다. 지정한 웹사이트만 프록시를 사용하게 하려면 일반적으로 DOMAIN 또는 DOMAIN-SUFFIX를 우선 사용하고, DOMAIN-KEYWORD는 도메인 구조가 일정하지 않지만 명확하고 고정된 문자열이 있는 경우에만 사용합니다. GEOIP는 대상 IP를 지역 데이터베이스에 따라 분류하며, FINAL은 도메인이나 주소를 확인하지 않고 남은 요청을 바로 처리합니다.

규칙의 마지막 항목은 정책입니다. PROXY는 프록시 정책으로 전달하고, DIRECT는 직접 연결하며, REJECT는 요청을 거부합니다. Config에서 사용자 지정 정책 그룹 이름을 사용하는 경우 규칙 끝에는 Config에 실제로 존재하며 철자까지 정확히 일치하는 이름을 입력해야 합니다. 정책 이름이 다르면 규칙이 정상적으로 매칭되어도 원하는 아웃바운드 결과를 얻을 수 없습니다.

규칙 키워드	매칭 대상	적합한 상황	주의 사항
DOMAIN	전체 도메인	하나의 명확한 호스트 이름만 처리	하위 도메인이 자동으로 포함되지 않음
DOMAIN-SUFFIX	도메인 접미사	기본 도메인과 하위 도메인을 함께 포함	범위를 지나치게 넓게 작성하지 않기
DOMAIN-KEYWORD	도메인 내 문자열	고정 키워드를 포함한 여러 도메인 매칭	관련 없는 도메인까지 잘못 매칭될 수 있음
GEOIP	확인된 대상 IP	주소가 속한 지역에 따라 분류	결과는 IP와 로컬 데이터베이스의 판단에 좌우됨
IP-CIDR	IPv4 주소 범위	고정된 주소 대역 처리	주소가 변경되면 함께 수정해야 함
FINAL	남은 모든 요청	기본 아웃바운드 경로 정의	반드시 규칙 마지막에 배치

같은 도메인의 넓은 규칙과 좁은 규칙

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

위 예시는 먼저 static.example.com을 DIRECT로 지정한 다음 example.com과 다른 하위 도메인에 PROXY를 적용합니다. 두 번째 줄을 첫 번째 줄보다 앞에 배치하면 정적 도메인이 먼저 DOMAIN-SUFFIX와 일치하므로 뒤의 DOMAIN 예외 규칙은 실행되지 않습니다.

결론: 예외를 먼저, 범위를 다음에, 기본 규칙을 마지막에 작성하세요

규칙 순서를 확인할 때는 「전체 도메인 → 도메인 접미사 → 광범위한 키워드 → IP 분류 → FINAL」 순서로 정리할 수 있습니다. 다른 순서가 필요한 경우에도 좁은 조건이 이를 포함할 수 있는 넓은 조건보다 앞에 오도록 해야 합니다.

바로 수정해 사용할 수 있는 「지정 웹사이트는 프록시, 나머지는 직접 연결」 Config

아래 예시는 실제 서비스와 무관한 예시 도메인을 사용합니다. 편집하기 전에 현재 Config를 백업용으로 복사한 다음 Config로 이동해 사용 중인 로컬 설정의 Rule 구간을 편집하세요. 사용자 본인의 구독에서 가져온 설정은 이후 업데이트로 수동 변경 사항이 덮어써질 수 있습니다. 별도의 로컬 Config를 보관하고 사용자 지정 규칙을 명확히 기록하는 편이 안전합니다.

예시의 PROXY는 현재 Config에서 사용할 수 있는 프록시 정책과 일치해야 합니다. 규칙은 요청을 어느 정책으로 전달할지만 결정하며 기존 설정의 프로토콜을 변경하지 않습니다. 현재 연결이 Shadowsocks, VMess, VLESS, Trojan, Hysteria2 또는 WireGuard를 사용하더라도 DOMAIN-SUFFIX의 첫 일치 방식은 동일합니다.

[Rule]
DOMAIN,login.example.com,PROXY
DOMAIN-SUFFIX,example.net,PROXY
DOMAIN-KEYWORD,media-example,PROXY
GEOIP,CN,DIRECT
FINAL,DIRECT

전체 도메인 바꾸기: login.example.com을 별도로 처리할 호스트 이름으로 변경하세요. DOMAIN에는 전체 호스트 이름을 입력해야 하며 https://, 포트, 슬래시 또는 페이지 경로를 덧붙이지 마세요.
도메인 접미사 바꾸기: example.net을 대상 웹사이트의 기본 도메인으로 변경하세요. DOMAIN-SUFFIX는 해당 도메인 자체와 그 하위 도메인에 적용됩니다.
키워드는 신중하게 유지하기: 여러 대상 도메인이 유일한 문자열을 공유한다는 사실을 확인한 경우에만 DOMAIN-KEYWORD를 사용하세요. 필요하지 않다면 해당 줄을 삭제해도 됩니다.
기본 경로 확인: FINAL,DIRECT는 「나머지 트래픽 직접 연결」의 핵심입니다. FINAL,PROXY로 잘못 작성하면 매칭되지 않은 요청도 프록시 정책으로 전달됩니다.
저장하고 적용하기: Config로 돌아가 방금 편집한 설정이 선택되어 있는지 확인한 다음 Home에서 Global Routing을 Config로 전환하고 연결을 다시 설정하세요.

고정 IP 예외가 필요한 경우

[Rule]
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
DOMAIN-SUFFIX,example.net,PROXY
FINAL,DIRECT

192.0.2.0/24는 문서용 예시 주소 대역입니다. no-resolve는 매칭을 위해 추가 도메인 확인을 수행하지 않는다는 뜻이며, 대상이 이미 IP 형식으로 표시된 경우에 적합합니다. 한 번의 확인 결과만으로 웹사이트 주소 대역을 장기간 고정하지 마세요. 분산 네트워크를 사용하는 웹사이트는 지역, 시간, 네트워크 조건에 따라 서로 다른 주소를 반환할 수 있습니다.

규칙이 지정한 웹사이트에만 실제로 적용되는지 확인하는 방법

저장에 성공했다고 해서 규칙이 예상대로 작동한다는 뜻은 아닙니다. 확인할 때는 「Config가 활성화되어 있는지」, 「대상 도메인이 완전한지」, 「더 앞선 항목에 의해 가로채이지 않았는지」, 「웹사이트가 다른 도메인을 호출하는지」를 나누어 점검해야 합니다. 한 번에 하나의 변수만 변경해야 어떤 규칙이 현상을 일으켰는지 판단할 수 있습니다.

상태 확인: Home에서 Global Routing을 확인해 현재 Config인지 확인하세요. Proxy, Direct 또는 Scene이 일시적으로 전환한 다른 상태가 아니어야 합니다.
설정 확인: Config로 이동해 새 규칙이 포함된 로컬 설정이 선택되어 있는지 확인하세요. 활성화되지 않은 복사본을 편집해도 현재 트래픽에는 변화가 없습니다.
일반 웹사이트부터 테스트: 규칙에 입력하지 않은 사이트를 엽니다. 마지막 줄이 FINAL,DIRECT이므로 직접 연결 경로로 처리되어야 합니다.
대상 웹사이트를 다시 테스트: DOMAIN-SUFFIX에 입력한 사이트를 엽니다. 홈페이지는 열리지만 이미지, 로그인 또는 동영상이 실패한다면 페이지가 다른 도메인도 호출하고 있을 가능성이 큽니다.
종속 도메인 추가: Shadowrocket에서 확인할 수 있는 요청 호스트 이름을 기준으로 실제 필요한 DOMAIN 또는 DOMAIN-SUFFIX를 하나씩 추가하세요. 의미가 모호한 키워드로 범위를 바로 넓히지 마세요.
예외 재확인: 대상 웹사이트, 일반 웹사이트, 시스템에서 자주 사용하는 네트워크 기능을 함께 테스트해 새 규칙이 FINAL 뒤에 배치되지 않았고 관련 없는 도메인까지 포함하지 않는지 확인하세요.

임시 REJECT로 도메인 매칭 여부 확인

특정 도메인이 실제로 페이지 로딩에 사용되는지 확신할 수 없다면 해당 도메인의 정책을 잠시 REJECT로 변경할 수 있습니다. 관련 리소스의 로딩이 즉시 중단되면 도메인과 규칙 위치가 유효하다는 뜻입니다. 확인이 끝나면 바로 PROXY 또는 DIRECT로 되돌리세요. 이 방법은 규칙 위치를 찾는 용도이며 장기 설정에는 적합하지 않습니다.

[Rule]
DOMAIN-SUFFIX,assets.example.net,REJECT
FINAL,DIRECT

오류: Failed to load config

원인 및 해결 방법: 흔한 원인은 Rule 줄의 쉼표 누락, 구간 제목의 불완전한 표기 또는 정책 필드가 비어 있는 경우입니다. Config로 돌아가 각 줄이 「규칙 키워드,매칭 값,정책」 구조를 유지하는지 확인하고, [Rule]이 단독 줄에 있는지 확인한 뒤 다시 불러오세요.

오류: Policy not found

원인 및 해결 방법: 규칙 끝에 입력한 정책 이름이 현재 Config에 없거나 실제 이름과 대소문자가 다릅니다. 기존 정책 이름을 확인해 한 글자씩 정확히 바꾸고, 다른 설정의 사용자 지정 이름을 그대로 사용하지 마세요.

흔한 오차와 추가로 범위를 좁히는 방법

하나의 웹사이트가 보통 하나의 도메인만 사용하는 것은 아닙니다. 메인 페이지, 정적 리소스, 로그인 API, 미디어 리소스가 서로 다른 호스트 이름에 있을 수 있습니다. 따라서 기본 도메인만 작성한 뒤 「페이지 틀은 열리지만 내용이 없음」 현상이 나타나도 Shadowrocket이 규칙을 무시한 것이 아니라 페이지에 필요한 다른 요청을 포함하지 않은 것입니다.

반면 DOMAIN-KEYWORD는 편리하지만 실제 적용 범위를 문자열만 보고 정확히 판단하기 어렵습니다. 예를 들어 키워드가 관련 없는 여러 도메인에 포함되어 있으면 모두 같은 정책과 매칭됩니다. 장기 설정에는 DOMAIN 또는 DOMAIN-SUFFIX를 우선 사용하고 DOMAIN-KEYWORD는 확인된 보조 규칙으로 활용하세요.

DOMAIN-SUFFIX를 작성했는데 왜 웹사이트 전체가 로드되지 않나요?

먼저 실패한 리소스의 호스트 이름을 기록하세요. 로그인, 이미지 또는 미디어가 다른 도메인에서 제공된다면 DOMAIN 또는 DOMAIN-SUFFIX를 각각 추가해야 합니다. 도메인 규칙은 경로를 매칭하지 않으므로 URL 경로를 규칙에 입력하지 마세요.

왜 모든 웹사이트가 프록시 정책으로 연결되나요?

먼저 Home에서 Global Routing이 실수로 Proxy로 설정되지 않았는지 확인한 다음 Rule 마지막 줄이 FINAL,DIRECT인지 확인하세요. FINAL이 PROXY를 사용하면 앞에서 매칭되지 않은 모든 요청이 프록시 정책으로 전달됩니다.

규칙을 수정했는데 왜 아무런 변화가 없나요?

Config로 이동해 현재 선택된 설정을 편집했는지 확인한 뒤 Home으로 돌아가 Config 상태를 선택하고 연결을 다시 설정하세요. 또한 대상 규칙이 FINAL보다 앞에 있는지, 앞쪽에 더 넓은 규칙이 먼저 매칭되는지 확인해야 합니다.

구독 업데이트 후 수동 규칙이 사라지면 어떻게 하나요?

구독 내용이 업데이트될 때 해당 설정이 다시 작성될 수 있습니다. 수정하기 전에 로컬 복사본을 보관하고 사용자 지정 Rule을 기록하세요. 업데이트 후 복사본과 비교해 필요한 항목을 복원합니다. 구독의 유효성과 내용은 사용자가 이용 중인 서비스 제공자에게 확인해야 합니다.

80 및 443 포트에 각각 도메인 규칙을 작성해야 하나요?

필요하지 않습니다. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD는 호스트 이름을 매칭하며 포트별로 나누지 않습니다. 같은 도메인이 80, 443 또는 다른 포트를 사용해도 동일한 도메인 규칙이 정책을 결정합니다.

안정적인 설정을 위한 확인 순서

먼저 Home → Global Routing → Config인지 확인하세요.
그다음 Config에서 선택된 파일이 방금 편집한 파일인지 확인하세요.
정확한 DOMAIN을 범위가 넓은 DOMAIN-SUFFIX보다 앞에 배치하세요.
DOMAIN-KEYWORD는 근거가 확실한 최소 범위로 제한하세요.
IP 규칙이 필요할 때만 IP-CIDR 또는 GEOIP를 추가하세요.
항상 FINAL,DIRECT를 마지막 줄에 남겨 두세요.
수정 후 대상 웹사이트와 규칙에 포함하지 않은 일반 웹사이트를 각각 테스트하세요.