Shadowrocket 사용자 규칙 설정법: 규칙 매칭 순서와 FINAL 기본 처리

이 글의 핵심

서비스 제공업체와 사용할 수 있는 연결을 이미 확보했고 Shadowrocket 설정을 편집하려는 사용자를 위한 안내입니다. 먼저 Global Routing이 Config로 설정되어 있는지 확인한 뒤, 구체적인 예외를 먼저 두고 넓은 범위의 규칙을 뒤에 배치하며 FINAL은 마지막에 둡니다. 최소 설정 예시와 규칙 충돌 사례, 확인 절차를 통해 규칙 미일치와 규칙 적용 후 연결 실패를 구분합니다.

1. 먼저 Config 확인: 규칙 목록이 트래픽을 분기하는 조건

사용자 규칙은 연결을 켜거나 연결에 필요한 서버 정보를 제공하는 기능이 아닙니다. 설정을 시작하기 전에 서비스 제공업체에서 구독 정보나 연결 매개변수를 받아 두고, 사용할 연결이 정상적으로 작동하는지 확인하세요. 이 안내에서는 iPhone/iPad의 Home, Config, Settings 화면 이름을 기준으로 설명합니다. 다른 플랫폼에서는 해당 플랫폼의 라우팅 및 설정 화면에서 같은 항목을 확인하세요.

Home에서 Global Routing을 확인하세요. Config를 사용 중이라면 현재 적용된 설정의 규칙이 트래픽 분기 문제를 확인할 때 기준이 됩니다. Proxy와 Direct는 전체 라우팅 모드이며, 개별 규칙 끝에 지정하는 PROXY·DIRECT 정책과 혼동하면 안 됩니다. Scene은 현재 장면의 설정에 따라 동작하므로 Config와 같은 의미로 볼 수 없습니다.

요청이 터널로 들어옴 대상 정보 확인 위에서 아래로 규칙 매칭 일치한 정책 실행 연결하거나 차단

이 과정은 설정에 따라 트래픽이 분기되는 요청을 설명하며, 모든 시스템 요청이 반드시 똑같은 경로로 처리된다는 뜻은 아닙니다. 확인할 때는 특정 대상 도메인과 새 연결을 기준으로 테스트하세요. 상태 표시줄에 VPN 표시가 나타난 것만으로 규칙이 적용됐다고 판단하지 마세요.

Home: 연결 상태와 선택된 연결, 현재 Global Routing 모드를 확인합니다.
Config: 실제로 사용 중인 설정 파일을 확인합니다. 선택되지 않은 파일을 편집해도 현재 트래픽 분기에는 반영되지 않습니다.
Settings → On Demand: 조건에 따른 자동 연결 동작을 설정합니다. DOMAIN-SUFFIX와 FINAL 중 어느 규칙이 먼저 적용되는지는 결정하지 않습니다.

2. 규칙 문법: 매칭 조건과 실행 정책 구분하기

일반적인 규칙은 ‘유형, 매칭 값, 정책’으로 구성되며 각 항목은 영문 쉼표로 구분합니다. 유형은 무엇을 검사할지, 매칭 값은 범위를 어디까지로 할지, 정책은 일치한 뒤 어떤 동작을 할지 지정합니다. FINAL에는 매칭 값이 필요하지 않으므로 보통 필드가 두 개뿐입니다. 쉼표에 전각 기호를 쓰거나 정책 이름 뒤에 설명을 이어 붙이지 마세요.

필드 3개

일반 조건 규칙: 유형, 매칭 값, 정책

필드 2개

기본 처리 규칙: FINAL, 정책

정책 3가지

이 글에서는 PROXY, DIRECT, REJECT를 사용합니다

규칙 유형	예시	검사 범위
`DOMAIN`	`DOMAIN,login.example.com,PROXY`	login.example.com과 정확히 일치합니다. 하위 도메인은 자동으로 포함되지 않습니다.
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	example.com 자체와 www.example.com 같은 하위 도메인에 일치합니다.
`IP-CIDR`	`IP-CIDR,192.168.50.0/24,DIRECT`	대상 IPv4 주소가 지정된 네트워크 대역에 포함되는지 확인합니다. /24는 포트 번호가 아닙니다.
`GEOIP`	`GEOIP,CN,DIRECT`	대상 IP를 로컬 GeoIP 데이터의 지역 분류와 비교합니다.
`FINAL`	`FINAL,PROXY`	앞선 규칙에 일치하지 않은 요청을 처리합니다.

