Shadowrocket
규칙 및 설정 참고서

01 설정 파일 구조와 적용 범위

Shadowrocket에서 연결 정보와 분할 규칙 설정은 서로 다른 역할을 합니다. 연결 정보는 사용자가 보유한 서버에 연결하는 방법을 지정하며, 보통 프로토콜, 주소, 포트, 인증 항목을 포함합니다. 분할 규칙 설정은 각 요청에 적용할 정책을 지정합니다. Subscribe를 가져와도 규칙 파일이 선택된 것은 아니며, .conf 파일을 가져와도 서버가 생기는 것은 아닙니다. 설정을 관리하기 전에 Home의 SERVER 목록과 Config에서 현재 사용하는 파일을 각각 확인해 두세요. 두 메뉴를 같은 데이터로 혼동하지 않는 것이 중요합니다.

먼저 네 가지 섹션을 확인하세요

설정 파일은 대괄호로 표시한 섹션 이름에 따라 적용 범위를 나눕니다. [General]에는 전역 매개변수, [Rule]에는 순서에 따라 적용되는 매칭 규칙, [Host]에는 호스트 이름 매핑, [URL Rewrite]에는 URL 재작성 표현식을 작성합니다. 섹션 이름은 단순한 제목이 아니라 뒤따르는 내용의 용도를 파서에 알려주는 표식입니다. 같은 문장도 어느 섹션에 놓이느냐에 따라 다르게 해석되거나 유효하지 않은 매개변수가 될 수 있으므로, 일부 내용을 복사할 때는 해당 섹션도 함께 확인해야 합니다.

[General]
bypass-system = true

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

[Host]
example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

이 예시는 섹션의 경계를 보여 주기 위한 것으로, 그대로 적용할 수 있는 완성된 설정이 아닙니다. example.com과 문서용 주소는 문법 설명에 사용한 값입니다. 실제 요청 결과는 사용자가 보유한 서버, 현재 정책, 네트워크 환경에 따라 달라집니다. 특히 [Host]와 [URL Rewrite]는 이름 해석이나 요청 대상을 바꿀 수 있으므로, 기본 연결 상태를 확인할 때는 두 섹션의 세부 항목을 먼저 제외하고 연결이 안정된 뒤 하나씩 추가하세요.

파일이 있다고 규칙이 적용되는 것은 아닙니다

Config에 여러 파일을 저장할 수 있지만, 문제를 확인할 때는 실제로 사용 중인 파일이 무엇인지 파악해야 합니다. 편집 내용을 저장한 뒤 파일 목록으로 돌아가 선택 상태를 확인하고, Home에서 Global Routing도 확인하세요. 규칙 분할을 확인할 때는 Config 모드가 일반적인 출발점입니다. Proxy와 Direct는 전역 라우팅을 비교할 때 사용하는 서로 다른 모드입니다. 파일이 저장되었다는 이유만으로 모든 요청이 해당 파일의 규칙을 차례로 거친다고 단정할 수는 없습니다.

편집하기 전에 정상 작동하는 파일을 복사해 두고, 작업용 사본에는 알아보기 쉬운 이름을 붙이세요. 이름에는 ‘도메인 규칙 테스트’처럼 용도만 적고 서버 비밀번호, 구독 토큰, 개인 계정 정보는 넣지 마세요. 원격 파일과 로컬 사본을 함께 관리한다면 현재 편집 중인 대상을 확인해야 합니다. 원격 업데이트가 같은 파일의 로컬 수정 내용을 덮어쓸 수 있으므로 중요한 사용자 설정은 기억에 의존하지 말고 별도로 기록하세요.

변경 사항을 검증 가능한 작은 단위로 나누세요

한 번에 한 가지 설정 요소만 변경하는 것이 좋습니다. 특정 도메인의 라우팅을 바꾸려면 해당 [Rule] 행만 수정하고 DNS, Host, 서버 인증 항목은 동시에 변경하지 마세요. 그래야 테스트 결과가 달라졌을 때 원인을 방금 수정한 규칙으로 좁힐 수 있습니다. 여러 항목을 한꺼번에 바꾸면 결과가 나아져도 무엇이 효과가 있었는지 알기 어려워지고, 이후 설정을 업데이트할 때 같은 근거를 다시 찾기 어렵습니다.

파일을 읽을 때는 먼저 섹션 이름을 확인하고, 다음으로 FINAL을 찾은 뒤 기본 처리 규칙 앞에 범위가 넓은 규칙이 있는지 살펴보세요. 처음부터 한 줄씩 읽는 것보다 전체 구성을 파악하기 쉽습니다. 이해하지 못한 매개변수는 일단 기존 값으로 두고, 트래픽 처리 방식, 이름 해석, 요청 매칭 중 무엇을 제어하는지 확인하세요. 필드 이름만 보고 값을 추측하거나 다른 설정 형식에서 비슷해 보이는 필드를 .conf에 그대로 옮기지 마세요.

02 General: 전역 매개변수와 DNS 범위

[General]의 매개변수는 설정 전체의 실행 환경에 영향을 주며, 특정 도메인 하나만을 판단하는 항목은 아닙니다. 규칙 문법은 맞는데 실제 동작이 예상과 다르다면 정책뿐 아니라 전역 설정이 트래픽을 규칙 시스템에 전달하는 방식도 확인해야 합니다. 특히 ‘시스템 트래픽을 어떻게 처리하는가’, ‘도메인에서 주소를 어떻게 얻는가’, ‘최종 연결이 어떤 경로를 사용하는가’를 구분하세요. 서로 관련은 있지만 같은 기능을 켜고 끄는 설정은 아닙니다.

bypass-system과 skip-proxy

