첫 연결을 마치고 Config를 편집하려는 사용자를 위한 안내입니다. 매칭 조건과 실행 정책을 구분한 뒤, 여섯 가지 규칙 유형으로 위에서 아래로 적용되는 과정을 살펴봅니다. 예시는 문법 설명용이며 기존 설정을 통째로 대체할 수 있는 완성된 구성은 아닙니다. 프록시 연결이 필요하다면 사용자가 이미 보유한 서비스 제공업체, 서버 및 구독이 있어야 합니다.
1. Global Routing을 확인한 다음 Config 수정하기
Shadowrocket 규칙은 두 가지를 결정합니다. 연결이 어떤 조건에 해당하는지, 조건에 맞으면 어떤 정책을 적용할지입니다. 규칙으로 서버를 만들거나 사용할 수 없는 서버를 작동시킬 수는 없습니다. 수정에 앞서 Home에서 사용 가능한 서버를 선택하고 기본 연결 테스트를 완료했는지 확인하세요.
Home에서는 서버와 연결 상태를 관리하고, Config에서는 구성 파일을, Settings에서는 앱 설정을 관리합니다. 구성 규칙에 따라 트래픽을 분기하려면 Home → Global Routing에서 Config를 선택하세요. 파일만 수정하고 해당 구성을 활성화하지 않았다면 규칙이 적용되는지 판단할 수 없습니다.
| 모드 | 주요 기능 | 이 글에서 확인할 항목 |
|---|---|---|
Config | 현재 구성의 규칙에 따라 정책을 결정합니다. | 규칙 테스트에는 이 모드를 사용합니다. |
Proxy | 이 글의 도메인 규칙에 따라 분기하지 않고 트래픽을 프록시로 처리합니다. | 프록시 연결 경로의 사용 가능 여부를 비교하는 데 도움이 됩니다. |
Direct | 트래픽을 직접 연결로 처리합니다. | 이 모드로는 특정 PROXY 규칙이 적용되는지 확인할 수 없습니다. |
Scene | 구성된 Scene 설정에 따라 라우팅 동작을 결정합니다. | 먼저 Scene 구성을 확인하세요. 단일 규칙 파일을 살펴볼 때는 Config를 사용합니다. |
On Demand는 연결을 설정하거나 끊는 시점을 결정하며 도메인 및 IP 규칙을 대신하지 않습니다. 연결이 자동으로 다시 설정된다면 Settings → On Demand도 확인하세요. 자동 연결 현상을 특정 DOMAIN 규칙이 연결을 유발한 것으로 오해하지 마세요.
2. 규칙 구조와 매칭 순서
기본 규칙은 대부분 쉼표로 구분한 ‘유형, 매칭 값, 정책’ 구조를 사용합니다. 규칙은 구성 파일의 [Rule] 섹션에 작성하며, 일반적으로 위에서 아래 순서로 확인합니다. 먼저 매칭된 규칙이 해당 연결의 정책을 결정하고, 뒤에 있는 더 구체적인 규칙이 자동으로 우선 적용되지는 않습니다.
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT
이 예시에서는 login.example.com이 첫 번째 줄에 먼저 매칭되어 DIRECT를 사용합니다. www.example.com은 첫 번째 줄에 매칭되지 않으므로 다음으로 두 번째 줄에 매칭되어 PROXY를 사용합니다. 나머지 매칭되지 않은 연결은 FINAL이 처리합니다. 두 번째 줄을 첫 번째 줄 위로 옮기면 로그인 도메인도 접미사 규칙에 먼저 매칭됩니다.
이 수치는 이 글에서 다루는 기본 개념을 설명하며, Shadowrocket이 여섯 가지 규칙만 지원한다는 뜻은 아닙니다. 규칙마다 한 줄씩 작성하고 영문 쉼표를 사용하세요. 서식 있는 텍스트에서 복사할 때 전각 문장 부호나 보이지 않는 문자가 섞이지 않도록 주의하세요.
3. DOMAIN, DOMAIN-SUFFIX, DOMAIN-KEYWORD
도메인 규칙은 연결과 관련된 호스트 이름을 매칭하며 웹페이지 경로는 매칭하지 않습니다. example.com처럼 입력하고, 프로토콜·포트·경로가 포함된 전체 URL을 입력하지 마세요. URL의 경로에 단어가 들어 있어도 DOMAIN-KEYWORD에 매칭되는 것은 아닙니다.
| 규칙 | 매칭되는 항목 | 매칭되지 않는 항목 |
|---|---|---|
DOMAIN,example.com,DIRECT | example.com | www.example.com |
DOMAIN-SUFFIX,example.com,PROXY | example.com、api.example.com | notexample.com |
DOMAIN-KEYWORD,example,PROXY | 호스트 이름에 example이 포함된 도메인 | 웹페이지 경로에만 example이 포함된 요청 |
DOMAIN: 특정 호스트에만 적용하는 예외
DOMAIN은 login.example.com만 직접 연결하고 다른 하위 도메인은 계속 프록시를 사용하게 하는 등, 특정 호스트 하나만 조정할 때 적합합니다. 해당 호스트의 하위 도메인까지 자동으로 포함하지는 않습니다. 범위가 더 넓은 규칙보다 앞에 구체적인 예외를 배치하세요.
DOMAIN-SUFFIX: 루트 도메인과 하위 도메인
DOMAIN-SUFFIX는 도메인 경계를 기준으로 여러 호스트를 관리할 때 적합합니다. example.com으로 작성하면 되며 *.를 붙일 필요가 없습니다. 루트 도메인과 하위 도메인을 모두 포함하지만 notexample.com은 같은 접미사로 취급하지 않습니다.
DOMAIN-KEYWORD: 호스트 이름에 포함된 문자열
DOMAIN-KEYWORD는 매칭 범위가 넓어 예상하지 못한 도메인까지 포함할 수 있습니다. 문자열 기준 매칭이 꼭 필요한 경우가 아니라면 DOMAIN 또는 DOMAIN-SUFFIX를 우선 사용하세요. 키워드 규칙을 앞에 배치하면 뒤에 있는 정확한 규칙도 우선 적용되지 않습니다.
4. GEOIP와 IP-CIDR: 대상 IP 기준 매칭
IP 규칙은 URL 문자가 아니라 대상 주소를 기준으로 합니다. 도메인에 접속할 때는 IP 매칭 전에 DNS 조회 결과가 필요할 수 있습니다. 조회 결과의 변화, IP 데이터베이스의 차이, CDN의 라우팅에 따라 실제 매칭 결과가 달라질 수 있습니다.
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
GEOIP,CN,DIRECT는 대상 IP가 사용 중인 IP 데이터베이스에서 CN으로 분류될 때 DIRECT를 사용한다는 뜻입니다. 웹사이트의 언어를 판별하거나 운영자의 소재지를 알아내는 규칙은 아닙니다. 중국어 사이트라도 여러 지역의 주소를 사용할 수 있고, 하나의 도메인이 여러 주소로 해석될 수도 있습니다.
- IP-CIDR:
192.168.0.0/16은 IPv4 사설 주소 범위를 나타내며, 구체적인 로컬 네트워크를 직접 연결할 때 자주 사용합니다. 실제 네트워크 범위에 맞게 입력해야 합니다. - 프리픽스 길이: IPv4의
/32는 주소 하나만 매칭하고,/24는 주소 256개를 포함합니다. 숫자가 작을수록 일반적으로 범위가 넓으므로 프리픽스 길이를 임의로 줄이지 마세요. - no-resolve: 이 추가 매개변수는 해당 IP 규칙을 확인하기 위해 도메인을 별도로 조회하지 않도록 합니다. 전역 DNS를 끄는 기능은 아니며, 도메인 요청이 반드시 이 규칙에 매칭된다는 뜻도 아닙니다.
- 예시 주소:
192.0.2.0/24는 문서에서 사용하는 예시 네트워크 대역입니다. 여기서는 문법을 설명하기 위해 사용한 것이며, 실제 구성에서 실서비스를 거부해야 한다는 뜻은 아닙니다.
대상이 IPv6를 사용하는 경우 IPv4만 다루는 IP-CIDR 규칙으로는 해당 연결을 처리할 수 없습니다. 관련 IPv6 규칙과 네트워크 설정을 별도로 확인하세요. IPv4 예시가 올바르다고 해서 모든 주소 체계가 처리된 것은 아닙니다.
5. PROXY, DIRECT, REJECT와 FINAL 조합하기
매칭 유형과 정책은 서로 다른 개념입니다. DOMAIN-SUFFIX는 ‘어떤 도메인을 매칭할지’를 정하고, PROXY는 ‘매칭 후 어떻게 처리할지’를 정합니다. 규칙의 마지막 항목을 DIRECT에서 PROXY로 바꾸면 아웃바운드 방식이 달라질 뿐, 도메인 매칭 범위가 넓어지지는 않습니다.
| 정책 | 처리 방식 | 확인할 항목 |
|---|---|---|
PROXY | 프록시를 통해 아웃바운드 연결을 처리합니다. | 현재 서버 또는 관련 정책에서 사용할 수 있는 항목이 선택되어 있는지 확인하세요. |
DIRECT | 대상에 직접 연결합니다. | 현재 네트워크에서 대상에 직접 접속할 수 있는지 확인하세요. |
REJECT | 조건에 맞는 연결을 거부합니다. | 거부 범위가 필요한 인터페이스를 포함하지 않는지 확인하세요. |
FINAL은 매칭 조건이나 도메인·IP 값을 따로 지정하지 않는 기본 처리 규칙이며, FINAL,정책 형식으로 작성합니다. 규칙 섹션의 마지막에 배치하세요. FINAL을 중간에 두면 이미 기본 처리된 연결을 뒤쪽 규칙이 처리할 수 없습니다.
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
이 예시는 구체적인 예외를 먼저 처리하고, 더 넓은 범위의 규칙을 적용한 뒤 마지막에 나머지를 처리합니다. ads.example.com은 거부되고, login.example.com은 직접 연결되며, 나머지 example.com 도메인은 프록시로 처리됩니다. 해당 도메인이 CN 주소로 해석되더라도 앞선 도메인 규칙이 이미 정책을 결정했으므로 GEOIP까지 진행되지 않습니다.
6. Config에서 저장·활성화·확인하기
수정 전에 현재 사용할 수 있는 구성의 사본을 보관하세요. 서버 구독 업데이트와 규칙 파일 업데이트는 서로 다른 작업입니다. Home에서 서버 목록을 새로고침했다고 해서 Config의 규칙까지 변경되는 것은 아닙니다. 원격으로 관리되는 구성은 업데이트 과정에서 로컬 수정 사항을 덮어쓸 수 있으므로 편집 전에 파일 출처를 확인하세요.
- 기준 상태 확인. Home에서 서버를 선택하고 연결을 켠 다음 Connectivity Test를 실행하세요. 테스트 성공은 해당 테스트 경로를 사용할 수 있다는 뜻일 뿐, 모든 웹사이트에 접속할 수 있다는 의미는 아닙니다.
- 현재 구성을 찾습니다. Config로 이동해 현재 활성화된 파일을 확인하세요. 해당 파일의 편집 메뉴에서
[Rule]섹션을 확인하고 나머지 구성 섹션은 유지하세요. 이 글의 예시를 파일 전체에 덮어쓰지 마세요. - 한 번에 하나만 변경합니다. 필요한 DOMAIN 또는 DOMAIN-SUFFIX 규칙 하나를 추가하고, 관련된 광범위한 규칙과 FINAL보다 앞에 배치한 다음 저장하세요.
- 적용 조건을 확인합니다. 수정된 구성을 활성화하고 Home → Global Routing에서 Config를 선택하세요. 필요하다면 연결을 다시 설정하세요.
- 요청을 다시 보냅니다. 기존 페이지를 닫거나 관련 앱의 연결을 종료한 뒤 다시 테스트하세요. 기존 장시간 연결은 처음 설정될 때의 아웃바운드 선택을 계속 사용할 수 있으므로 새 규칙의 결과를 보여주지 않을 수 있습니다.
- 실제 결과를 기록합니다. 연결 기록이나 로그에서 대상 호스트 이름, 대상 IP, 적용된 정책을 확인하세요. 개선되지 않으면 이전의 정상 구성을 복원한 뒤 DNS 또는 아웃바운드 연결 경로를 점검하세요.
테스트할 때는 포트와 규칙 범위도 구분해야 합니다. HTTPS는 보통 대상 포트 443을 사용하지만 DOMAIN,example.com,DIRECT 자체에는 ‘443만 매칭’하는 제한이 없습니다. 웹페이지는 정상인데 다른 포트를 사용하는 서비스가 실패한다면 도메인 규칙이 적용되지 않는다고 단정하지 말고 서비스의 리스닝 상태와 네트워크 연결을 확인하세요.
7. 연결 실패 시 오류와 규칙 적용 여부 구분하기
오류 메시지 원문은 연결 과정의 특정 단계가 실패했다는 뜻이며, 특정 규칙이 잘못 작성되었다는 증거는 아닙니다. 아래 두 오류는 네트워크 진단 과정에서 나타날 수 있는 메시지이며 Shadowrocket 전용 규칙 문법 오류가 아닙니다. 실패한 대상과 실제 아웃바운드 경로를 함께 확인해 원인을 파악하세요.
오류: Connection refused
원인: 대상 또는 중간 장치가 연결을 거부했을 수 있습니다. 해당 포트에서 서비스가 대기 중이지 않을 수도 있습니다.
해결: 먼저 실패한 대상이 프록시 서버인지 웹사이트인지 확인한 뒤 해당 주소와 포트를 점검하세요. 규칙이 매칭된 것을 확인했다면 해당 아웃바운드 서비스의 상태를 확인합니다.
오류: Operation timed out
원인: 제한 시간 안에 연결이 완료되지 않았습니다. 네트워크 경로, 필터링 또는 대상에 연결할 수 없는 상황이 원인일 수 있습니다.
해결: 먼저 Home에서 Connectivity Test를 실행한 뒤 DIRECT와 PROXY 경로를 각각 확인하세요. 한 번에 대상 규칙 하나만 조정하고 DNS와 서버를 동시에 바꾸지 마세요.
REJECT가 적용되면 연결이 차단되는 것이 정상입니다. 필요한 리소스가 거부되었다면 거부 규칙의 범위를 좁히거나 허용할 대상을 구체적으로 지정한 예외를 앞에 추가하세요. 반복해서 요청해도 이미 적용된 REJECT 규칙이 PROXY로 바뀌지는 않습니다.
8. 규칙 설정 자주 묻는 질문
DOMAIN 규칙을 추가했는데 하위 도메인에 변화가 없는 이유는 무엇인가요?
DOMAIN은 입력한 호스트 이름만 매칭합니다. 루트 도메인과 하위 도메인을 모두 포함하려면 DOMAIN-SUFFIX를 사용하고 해당 규칙이 다른 매칭 규칙보다 앞에 있는지 확인하세요. 하위 도메인 하나에만 예외가 필요하다면 해당 호스트에 DOMAIN 규칙을 추가하면 됩니다.
규칙을 마지막 줄에 작성했는데 계속 적용되지 않는 이유는 무엇인가요?
먼저 FINAL 뒤에 있는지 확인하세요. 구체적인 규칙을 FINAL 앞에 옮긴 다음, 앞쪽의 DOMAIN-SUFFIX 또는 DOMAIN-KEYWORD 규칙에 이미 매칭되는지도 살펴보세요. 규칙은 뒤에 있을수록 우선순위가 높아지는 방식으로 적용되지 않습니다.
GEOIP에 CN을 지정했는데도 웹사이트가 PROXY로 연결되는 이유는 무엇인가요?
먼저 앞선 도메인 규칙에서 PROXY를 선택했는지 확인한 다음 실제로 해석된 대상 주소와 IP 데이터베이스의 분류를 확인하세요. GEOIP는 웹사이트의 언어를 기준으로 판단하지 않습니다. 특정 도메인의 아웃바운드 경로를 고정하려면 앞쪽에 명시적인 DOMAIN 규칙을 추가해 확인할 수 있습니다.
구독을 새로고침했는데 규칙이 그대로인 이유는 무엇인가요?
서버 구독과 Config 파일을 각각 확인하세요. 먼저 Config에서 활성화된 파일과 규칙 내용을 확인한 뒤 해당 원격 구성을 업데이트해야 하는지 판단하세요. 업데이트 전에 로컬 수정 사항을 저장하고, 구독 새로고침을 규칙 업데이트로 착각하지 마세요.
브라우저에서는 정상인데 앱에서 이미지가 열리지 않을 때는 어떻게 해야 하나요?
이미지 요청에 사용된 실제 호스트 이름을 확인하고 기본 사이트만 테스트하지 마세요. 요청을 다시 보낸 뒤 연결 기록에서 다른 리소스 도메인, 다른 대상 IP 또는 REJECT된 인터페이스가 있는지 확인하고 해당 대상에 필요한 최소 범위의 예외를 추가하세요.