도메인 규칙의 매칭 값에는 https://, 경로, 쿼리 매개변수, 포트를 넣지 않습니다. 예를 들어 대상 URL이 https://login.example.com:443/account이라면 DOMAIN 값은 login.example.com으로 작성합니다. IP-CIDR에는 URL이 아닌 주소와 마스크 길이를 사용합니다. GEOIP는 IP 분류를 기준으로 판단하며, 웹페이지 언어·도메인 접미사·서비스 운영업체의 소재지를 기준으로 하지 않습니다.

3. PROXY·DIRECT·REJECT의 동작 차이

정책은 규칙의 끝에 지정합니다. 규칙이 일치했다는 것은 처리 방식이 선택됐다는 뜻일 뿐, 대상에 반드시 연결된다는 보장은 아닙니다. PROXY는 선택된 연결과 원격 네트워크에, DIRECT는 로컬 네트워크에 따라 달라집니다. REJECT는 연결을 의도적으로 차단합니다. 아래 두 설정 카드는 규칙을 설명하기 위한 예시이며, 함께 가져와야 하는 완성된 설정은 아닙니다.

도메인별 예외 설정

DOMAIN: login.example.com,PROXY
DOMAIN-SUFFIX: ads.example.com,REJECT
DOMAIN-SUFFIX: example.com,DIRECT

정확한 예외와 하위 도메인 차단 규칙은 전체 도메인 범위 규칙보다 앞에 두어 넓은 조건에 먼저 적용되지 않도록 합니다.

주소 범위별 설정

IP-CIDR: 192.168.50.0/24,DIRECT
GEOIP: CN,DIRECT
FINAL: PROXY

해당 주소 범위를 실제로 직접 연결해야 하는 경우에만 규칙을 유지하고, 나머지 요청은 FINAL로 처리합니다.

PROXY: 일치한 연결을 프록시를 통해 처리합니다. 서버 주소를 뜻하거나 사용할 수 있는 연결을 자동으로 만드는 것은 아닙니다. Home에서 선택한 연결이나 설정에 지정된 정책 대상을 확인해야 합니다.
DIRECT: 프록시 서버를 거치지 않고 대상에 직접 연결합니다. 모든 VPN 처리를 우회한다는 뜻도, 현재 네트워크에서 대상에 반드시 접속할 수 있다는 뜻도 아닙니다.
REJECT: 규칙에 일치한 연결을 거부합니다. 규칙으로 식별할 수 있는 대상 정보를 기준으로 동작하며 웹페이지 콘텐츠 필터는 아닙니다. 같은 HTTPS 연결에서 페이지 일부 콘텐츠만 골라 차단할 수는 없습니다.

하나의 도메인이 로그인과 다른 콘텐츠 제공에 모두 사용된다면 REJECT를 넓게 적용해 로그인까지 차단할 수 있습니다. 먼저 실제로 처리해야 할 대상을 찾고 매칭 범위를 좁히세요. 페이지에서 콘텐츠 일부가 사라졌다는 이유만으로 규칙이 올바르게 작동한다고 판단하지 말고, 모든 실패를 프록시 연결 문제로 돌리지도 마세요.

4. 매칭 순서: 더 구체적인 규칙이 자동으로 우선하지 않습니다

규칙은 첫 번째 줄부터 아래로 확인합니다. 먼저 일치한 규칙이 해당 요청의 정책을 결정하고, 뒤의 규칙은 그 요청에 적용되지 않습니다. DOMAIN이 DOMAIN-SUFFIX보다 구체적이어도 행 순서보다 우선하지는 않습니다. 마찬가지로 REJECT에도 앞선 DIRECT 규칙을 뛰어넘는 특별한 우선순위는 없습니다.

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

이 순서에서는 login.example.com이 example.com의 하위 도메인이므로 첫 번째 줄에 먼저 일치합니다. 두 번째 줄이 더 구체적이어도 이미 적용 기회를 놓친 상태입니다. 로그인 도메인은 PROXY로, 다른 하위 도메인은 DIRECT로 연결하려면 앞의 두 줄 순서를 바꾸세요.

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

요점: 예외를 해당 범위 규칙보다 앞에 배치

규칙을 추가한 뒤에는 위쪽에 같은 대상을 포함하는 조건이 있는지 먼저 확인하세요. 있다면 같은 규칙을 반복해서 추가하는 대신 위치를 바꾸거나 앞선 규칙의 범위를 좁히세요.

‘구체적인 규칙을 앞에 둔다’는 규칙을 정리하는 실용적인 방법이지만, 실제 적용 원칙은 먼저 일치한 규칙이 우선한다는 것입니다. 예를 들어 특정 IP를 반드시 PROXY로 연결해야 한다면 해당 IP를 포함할 수 있는 GEOIP 직접 연결 규칙보다 앞에 둡니다. 도메인 규칙이 주소 규칙보다 항상 우선한다거나 특정 정책이 본질적으로 더 강하다고 가정하지 마세요.