bypass-system = true는 특정 시스템 트래픽을 해당 방식으로 프록시 처리에서 제외하는 데 사용합니다. [Rule]의 모든 DIRECT 항목을 활성화한다는 뜻이 아니며, 기기 전체가 직결된다는 의미도 아닙니다. 특정 트래픽이 규칙 매칭에 참여하는지 판단하려면 이 매개변수의 참·거짓 값만 볼 것이 아니라 실제 요청 기록과 현재 트래픽 처리 조건을 함께 확인해야 합니다.

[General]
bypass-system = true
skip-proxy = 127.0.0.1, 192.168.0.0/16
dns-server = system

skip-proxy는 해당 프록시 처리를 건너뛸 주소 범위를 지정합니다. 예시에는 루프백 주소와 흔히 쓰이는 사설 네트워크 대역 하나만 포함되어 있으며, 모든 가정용·사무실 네트워크를 포괄하지는 않습니다. 라우터, 프린터, 로컬 네트워크 서비스가 다른 주소 대역에 있다면 기기의 실제 주소를 기준으로 판단하세요. 사설 주소 전체를 한꺼번에 추가하면 관리된 경로를 통해 접근해야 하는 내부 서비스의 경로가 바뀔 수 있으므로, 먼저 기기가 연결된 네트워크를 확인해야 합니다.

여기서 말하는 우회와 [Rule]의 DIRECT는 단순히 같은 기능을 반복하는 것이 아닙니다. 전자는 트래픽이 이후 처리 단계에 진입하는지에 영향을 줄 수 있고, 후자는 규칙 단계에서 직결 정책을 선택합니다. 로컬 네트워크 규칙에 요청 기록이 남지 않는다면 먼저 전역 우회가 적용되었는지 확인하세요. 이 경우 규칙의 위치를 바꾸는 것만으로는 앞선 단계에서 이미 내려진 처리 결정을 바꾸기 어렵습니다.

DNS 결과와 라우팅 정책을 따로 확인하세요

dns-server = system은 시스템의 이름 해석 경로를 사용한다는 뜻입니다. 이해하기 쉬운 기본 설정을 구성할 때 유용하지만, 모든 네트워크에서 필요한 이름을 해석할 수 있다는 의미는 아닙니다. DNS는 호스트 이름을 주소로 변환하고, PROXY 또는 DIRECT는 연결 경로를 결정합니다. 도메인 규칙이 PROXY에 매칭되었다고 해서 이름 해석 경로까지 예상대로라는 뜻은 아닙니다. 이름 해석에 성공해도 대상 포트에 연결할 수 있다는 보장은 없습니다.

다른 DNS 서버를 설정하려면 용도와 권한, 연결 가능 여부를 분명히 알고 있는 주소만 사용하세요. 특정 테스트를 통과시키려고 여러 DNS 경로를 연달아 추가하지 마세요. 해석 결과와 캐시, 네트워크 전환이 뒤섞이면 문제를 재현하기 어려워집니다. 먼저 시스템 DNS의 결과를 기록하고 라우팅 규칙을 그대로 둔 채 다른 설정과 비교해야 문제가 실제로 DNS 단계에 있는지 판단할 수 있습니다.

주소 규칙은 이름 해석을 유발할 수 있습니다

도메인 조건은 대개 요청의 호스트 이름으로 바로 판단할 수 있지만, GEOIP 또는 IP-CIDR 조건에는 대상 주소 정보가 필요합니다. 요청에 도메인 이름만 있는 경우 주소 규칙을 판단하려면 이름을 해석해야 할 수 있습니다. 규칙 행에 적용되는 no-resolve 옵션이 있으면 해당 규칙만을 위해 도메인을 추가로 해석하지 말라는 뜻입니다. 연결 과정 전체에서 DNS가 더는 필요 없다는 의미는 아닙니다. 이 차이는 도메인 요청이 주소 기반 규칙에 매칭될 수 있는지에 직접 영향을 줍니다.

이미 주소 정보가 있는 요청과 아직 해석되지 않은 도메인 요청은 같은 서비스에 접속하더라도 매칭 과정이 다를 수 있습니다. 규칙을 관리할 때는 추가 해석을 줄이기 위해 no-resolve를 적용하는 등 그 목적을 기록하세요. 모든 IP 규칙에 붙이는 장식처럼 사용해서는 안 됩니다. 최종 주소에 따라 정책을 결정하려면 필요한 해석 조건을 받아들이고 실제 동작을 확인해야 합니다.

네트워크 변경 후 다시 확인할 순서

iPad 또는 iPhone을 다른 Wi-Fi로 전환했다면 먼저 기본 네트워크 연결을 확인한 다음 DNS 결과와 로컬 네트워크 접근 가능 여부를 다시 살펴보세요. 같은 사설 주소가 네트워크마다 다른 기기를 가리킬 수 있으므로, 이전에 작동했던 결과가 계속 유효하다고 볼 수는 없습니다. On Demand는 연결 시작 조건을 제어할 뿐 DNS나 [Rule] 설정 확인을 대신하지 않습니다. 연결이 자동으로 시작된 뒤에도 새 요청에 실제로 어떤 정책이 적용되는지 확인해야 합니다.

전역 매개변수는 개수와 용도를 맞춰 관리하세요. 특정 도메인 규칙 하나로 해결할 수 있다면 모든 DNS 경로를 먼저 바꿀 필요가 없습니다. 사설 주소 대역 하나를 수정하면 되는 문제라면 전체 우회 목록을 넓힐 필요도 없습니다. 저장하기 전에 영문 쉼표, 등호, 주소 접두사를 확인하고, 저장한 뒤에는 새 요청으로 다시 테스트해 이전 연결이나 캐시가 변경 효과를 가리지 않게 하세요.

03 Rule: 도메인 조건과 매칭 범위