5. FINAL을 마지막에 두어야 하는 이유

FINAL은 특정 도메인이나 주소를 확인하는 대신 앞선 규칙에 일치하지 않은 요청을 처리합니다. 목록 중간에 두면 그 위치에서 나머지 규칙 검사를 끝내는 것과 같습니다. 아래에 문법적으로 올바른 DOMAIN, IP-CIDR, GEOIP 규칙이 있더라도 FINAL이 이미 처리한 요청에는 적용되지 않습니다.

[Rule]
DOMAIN,login.example.com,PROXY
DOMAIN-SUFFIX,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.168.50.0/24,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

순서를 이해하기 위한 최소 예시이며 모든 네트워크에 적합한 기본 설정은 아닙니다. example.com과 그 하위 도메인은 예시일 뿐입니다. 로컬 네트워크 대역도 실제로 필요한 범위로 바꿔야 합니다. 기존 설정에 [Rule]이 있다면 같은 이름의 섹션을 다시 붙여 넣지 말고 기존 섹션에서 규칙을 정리하세요.

login.example.com은 첫 번째 줄의 PROXY에 일치하므로 뒤에 있는 도메인 접미사 규칙까지 확인하지 않습니다.
ads.example.com은 두 번째 줄의 REJECT에 일치합니다. 해당 접미사 범위에는 하위 도메인도 포함됩니다.
요청에서 매칭에 사용할 대상 도메인 정보를 확인할 수 있다면 www.example.com은 세 번째 줄의 DIRECT에 일치합니다.
대상 주소 192.168.50.10은 예시의 /24 네트워크 대역에 포함되므로 앞선 규칙에 일치하지 않을 때 네 번째 줄에서 처리됩니다.
나머지 요청은 GEOIP 규칙을 계속 확인하며, 여기에 일치하지 않을 때 FINAL에 지정된 PROXY가 적용됩니다.

FINAL의 정책은 직접 선택해야 합니다.FINAL,PROXY는 분류되지 않은 요청을 프록시로 보내고, FINAL,DIRECT는 직접 연결합니다. 네트워크 요구와 관계없이 항상 옳은 선택은 없습니다. 실제 설정에서는 FINAL을 하나만 명확하게 두고 마지막 유효 규칙으로 배치하세요.

IP 계열 규칙에는 도메인 해석이 관여할 수 있으며, 실제 대상 IP·DNS 응답·GeoIP 데이터에 따라 매칭 결과가 달라질 수 있습니다. IP 주소로 직접 연결하면 DOMAIN 규칙에 사용할 도메인 정보가 없을 수도 있습니다. 따라서 도메인으로 접속하는 테스트와 IP로 직접 접속하는 테스트를 완전히 같은 것으로 보아서는 안 됩니다.

6. 저장 및 확인: 미적용 문제를 먼저 해결한 뒤 연결 실패 점검

편집하기 전에 현재 정상적으로 작동하는 설정을 복사해 저장하세요. 확인할 때는 한 번에 대상 하나 또는 순서 하나만 변경하고 변경 전후 결과를 기록합니다. DNS와 라우팅 모드, 규칙 목록을 동시에 바꾸면 어떤 변경이 영향을 줬는지 판단하기 어렵습니다.

편집 중인 파일 확인: Config로 이동해 현재 사용하는 설정을 확인한 뒤 해당 파일의 편집 화면을 여세요. 원격 설정과 로컬 복사본은 구분해서 확인해야 합니다.
규칙 섹션 확인: [Rule] 안에서 수정하고 영문 쉼표를 유지하세요. 정책 이름의 철자를 확인한 뒤 FINAL을 마지막으로 옮깁니다.
저장 후 적용: 편집을 마치면 저장하고 해당 설정이 계속 현재 사용 중인지 확인하세요. Home으로 돌아가 Global Routing이 Config인지 확인합니다.
새 연결 생성: 저장한 뒤 연결을 다시 설정하고 테스트 페이지나 앱도 새로 여세요. 기존의 장시간 연결 동작을 새 규칙의 결과로 오해하지 않도록 합니다.
기록 확인: 요청 또는 연결 기록에서 테스트 대상을 찾아 매칭된 규칙과 정책, 대상 주소 정보를 확인합니다. 먼저 예상한 규칙에 일치했는지 확인한 다음 연결 오류를 점검하세요.
문제 범위 좁히기: PROXY에 일치했는데도 시간 초과가 발생한다면 선택한 연결과 서비스 제공업체 상태를 확인하세요. REJECT에 일치한 뒤 연결이 실패했다면 해당 정책에 따른 정상적인 동작입니다.