[Rule]의 일반적인 행은 ‘규칙 유형, 매칭 값, 대상 정책’으로 구성됩니다. 필드는 영문 쉼표로 구분하며, 도메인 칸에는 프로토콜, 경로, 포트를 넣지 않습니다. example.com을 기준으로 라우팅하려면 호스트 이름만 입력하세요. 전체 웹 주소를 넣어서는 안 됩니다. 도메인 규칙은 요청 대상의 이름을 처리하며 페이지 제목이나 본문, 주소 표시줄에 있는 모든 문자를 검사하지 않습니다.

DOMAIN: 호스트 이름 전체에 적용

DOMAIN,example.com,DIRECT는 정확히 example.com이라는 이름에만 매칭됩니다. 같은 문자열이 들어 있다는 이유로 다른 이름까지 적용되지 않으며 api.example.com도 자동으로 포함하지 않습니다. 특정 API 또는 로그인 호스트에 별도의 정책을 지정하려면 DOMAIN의 범위가 명확하므로, 일반적으로 더 넓은 도메인 접미사 규칙보다 앞에 배치하는 것이 좋습니다.

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

이 규칙에서는 api.example.com이 첫 번째 행에 먼저 매칭되어 DIRECT를 사용합니다. example.com과 접미사 조건에 해당하는 다른 하위 도메인은 두 번째 행에서 PROXY를 사용합니다. 앞뒤 순서를 바꾸면 범위가 더 넓은 접미사 조건이 먼저 적용되어 뒤에 있는 정확한 예외가 무시됩니다. 규칙 시스템이 더 정확한 DOMAIN을 자동으로 앞에 배치하지 않으므로, 작성 순서는 실제 판단 순서를 결정하는 중요한 요소입니다.

DOMAIN-SUFFIX: 도메인과 하위 도메인에 적용

DOMAIN-SUFFIX,example.com,PROXY는 example.com과 그 하위 도메인에 적용됩니다. 예를 들면 a.example.com과 b.a.example.com이 해당합니다. 접미사는 도메인 레이블 경계를 기준으로 판단하므로 notexample.com은 같은 도메인으로 보지 않습니다. 별표를 붙여 와일드카드 표현식으로 써야 한다고 오해하기 쉽지만, 이 규칙 유형에는 도메인 접미사를 그대로 입력하면 됩니다. 정규식으로 바꿀 필요가 없습니다.

접미사 규칙은 도메인 체계 전체에 같은 정책을 적용할 때 유용하지만, 한 웹사이트의 모든 기능이 같은 접미사를 사용하는 것은 아닙니다. 로그인, 이미지, 파일, 통계 요청이 서로 다른 독립 도메인을 사용할 수 있으므로 ‘페이지는 열리지만 첨부 파일이 불러와지지 않음’이 접미사 규칙이 작동하지 않는다는 뜻은 아닙니다. 실패한 리소스의 실제 호스트 이름을 확인하고 별도 규칙이 필요한지 판단하세요.

DOMAIN-KEYWORD: 이름에 포함된 문자열로 판단

DOMAIN-KEYWORD,example,DIRECT는 example 문자열이 포함된 도메인 요청에 매칭됩니다. 단일 접미사보다 범위를 직관적으로 제어하기 어렵습니다. 서로 다른 조직의 호스트 이름까지 포함할 수 있고 관련 리소스는 이름이 전혀 달라 누락될 수도 있습니다. 이런 넓은 조건이 꼭 필요한 경우가 아니라면 정확한 도메인이나 접미사 조건을 우선 사용해 나중에 설명하기 어려운 오매칭을 줄이세요.

요청 기록에서 조건 찾기

규칙을 추가하기 전에 실제 요청의 호스트 이름을 확인하세요. 페이지 이름만으로 추측해서는 안 됩니다. 하나의 앱이 여러 백엔드 서비스에 연결될 수 있고 주소 표시줄의 도메인은 진입점에 불과할 수도 있습니다. 재현 가능한 실패 동작을 한 번 수행하고 같은 시간대의 대상 이름을 확인한 뒤 DOMAIN과 DOMAIN-SUFFIX 중 적절한 유형을 선택하세요. 기록에 대상 주소만 표시된다면 근거 없이 특정 도메인 조건을 만들어서는 안 됩니다.

국제화 도메인을 매칭할 때는 화면에 보이는 이름과 네트워크에서 사용하는 인코딩 형식이 다를 수 있습니다. 실제 매칭에 사용된 호스트 이름은 클라이언트 기록을 기준으로 확인하세요. 주소를 복사할 때는 끝에 붙은 경로와 쿼리 매개변수, 불필요한 공백도 제거해야 합니다. 도메인 규칙은 URL Rewrite가 아니므로 DOMAIN 필드에 경로를 넣어도 경로 매칭이 되지 않습니다.

여러 도메인 규칙을 관리할 때는 ‘업무 목적’과 ‘문법상 범위’를 따로 기록하세요. 예를 들어 특정 테스트 서비스의 경로를 지정하는 것이 목적이라면 실제 조건에는 구체적인 호스트를 적어야 합니다. ‘업무 사이트’ 같은 설명만 남기면 몇 달 뒤 넓은 키워드를 사용한 이유를 알기 어렵습니다. 매칭 근거와 선택 이유를 기록하면 겹치는 항목을 계속 추가하는 것보다 장기적으로 관리하기 쉽습니다.

04 IP, GEOIP 및 USER-AGENT 조건

도메인 조건은 이름을 기준으로 하고 주소 조건은 연결 대상의 IP를 기준으로 합니다. 서로 다른 대상을 설명하므로 특정 도메인이 항상 같은 주소를 사용하거나 하나의 주소가 도메인 하나만 제공한다고 가정할 수 없습니다. 콘텐츠 전송, 부하 분산, 네트워크 위치에 따라 해석 결과가 달라질 수 있습니다. 따라서 대상이 실제로 주소 범위로 관리되는 경우에만 IP 규칙을 주된 판단 기준으로 사용하세요.