구독 업데이트와 설정 파일 업데이트는 구분해야 합니다. 연결 구독은 보통 서비스 제공업체가 제공한 연결 정보를 새로 고치는 기능이며, 현재 [Rule]을 수정하는 것은 아닙니다. 원격 설정을 업데이트하면 파일 내용이 교체될 수 있습니다. 장기간 유지할 사용자 규칙은 관리할 설정 파일에 명확히 저장하고 업데이트 후 다시 확인하세요.

한 번 열렸다는 이유만으로 트래픽 분기가 올바르다고 판단하지 마세요. 같은 페이지도 기본 도메인과 이미지 도메인, API 도메인에 연결하면서 각각 다른 규칙에 일치할 수 있습니다. 관련 요청을 하나씩 확인하세요. 점검할 때 인증 정보가 포함된 구독 링크나 전체 설정을 공개하지 마세요.

7. 규칙이 적용되지 않을 때 자주 묻는 질문

REJECT를 추가했는데도 대상에 접속할 수 있는 이유는 무엇인가요?

먼저 위쪽에 같은 대상을 포함하는 DIRECT, PROXY 또는 FINAL 규칙이 있는지 확인하세요. 이어서 Global Routing이 Config인지, 편집한 파일이 현재 적용 중인 파일인지 확인합니다. 그런 다음 새 연결을 만들고 실제 요청 도메인을 확인하세요. 페이지에서 사용하는 API 도메인은 주소 표시줄의 도메인과 다를 수 있습니다.

FINAL 뒤에 규칙을 더 작성해도 되나요?

파일에 뒤쪽 내용을 작성할 수는 있지만 FINAL이 앞선 규칙에 일치하지 않은 요청을 처리한 뒤에는 일반 규칙이 해당 요청에 적용되지 않습니다. 필요한 규칙을 FINAL 위로 옮기고, 관리 중 혼동하지 않도록 불필요한 FINAL은 정리하세요.

On Demand를 켰는데도 도메인별로 트래픽이 분기되지 않는 이유는 무엇인가요?

Settings → On Demand는 자동 연결 조건을 처리하며 Global Routing 선택을 바꾸지 않습니다. Home으로 돌아가 Config 모드인지 확인한 다음 Config에서 사용 중인 파일을 확인하세요. 자동 연결 설정을 라우팅 설정 대신 사용하지 마세요.

구독 업데이트가 완료됐는데 방금 추가한 규칙이 바뀌지 않은 이유는 무엇인가요?

먼저 업데이트한 항목이 연결 구독인지 원격 설정인지 확인하세요. 연결 구독 업데이트만으로 규칙이 갱신됐다고 볼 수 없으며, 원격 설정 업데이트는 로컬 변경 사항을 덮어쓸 수 있습니다. 현재 설정에서 실제 [Rule] 내용을 확인한 뒤 특정 대상을 지정해 새 연결로 테스트하세요.

같은 도메인이 어제는 직접 연결됐는데 오늘은 다른 규칙에 일치하는 이유는 무엇인가요?

먼저 매칭 기록과 실제 대상 IP, 현재 설정을 비교하세요. DNS 응답 주소가 바뀌면 IP-CIDR이나 GEOIP 판단 결과가 달라질 수 있고, 원격 설정 업데이트로 규칙 순서가 바뀔 수도 있습니다. 도메인 기준으로 일관되게 처리하려면 해당 DOMAIN 또는 DOMAIN-SUFFIX 규칙을 관련 주소 규칙보다 앞에 배치하세요.

Shadowrocket 다운로드 및 설정 계속하기

iPhone/iPad 버전은 App Store에서 $2.99에 한 번 구매하면 됩니다. Mac(Apple 실리콘/Intel), Windows, Android, Linux 버전은 무료입니다. iPhone/iPad의 시스템 요구 사항은 App Store 페이지를 확인하세요. 다운로드 페이지에서 플랫폼을 선택한 다음 안내에 따라 보유한 설정과 구독을 가져오면 됩니다.

클라이언트 앱 구매와 연결 서비스 요금제는 별개입니다. 연결에 필요한 구독은 서비스 제공업체에서 받으세요. 이 사이트에서는 클라이언트 다운로드와 설정 방법을 안내하며, 연결 노드나 구독을 제공·판매·추천하지 않습니다.

다운로드 페이지 설정 가이드