IP-CIDR: 주소와 접두사 길이 이해하기

IP-CIDR,192.168.0.0/16,DIRECT는 IPv4 주소 대역을 매칭합니다. 슬래시 뒤의 숫자는 네트워크 접두사 길이이며 포트나 주소 개수가 아닙니다. 접두사가 길수록 일반적으로 포함 범위가 좁아집니다. IPv4 주소 하나는 /32로 지정할 수 있습니다. 편집하기 전에 대상이 어느 대역에 속하는지 확인하세요. 주소 앞부분이 비슷하다는 이유만으로 범위를 임의로 넓혀서는 안 됩니다.

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

192.0.2.10과 2001:db8::/32는 문서용 예시이며 연결 가능한 실제 서비스 주소가 아닙니다. IP-CIDR6는 IPv6 주소 조건에 사용합니다. IPv6 주소를 IPv4 규칙에 넣어도 자동으로 변환되지 않습니다. 서비스가 두 주소 유형을 모두 반환하는데 IPv4 규칙만 확인하면 실제 IPv6 연결을 놓칠 수 있습니다. 기록에 표시된 대상 주소의 유형을 확인한 뒤 필요한 규칙을 판단하세요.

로컬 네트워크 규칙과 실제 구성

가정이나 사무실 네트워크에는 사설 주소가 흔히 사용되지만 구체적인 주소는 네트워크 관리 방식에 따라 달라집니다. 프린터에 접근할 수 없다면 실제 주소, 서브넷, 네트워크 격리 설정부터 확인하세요. 기기가 다른 격리 네트워크에 있다면 규칙에서 DIRECT를 선택해도 네트워크 간 경로나 접근 권한이 자동으로 생기지 않습니다. 규칙은 이미 존재하는 경로를 선택할 뿐, 라우터에 없는 연결 경로를 만들어 주지는 않습니다.

no-resolve가 포함된 주소 규칙은 요청에 대상 주소가 이미 있는지 다시 확인하세요. 요청이 여전히 도메인 이름으로 전달된다면 이 옵션 때문에 추가 해석을 하지 않아 주소 조건에 필요한 정보를 얻지 못할 수 있습니다. 이때는 no-resolve를 유지할지, 구체적인 도메인 규칙을 추가할지, 해석을 허용한 동작을 확인할지 목적에 따라 결정하세요. 같은 주소 대역을 여러 규칙에 무작정 복사하지 마세요.

GEOIP: 주소 데이터베이스 분류 기준으로 판단

GEOIP,CN,DIRECT는 대상 IP를 지리 정보 데이터베이스의 분류 결과에 따라 판단합니다. CN은 지역 코드입니다. 웹페이지 언어나 사용자의 위치, 사이트 등록 국가, 콘텐츠 서비스의 대상 지역을 판단하는 규칙이 아닙니다. 중국어 페이지가 다른 지역의 주소를 사용할 수 있고, 글로벌 서비스가 한국 내 배포 주소로 해석될 수도 있습니다. 따라서 GEOIP를 서비스의 정체성을 판별하는 조건으로 사용해서는 안 됩니다.

데이터베이스 분류에는 한계가 있고 결과가 바뀔 수 있으므로, 한 번 매칭된 결과를 영구적인 사실로 간주하지 마세요. 특정 서비스를 안정적으로 처리해야 한다면 구체적인 도메인 예외를 GEOIP보다 앞에 둘 수 있습니다. 나머지 주소를 넓은 범위로 분류해야 할 때 GEOIP를 사용하세요. 분류 결과가 예상과 다르면 대상 IP와 당시 해석 결과를 기록하고 데이터베이스와 규칙 순서를 확인하세요. 서버 프로토콜에 문제가 있다고 바로 단정하지 마세요.

USER-AGENT: 요청 정보가 보이는 범위와 한계

USER-AGENT는 USER-AGENT,ExampleClient*,DIRECT처럼 요청의 User-Agent 정보와 매칭합니다. 여기서는 접두사 패턴을 나타냅니다. 앱에 표시된 이름으로 모든 연결을 식별하는 기능도 아니며 시스템 수준의 앱 식별자도 아닙니다. 클라이언트에서 해당 요청 정보를 확인할 수 있고, 요청에 실제로 필드가 포함되어 있으며, 지원되는 매칭 방식과 일치할 때만 이 조건을 판단에 사용할 수 있습니다.

암호화된 연결의 HTTP 필드는 연결 바깥에서 바로 확인하기 어려우므로 USER-AGENT가 모든 HTTPS 요청에 안정적으로 매칭된다고 가정하지 마세요. 이 규칙을 적용하려고 인증서 신뢰 범위나 복호화 범위를 넓혀서도 안 됩니다. 이 안내의 기본 설정은 그런 작업에 의존하지 않습니다. 명확한 도메인 조건으로 해결할 수 있다면 먼저 확인하기 쉬운 도메인 규칙을 사용하세요.

여러 유형을 조합할 때는 먼저 ‘이 시점에 실제로 확인할 수 있는 정보가 무엇인가’를 따져 보세요. 호스트 이름, IPv4, IPv6, 아니면 읽을 수 있는 요청 필드 중 무엇인지 확인해야 합니다. 규칙에 필요한 정보가 없으면 문법이 맞아도 매칭되지 않을 수 있습니다. 정보의 가시성과 매칭 문법을 따로 점검하면 판단할 수 없는 규칙을 반복해서 수정하는 일을 줄일 수 있습니다.

05 PROXY, DIRECT, REJECT와 규칙 적용 순서

규칙 앞부분은 ‘어떤 요청인지’를 나타내고 마지막 정책은 ‘어떻게 처리할지’를 지정합니다. 이 페이지에서는 기본 정책 키워드로 PROXY, DIRECT, REJECT를 사용하며 영문 표기를 그대로 유지합니다. PROXY는 현재 적용된 프록시 경로를 사용하고, DIRECT는 직접 연결하며, REJECT는 매칭된 요청을 거부합니다. 이들은 지연 시간 등급이 아니며 연결 결과에 따라 자동으로 서로 바뀌지도 않습니다.

정책이 서버 설정을 대신하지는 않습니다

PROXY를 사용하려면 이용 가능한 사용자 서버 정보와 적절한 선택 상태가 필요합니다. 규칙이 PROXY에 매칭되어도 인증, 포트, 프로토콜 매개변수가 잘못되면 연결에 실패할 수 있습니다. DIRECT도 기본 네트워크에서 대상에 접근할 수 있어야 하며, 요청 성공을 보장하지 않습니다. REJECT는 요청을 명시적으로 차단할 때 사용합니다. 중요한 인터페이스에 적용하면 로그인, 동기화, 콘텐츠 로딩에 영향을 줄 수 있으므로 먼저 의존 관계를 확인하세요.

먼저 매칭된 규칙이 정책을 결정합니다

일반적인 [Rule] 순서 매칭에서는 요청을 위에서 아래로 확인하며, 처음 조건에 맞는 규칙이 정책을 결정합니다. 뒤에 있는 규칙은 더 구체적이라는 이유만으로 앞선 결과를 덮어쓰지 않습니다. 우선순위는 규칙 이름이 전문적으로 보이는지, 필드가 긴지보다 파일에서의 위치에 따라 결정됩니다. 규칙을 편집할 때는 구체적인 예외를 넓은 조건보다 앞에 배치해 파일 순서만 따라가도 각 판단을 설명할 수 있게 하세요.

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

api.example.com에는 DIRECT가 적용되고 blocked.example.com은 REJECT됩니다. example.com 접미사 조건에 해당하는 나머지 이름에는 PROXY가 적용됩니다. 이 도메인 조건들이 모두 맞지 않을 때만 사설 네트워크 대역과 GEOIP 규칙을 확인합니다. example.com의 해석 주소가 CN에 속하더라도 앞선 접미사 규칙에서 정책이 이미 결정되었으므로, 뒤에 있는 GEOIP가 이를 DIRECT로 바꾸지 않습니다.

FINAL은 기본 처리 규칙이지 수정용 규칙이 아닙니다

FINAL에는 도메인이나 주소 조건이 없습니다. 일반적인 형식은 FINAL,PROXY 또는 FINAL,DIRECT이며, 기본 처리 위치에 둡니다. FINAL을 앞에 두면 이후의 일반 매칭 규칙은 적용될 기회를 잃습니다. 유지 관리 시에는 의미가 분명한 최종 정책 하나만 남기고 선택 이유를 설명하세요. 서로 다른 방향의 FINAL을 여러 개 남겨 서로 보완되기를 기대해서는 안 됩니다.

두 가지 기본 처리 방식에는 각각 적합한 전제가 있습니다. FINAL,DIRECT는 별도로 지정되지 않은 트래픽을 직결하고, FINAL,PROXY는 프록시 경로로 보냅니다. 어떤 방식을 선택할지는 보유한 서버의 기능, 업무 범위, 장애 영향을 고려해야 하며 한쪽이 항상 옳다고 볼 수 없습니다. 기본 처리 방식을 바꾸기 전에 자주 사용하는 서비스를 테스트하고 기존 경로에서 바뀌는 트래픽을 확인하세요.

라우팅 모드와 규칙 정책을 구분하세요

Global Routing의 Config, Proxy, Direct는 화면에서 선택하는 모드이고, 규칙의 PROXY와 DIRECT는 설정 파일에 쓰는 키워드입니다. 표현은 서로 관련이 있지만 같은 설정 필드로 혼용해서는 안 됩니다. 규칙을 확인할 때는 먼저 Config로 돌아가세요. 비교를 위해 Proxy 또는 Direct를 임시로 선택했다면 다시 되돌렸는지 확인해야 합니다. 그렇지 않으면 다음 테스트에서도 전역 모드가 적용된 상태인데 특정 규칙이 바뀐 것으로 오해할 수 있습니다.

REJECT를 테스트할 때는 적용 범위를 특히 주의하세요. 먼저 직접 확인할 수 있는 테스트 호스트 하나만 사용하고 매칭 기록을 확인한 뒤 접미사 범위를 넓힐지 검토하세요. 넓은 키워드로 많은 요청을 한꺼번에 차단한 다음 ‘페이지가 조금 빨라진 것 같다’는 이유만으로 판단하지 마세요. 중요한 리소스는 나중에 동기화, 결제 확인, 세션 갱신 과정에서 사용될 수 있습니다. 잠시 화면이 정상으로 보여도 의존 관계를 모두 확인한 것은 아닙니다.

06 Host 및 URL Rewrite: 매핑과 재작성

[Host]와 [URL Rewrite]는 모두 접속 결과를 바꿀 수 있지만 처리하는 계층은 다릅니다. Host는 이름에 대응하는 주소를 지정하고, URL Rewrite는 매칭된 URL을 어떻게 바꾸거나 리디렉션할지 다룹니다. [Rule]은 요청에 적용할 정책을 결정합니다. 세 계층을 구분해야 페이지 대상이 바뀌거나 인증서 오류가 발생하거나 분할 조건이 예상대로 적용되지 않는 이유를 파악할 수 있습니다.

Host: 호스트 이름의 해석 결과 지정

example.com = 192.0.2.10은 해당 이름에 주소를 지정한다는 뜻입니다. 방문할 도메인 이름 자체가 숫자 주소로 바뀌는 것은 아니며 HTTP Host, TLS에서 사용하는 서비스 이름, 원격 인증서가 자동으로 변경되지도 않습니다. 서버는 기존 이름을 올바르게 처리해야 합니다. 접근 가능한 IP를 입력해도 상대 서버가 해당 도메인 서비스를 제공하지 않으면 잘못된 페이지가 표시되거나 인증서 이름이 일치하지 않는다는 경고가 나올 수 있습니다.

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.11

예시의 두 매핑은 서로 독립적이며, 기본 도메인 항목이 모든 하위 도메인까지 자동으로 포함한다고 볼 수 없습니다. 여러 이름을 고정해야 한다면 각 항목의 대상과 용도를 확인하세요. 매핑 주소는 직접 관리하고 검증할 수 있는 환경에서 가져와야 합니다. 자주 바뀌는 공용 서비스에 오래된 주소를 고정하면 정상적인 부하 분산과 장애 전환이 작동하지 않을 수 있습니다.

Host는 자체 테스트 환경이나 분명한 이름 해석 수정이 필요할 때 주로 사용하며, 알 수 없는 주소를 시험하는 용도로 적합하지 않습니다. 문제를 확인하기 전에 작업용 사본에서 관련 매핑을 삭제하거나 비활성화하고 시스템 DNS 결과와 비교하세요. 일반적인 이름 해석으로 되돌렸을 때 연결이 정상이라면 매핑 대상의 만료 여부, 포트 개방 상태, 인증서 이름을 확인하세요. 프록시 규칙을 계속 추가하는 것만으로 해결하려 해서는 안 됩니다.

URL Rewrite: 범위를 한정해 대상 변경하기

URL Rewrite는 일반적으로 매칭 패턴, 대체 대상, 처리 방식으로 구성됩니다. 아래 예시는 example.com의 HTTP 주소를 이에 대응하는 HTTPS 주소로 리디렉션하는 문법입니다. 형식 설명을 위한 예시일 뿐입니다. 실제 적용 전에 대상 서버가 HTTPS를 지원하고 리디렉션이 서버의 기존 동작과 충돌하지 않는지 확인하세요. 실제 서비스 주소를 사용할 때는 작업용 사본에서 단일 진입점부터 테스트해야 합니다.

[URL Rewrite]
^http://example\.com/ https://example.com/ 302

매칭 부분에서 점을 \.로 작성하는 이유는 실제 마침표로만 매칭되게 하기 위해서입니다. example.com이라고 그대로 쓰면 정규식에서 점이 임의의 문자로 처리되어 매칭 범위가 넓어질 수 있습니다. 시작 부분의 ^는 문자열의 시작부터 매칭하도록 제한하며 도메인 뒤의 슬래시도 호스트 경계를 구분하는 데 도움이 됩니다. 재작성 규칙은 가능한 한 정확한 대상을 표현해야 하며, 지나치게 넓은 표현식으로 모든 요청을 덮어서는 안 됩니다.

재작성 기능으로 암호화된 내용을 자유롭게 수정할 수 있는 것은 아닙니다

클라이언트가 전체 URL을 읽을 수 있는지는 요청 형태와 확인 가능한 정보에 따라 달라집니다. HTTPS의 경로는 대개 암호화 계층 안에 있으므로 URL Rewrite로 모든 HTTPS 경로를 매칭할 수 있다고 가정해서는 안 됩니다. 연결 단계에서 보이는 대상과 전체 HTTP 요청은 서로 다릅니다. 연결 정책만 바꾸려는 경우 요청 내용 처리 기능을 추가할 필요 없이 [Rule]에서 도메인이나 주소 조건을 사용하세요.

이 페이지의 기본 설정에는 인증서 신뢰 범위 확대나 복호화 범위 확대가 포함되지 않습니다. 요청 정보를 추가로 확인해야 하는 기능은 먼저 권한 범위와 적용 대상을 파악하고 앱 내 안내에 따라 사용하세요. 일반적인 연결 실패를 해결하려고 출처를 알 수 없는 인증서를 추가하거나, 서비스 인증 실패를 URL Rewrite 기능 부족으로 잘못 판단하지 마세요.

리디렉션 순환과 중복 조건

한 규칙에서 주소 A를 B로 바꾸고 다른 규칙이나 서버가 B를 다시 A로 바꾸면 리디렉션 순환이 발생할 수 있습니다. 브라우저가 계속 이동하거나 리디렉션이 너무 많다는 메시지를 표시하면 재작성 규칙을 하나씩 비활성화하고 각 Location 변경을 기록하세요. PROXY와 DIRECT를 바꾸면 접근 가능성은 달라질 수 있지만 서로를 가리키는 대상 관계 자체를 해결하지는 못합니다.

여러 설정을 조합할 때는 먼저 일반 DNS와 라우팅을 확인한 다음 Host를 적용하고 마지막으로 재작성 규칙을 따로 활성화하세요. 세 계층을 동시에 바꾸면 최종 주소가 이름 해석, 리디렉션, 페이지 자체 요청 중 어디에서 비롯되었는지 판단하기 어렵습니다. 각 변경의 목적과 되돌리는 방법을 기록하고 테스트가 끝나면 임시 매핑을 제거해 나중에 남은 테스트 항목을 장기적인 요구 사항으로 오해하지 않도록 하세요.

07 자주 쓰는 규칙 조합과 설정 관리

관리하기 좋은 설정은 규칙이 많은 설정이 아니라 적은 조건만으로도 각 요청의 처리 결과를 설명할 수 있는 설정입니다. 규칙을 조합하기 전에 기본 방향을 정하세요. 대부분의 요청은 직결하고 지정한 도메인만 프록시를 사용할지, 대부분의 요청은 프록시로 보내고 명확한 예외만 직결할지 결정해야 합니다. 이 방향을 FINAL에 반영한 뒤 범위가 좁은 예외부터 앞쪽에 배치하세요.

조합 1: DIRECT 기본 처리, 지정 도메인에는 PROXY 적용

아래 설정은 ‘정해진 이름에만 프록시 경로를 적용’하는 구조를 설명합니다. api.example.com은 정확한 직결 예외이고, example.com 접미사에 해당하는 다른 요청에는 PROXY가 적용됩니다. 나머지 요청은 FINAL,DIRECT로 처리됩니다. 중요한 것은 예시 도메인 자체가 아니라 예외, 도메인 그룹, 로컬 네트워크, 기본 처리 규칙의 순서입니다.

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

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

대상 서비스가 별도의 도메인을 사용한다면 이 예시가 해당 도메인을 자동으로 처리하지 않습니다. 새 조건은 실제 요청 기록을 근거로 추가하세요. 서비스 이름을 키워드로 넣어 비슷한 이름을 모두 한꺼번에 매칭해서는 안 됩니다. 앱이 여러 요청을 함께 사용한다면 진입 페이지가 표시되는지만 보지 말고 열기, 로그인, 조회, 제출까지 전체 동작을 확인하세요.

조합 2: PROXY 기본 처리, 명확한 직결 범위 유지

다른 구성에서는 예외에 포함되지 않은 요청을 PROXY로 보냅니다. 사용자가 보유한 서버가 해당 트래픽을 처리할 수 있어야 하며, 어떤 요청이 로컬 경로를 계속 사용해야 하는지도 분명히 알아야 합니다. 예시에는 도메인 예외 하나와 사설 네트워크 대역 하나가 포함되며, 주소 분류에 GEOIP를 사용합니다. GEOIP를 유지할지는 실제 필요에 따라 결정하세요. 흔한 설정에 자주 등장한다는 이유만으로 포함해서는 안 됩니다.

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

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

두 설정은 서로 다른 관리 방향이므로 그대로 이어 붙이지 마세요. 이어 붙이면 첫 번째 설정의 FINAL이 판단을 먼저 끝내 두 번째 설정의 대부분 항목이 적용되지 않습니다. 설정을 합칠 때는 각 조각의 기존 기본 처리 행을 삭제하고 구체적인 규칙과 중복 조건을 정리한 뒤 전체 목적에 맞는 FINAL 하나만 남기세요. 합친 뒤에는 각 항목의 동작을 확인해야 합니다.

구독과 설정 파일은 따로 업데이트하세요

Subscribe 업데이트는 보통 기존 서버 목록을 갱신하고, 설정 파일 업데이트는 규칙, 매개변수, 정책 참조를 변경할 수 있습니다. 한쪽을 업데이트했다고 다른 쪽까지 올바르게 동기화되는 것은 아닙니다. 목록의 서버 이름이 바뀌었는데 사용자 설정에서 특정 이름을 참조한다면 그 이름이 여전히 존재하는지 확인하세요. 이 안내에서 기본 키워드 PROXY를 사용하는 이유는 규칙의 의미가 특정 예시 서버 이름에 좌우되지 않도록 하기 위해서입니다.

구독 주소에는 접근 토큰이 포함될 수 있으므로 민감 정보로 취급해야 합니다. 문제 해결 자료를 공유할 때는 필요한 규칙과 대상 유형만 남기고 전체 구독 주소, 서버 인증 항목, 개인 식별 정보를 삭제하세요. 공유 링크와 구독 주소의 차이는 노드 링크 형식 안내에서 확인할 수 있습니다. 두 항목은 가져오기와 업데이트 방식이 다르므로 텍스트로 복사할 수 있다는 이유만으로 같은 종류라고 보아서는 안 됩니다.

저장, 전환, 되돌리기

Config에서 편집하거나 가져온 뒤 파일이 정상적으로 열리는지 확인하고 현재 선택된 파일도 확인하세요. 저장한 다음 Home으로 돌아가 Global Routing이 Config인지 확인하고 새 요청을 만들어 테스트합니다. 연결을 다시 설정해야 한다면 영향을 받을 수 있는 작업을 먼저 끝낸 뒤 앱의 현재 화면에 따라 연결을 전환하세요. 기존에 시작된 장시간 연결은 연결 당시 경로를 계속 사용할 수 있습니다.

되돌리려면 ‘방금 내용을 삭제하기’가 아니라 검증된 작업 사본을 기준으로 해야 합니다. 변경 목적, 수정한 섹션, 테스트 대상, 관찰 결과를 매번 기록하세요. 원격 설정 업데이트로 로컬 변경이 덮어써졌다면 먼저 작업 사본을 복원해 기본 연결을 확인한 다음 필요한 항목만 다시 병합하세요. 문제가 발생한 상태에서 출처가 불분명한 설정을 여러 개 연이어 가져오지 마세요.

클라이언트의 일회성 구매 ≠ 연결 서비스 요금제입니다. Shadowrocket 앱 구매와 사용자가 보유한 연결 서비스는 별도로 관리됩니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다. 앱을 받을 수 있는 경로와 개발자 정보를 확인하려면 App Store 정품 확인 안내를 참고하세요. Shadowrocket은 Apple 플랫폼에서만 제공되며, 시스템 요구 사항은 App Store 페이지 표기를 기준으로 확인하세요.

08 규칙 확인 및 문제 해결 절차

문제를 해결할 때는 ‘연결되지 않음’, ‘연결은 되었지만 요청 실패’, ‘요청은 성공했지만 경로가 예상과 다름’을 먼저 구분해야 합니다. 각 상황에 필요한 증거가 다릅니다. Home에 연결 상태가 표시되어도 모든 대상에 접근할 수 있다는 뜻은 아닙니다. Connectivity Test 결과만으로 특정 업무 요청이 예상한 규칙에 매칭되었다고 단정할 수도 없습니다.

1단계: 반복 가능한 테스트 대상 정하기

예를 들어 이미 알고 있는 테스트 페이지를 여는 등 동작 하나를 정하고 대상 호스트 이름, 현재 네트워크, 실패 증상을 기록하세요. 백그라운드 요청의 영향을 줄이려면 한 번에 이 동작만 수행합니다. 로그인이나 업로드 단계에서만 문제가 발생한다면 홈페이지를 반복해서 새로고침하지 말고 해당 단계를 테스트하세요. 단계마다 대상이 다를 수 있으므로 첫 화면이 열린다고 이후 요청까지 검증된 것은 아닙니다.

현재 파일, Global Routing, 서버 선택, 가장 최근의 변경 사항도 기록하세요. 네트워크를 전환한 뒤 문제가 발생했다면 기존 네트워크와 새 네트워크에서 각각 다시 테스트합니다. 근거를 저장하기도 전에 앱을 다시 설치하거나 전체 설정을 초기화하지 마세요. 문제를 설명할 수 있는 상태가 사라져 특정 규칙 변경을 확인하는 대신 더 넓은 범위를 다시 설정해야 할 수 있습니다.

2단계: 설정이 규칙 판단에 사용되는지 확인

Config에서 실제 선택된 파일을 확인하고 편집 내용이 저장되었는지 확인한 다음 Home의 Global Routing을 확인하세요. Proxy 또는 Direct 모드라면 그 결과는 전역 경로를 비교하는 데만 사용할 수 있으며 [Rule]의 특정 조건이 작동하지 않는다는 증거가 되지 않습니다. Config로 돌아간 뒤 새 요청을 만들어 대상, 매칭 조건, 정책이 파일의 순서와 일치하는지 확인하세요.

Global Routing: Config
Config: 현재 작업 사본
Target: api.example.com
Expected Rule: DOMAIN,api.example.com,DIRECT
Expected Policy: DIRECT

이 내용은 기록 형식 예시이지 클라이언트 실행 로그가 아닙니다. 실제 결과는 이번 테스트에서 확인한 값을 기준으로 적고 예상값을 관찰값처럼 옮기지 마세요. 기록에서 대상 요청이 보이지 않는다면 기존 연결이 재사용되었는지, 다른 전역 조건이 요청을 먼저 우회했는지, 관찰 시간이 방금 수행한 동작과 일치하는지 확인하세요.

3단계: 증상에 따라 확인 범위 좁히기

잘못된 규칙에 매칭되면 먼저 앞부분에서 처음으로 조건에 맞는 규칙을 찾으세요. 흔한 원인은 범위가 너무 넓은 DOMAIN-KEYWORD, 정확한 예외보다 앞에 놓인 접미사 규칙, 파일 중간에 위치한 FINAL입니다. 순서를 고친 뒤 새 요청을 다시 보내세요. 끝에 중복 규칙을 추가해도 앞선 조건에서 처리된 요청이 다시 판단되지는 않습니다.

정책은 맞는데 연결에 실패하면 해당 경로에 필요한 조건을 살펴보세요. PROXY라면 사용자가 보유한 서버의 주소, 포트, 프로토콜, 인증 정보를 확인하고, DIRECT라면 기본 네트워크와 대상 접근 가능 여부를 확인합니다. REJECT라면 차단이 의도한 것인지 먼저 확인하세요. 인증 실패에는 도메인 규칙을 추가해도 대개 도움이 되지 않습니다. 대상 요청이 이미 거부되었다면 DNS를 바꿔도 다른 정책으로 자동 전환되지 않습니다.

4단계: 캐시, 기존 연결, 설정 오류 구분

도메인 해석 결과와 기존 연결은 이전 상태를 일시적으로 유지할 수 있습니다. 규칙을 바꾼 뒤에는 직접 제어할 수 있는 새 요청으로 확인하고, 필요한 경우 앱에서 제공하는 방법으로 연결을 다시 설정한 다음 결과를 살펴보세요. 캐시가 바뀔 때마다 설정이 무작위로 적용된다고 해석해서는 안 됩니다. ‘수정 전, 저장 후, 새 요청 후’의 상태를 기록하면 편집 문제와 연결 수명의 영향을 구분하기 쉽습니다.

특정 앱에서만 문제가 발생한다면 별도 도메인, 다른 주소 유형, 특수 전송 방식을 사용하는지 확인하세요. 테스트 페이지 하나에 접속된다고 모든 프로토콜 경로가 정상이라는 뜻은 아니며, 지연 시간 수치가 실제 서비스 경험 전체를 나타내지도 않습니다. 테스트 결과와 서버 선택을 이해하는 방법은 지연 시간 테스트와 노드 판단 방법에서 확인하세요. 테스트 범위는 사용자가 이미 보유한 목록으로 한정하면 됩니다.

5단계: 다시 확인할 수 있는 결론 정리

문제 해결이 끝나면 효과가 확인된 최소한의 변경만 남기고 테스트 중 임시로 바꾼 Global Routing을 원래대로 되돌리세요. 어떤 조건이 문제를 일으켰는지, 어느 행을 수정했는지, 어떻게 확인했는지, 어떻게 되돌릴 수 있는지를 기록해야 합니다. 원인을 확정할 수 없다면 개인 정보를 제거한 설정 일부와 실제 증상을 저장한 뒤 자주 묻는 질문을 확인하세요. 최초 권한 승인과 가져오기 절차를 다시 진행해야 한다면 빠른 시작 안내로 돌아가세요.