Global Routing
요청을 전반적으로 처리하는 방식을 선택하는 항목입니다. Config, Proxy, Direct는 각각 구성에 따른 처리, 프록시, 직접 연결을 뜻합니다. Rule의 분기 규칙을 적용하려면 Config가 선택되어 있는지 먼저 확인하세요. 모드를 바꿔도 서버 매개변수는 변경되지 않으며, 잘못된 인증 정보가 유효해지는 것도 아닙니다.
공식 설명서 · 용어 색인
Shadowrocket 용어 빠른 검색
화면 옵션, 프로토콜 매개변수, 규칙 정책을 먼저 구분한 다음 설정을 확인하세요. 사용 상황에 따라 용어를 정리했습니다. 범주나 용어 링크를 누르면 해당 설명으로 이동합니다.
[General]
화면과 옵션
모드는 요청 처리 방식을, 옵션은 연결 동작을 결정하며 테스트는 결과를 확인하는 데 사용합니다. 서로 대체할 수 없습니다.
Config
Global Routing에서 Config는 Rule에 따라 정책을 선택하는 등 현재 설정으로 요청을 처리한다는 뜻입니다. 페이지 탐색 메뉴의 Config는 설정 파일을 관리하는 곳을 가리킵니다. 두 의미는 표시 위치로 구분해야 합니다. 규칙이 적용되지 않는다면 모드와 실제로 선택된 설정 파일을 모두 확인하세요.
Proxy
Global Routing의 프록시 모드로, 요청을 이 모드에 따라 프록시로 처리합니다. 일상적인 분기 규칙을 하나씩 적용하는 방식은 아닙니다. 규칙 행 끝의 대문자 PROXY와는 서로 다른 계층이므로 한글 의미가 비슷하다고 혼용하면 안 됩니다. 테스트 후 규칙 기반 분기로 돌아가려면 Config로 전환하고 접속 결과를 다시 확인하세요.
Direct
Global Routing의 직접 연결 모드로, 요청은 현재 네트워크를 통해 대상에 직접 접속합니다. 직접 연결 결과를 확인할 때 사용할 수 있지만 현재 네트워크와 대상 서비스, DNS 해석의 영향을 받습니다. 화면의 Direct와 규칙 키워드 DIRECT는 대소문자가 다릅니다. 전자는 전체 모드, 후자는 개별 규칙의 처리 정책입니다.
On Demand
On Demand는 앱에서 설정한 조건에 따라 연결 동작을 제어합니다. 구체적인 조건과 사용 가능한 옵션은 현재 앱 화면을 기준으로 확인하세요. On Demand는 연결을 언제 설정할지, Rule은 요청을 어떻게 처리할지를 정하므로 용도가 다릅니다. 자동 연결이나 연결 상태에 변화가 생기면 먼저 이 조건을 확인한 뒤 규칙 조정이 필요한지 살펴보세요.
Add Server
사용자가 이미 보유한 서버 정보를 입력하는 메뉴입니다. 먼저 프로토콜 유형을 선택하고, 보유한 자료를 바탕으로 주소와 포트, 인증 매개변수를 입력하세요. 프로토콜마다 필요한 항목이 다르므로 Type만 바꿨다고 설정이 변환되는 것은 아닙니다. 저장한 뒤 주요 항목을 다시 확인해 복사 과정에서 공백이 들어가거나 전송 설정이 누락되지 않았는지 살펴보세요.
Connectivity Test
연결 가능 여부를 확인하는 기능으로, 결과는 선택한 테스트 방법과 대상, 현재 네트워크에 따라 달라집니다. 표시된 지연 시간은 사용 가능한 대역폭을 뜻하지 않으며 모든 웹사이트에 접속할 수 있다는 보장도 아닙니다. 문제를 판단할 때는 테스트 결과와 실제 요청을 함께 살펴 서버 연결, 인증 성공, 대상 접속 성공을 구분하세요.
DNS
DNS는 도메인을 IP 주소로 변환하며, 많은 연결에서 요청 전 필요한 과정입니다. 이름 해석 실패와 프록시 연결 실패는 서로 다른 문제입니다. 라우팅 정책을 바꿔도 이름 해석이 반드시 해결되는 것은 아닙니다. 도메인에 접속할 수 없다면 먼저 해석 설정과 반환된 주소를 확인한 뒤, 요청에 어떤 규칙이 적용됐는지 살펴보세요.
[General]
프록시 프로토콜
프로토콜 이름은 연결 방식을 나타낼 뿐 회선 품질을 뜻하지 않습니다. 매개변수를 입력할 때는 사용자가 보유한 서버 정보를 기준으로 하세요.
Shadowsocks
Shadowsocks는 서버 주소, 포트, 암호화 방식, 비밀번호 등의 매개변수로 프록시 연결을 설정합니다. 암호화 방식은 서버 측 설정과 일치해야 하며, 이름이 비슷한 옵션을 임의로 바꿔서는 안 됩니다. 보유한 정보에 추가 전송 매개변수가 있다면 주소와 비밀번호만 입력하고 테스트할 것이 아니라 항목별로 확인하세요.
VMess
VMess는 사용자 인증을 사용하는 프록시 프로토콜로, 사용자 식별자와 서버 인증 설정이 서로 맞아야 합니다. 전송 방식, TLS, 경로, Host 등의 매개변수가 필요할 수도 있으며 각 항목은 인증 정보와 역할이 다릅니다. 가져온 뒤 서버 항목이 표시되더라도 정보가 저장된 것일 뿐, 모든 항목이 올바르다는 뜻은 아닙니다.
VLESS
VLESS는 사용자 식별자로 인증하며 전송 방식과 연결 보안 설정을 별도로 확인해야 합니다. VMess와는 다른 프로토콜입니다. 둘 다 UUID를 사용할 수 있다고 해서 Type을 서로 바꿔서는 안 됩니다. 설정할 때 서버에서 요구하는 매개변수를 빠짐없이 유지하고, 실제 앱에 표시되는 입력 항목을 기준으로 정보를 입력하세요.
Trojan
Trojan은 일반적으로 TLS로 연결을 보호하고 비밀번호로 인증합니다. 주소, 포트, 비밀번호 외에 TLS에 필요한 서버 이름과 인증서 관련 설정도 확인하세요. 인증 정보가 맞더라도 TLS 검증에 실패하면 연결되지 않을 수 있으므로 두 단계를 나누어 살펴봐야 합니다.
Hysteria2
Hysteria2는 QUIC 기반으로 UDP를 통해 연결하며, 서버의 인증 및 TLS 설정 등이 서로 맞아야 합니다. 현재 네트워크에서 일반 TCP 연결이 가능하다고 해서 해당 UDP 경로도 반드시 사용할 수 있는 것은 아닙니다. 문제를 확인할 때 프로토콜 매개변수와 네트워크 연결 가능성을 함께 살펴보고, 지연 시간 하나만으로 원인을 판단하지 마세요.
WireGuard
WireGuard는 키로 인증하며, 일반적인 설정에는 키, 터널 주소, Endpoint, 허용 주소 범위가 포함됩니다. 여기서 키와 주소는 일반 프록시 프로토콜의 비밀번호나 서버 주소를 대신하는 항목이 아닙니다. 진단 자료를 공유할 때는 개인 키와 기타 인증 정보를 가리고 필요한 항목 이름만 남기세요.
HTTP · SOCKS5
HTTP와 SOCKS5는 서로 다른 프록시 프로토콜입니다. 접속하려는 웹사이트 유형이 아니라 보유한 서버의 유형에 맞춰 선택하세요. 사용자 이름과 비밀번호가 필요한지, 보호된 연결을 제공하는지는 해당 설정에 따라 확인해야 합니다. 주소와 포트가 같더라도 두 프로토콜을 서로 바꿔 사용할 수 있는 것은 아닙니다.
[Rule]
규칙 키워드
규칙 유형은 어떤 필드를 확인할지 정하고, 정책은 매칭된 뒤 요청을 어떻게 처리할지 정합니다. 아래 도메인은 문법 설명을 위한 예시입니다.
DOMAIN
DOMAIN은 지정한 도메인과 정확히 일치시키며 하위 도메인은 자동으로 포함하지 않습니다. 예를 들어 DOMAIN,example.com,PROXY는 example.com에 적용되며 api.example.com에도 매칭된다고 단정할 수 없습니다. 전체 도메인 접미사를 포함하려면 DOMAIN-SUFFIX의 매칭 범위를 이해한 뒤 규칙을 선택하세요.
DOMAIN-SUFFIX
DOMAIN-SUFFIX는 지정한 도메인과 그 하위 도메인을 매칭하므로 같은 도메인 접미사에 속하는 요청을 표현할 때 적합합니다. DOMAIN-SUFFIX,example.com,PROXY는 example.com과 api.example.com에 적용됩니다. 특정 하위 도메인에 다른 정책을 적용하려면 범위가 넓은 이 규칙보다 구체적인 규칙을 앞에 두세요.
DOMAIN-KEYWORD
DOMAIN-KEYWORD는 도메인에 포함된 키워드를 기준으로 매칭하며, 완전한 도메인 접미사를 매칭하는 것과는 다릅니다. 키워드가 너무 짧거나 흔하면 의도하지 않은 도메인까지 포함될 수 있습니다. 추가하기 전에 매칭 범위를 고려하고 실제 요청으로 적용 결과를 확인해 광범위한 규칙이 정책을 먼저 결정하지 않도록 하세요.
GEOIP
GEOIP는 IP 지리 정보 데이터베이스의 분류를 기준으로 대상 주소를 매칭합니다. 예를 들면 GEOIP,CN,DIRECT와 같습니다. 이 분류는 주소 데이터베이스에 의존하며, 웹페이지의 내용이나 도메인 접미사, 실제 서비스 위치를 직접 판단하는 것은 아닙니다. 사용할 때는 DNS가 반환한 주소와 앞선 도메인 규칙의 매칭 여부도 고려해야 합니다.
IP-CIDR
IP-CIDR은 지정한 IPv4 대역을 매칭하며 슬래시 뒤의 숫자는 네트워크 접두사 길이를 나타냅니다. IP-CIDR,192.168.0.0/16,DIRECT는 해당 주소 범위에 직접 연결 정책을 적용한다는 뜻입니다. 대역이 넓을수록 더 많은 대상이 포함됩니다. 규칙을 작성하기 전에 대상 주소 범위를 확인하고 목록에서의 위치를 정하세요.
IP-CIDR6
IP-CIDR6은 IPv6 대역을 매칭하며 IPv4용 IP-CIDR과 별도로 작성합니다. 예를 들어 IP-CIDR6,2001:db8::/32,DIRECT는 문서용 예시 주소를 사용한 문법 설명입니다. IPv4 규칙만 설정했다고 IPv6 요청에도 같은 정책이 적용되는 것은 아니므로 실제 반환 주소를 확인하세요.
USER-AGENT
USER-AGENT는 요청에서 확인할 수 있는 User-Agent 필드를 기준으로 매칭하며, 앱 이름으로 모든 트래픽을 자동 식별하는 기능은 아닙니다. 암호화된 요청에서는 관련 필드를 항상 직접 확인할 수 있는 것은 아니므로 이 규칙이 모든 접속에 적용된다고 가정해서는 안 됩니다. 추가하기 전에 앱이 필요한 필드를 가져올 수 있는지 확인하고 매칭 조건이 적절한지 살펴보세요.
FINAL
FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리하며 보통 Rule 섹션의 끝에 둡니다. 도메인이나 대역 매칭값은 필요하지 않습니다. 일반적인 표기는 FINAL,PROXY 또는 FINAL,DIRECT입니다. 너무 앞에 두면 뒤에 있는 규칙이 기본 규칙에 이미 처리된 요청을 다룰 수 없습니다.
[Rule]
정책과 매칭 순서
영문 대소문자를 보면 서로 다른 계층을 구분하는 데 도움이 됩니다. 화면 옵션 Proxy와 규칙 키워드 PROXY를 혼동하지 마세요.
Rule
설정 파일의 [Rule] 섹션은 매칭 조건과 처리 정책을 구성하며, 일반적인 규칙은 유형, 매칭값, 정책으로 이루어집니다. Rule은 서버 목록이 아니며 서버에 빠진 인증 정보를 보완하지도 않습니다. 문제를 확인할 때 먼저 Global Routing이 Config인지 확인한 다음 현재 파일에 적용된 규칙을 살펴보세요.
PROXY
PROXY는 규칙에서 사용하는 프록시 정책 키워드로, 매칭된 요청을 프록시로 처리한다는 뜻입니다. 실제 연결에는 현재 선택한 프록시와 유효한 서버 매개변수가 필요합니다. PROXY를 적었다고 사용 가능한 연결이 설정되는 것은 아닙니다. 해당 요청의 정책만 결정하며 Global Routing을 Proxy로 전환하는 다른 표기가 아닙니다.
DIRECT
DIRECT는 매칭된 요청을 직접 연결로 처리한다는 뜻이며 특정 도메인이나 주소의 처리 방식을 지정할 때 사용합니다. 직접 연결을 하려면 현재 네트워크에서 대상에 접속할 수 있어야 하고 필요한 도메인 해석도 완료되어야 합니다. 이 정책은 규칙에 매칭된 요청에 적용되며 클라이언트 전체를 Global Routing의 Direct 모드로 전환하는 것은 아닙니다.
REJECT
REJECT는 매칭된 요청을 거부하며 특정 범위에 대한 접속을 명시적으로 차단할 때 사용합니다. 정상적인 페이지가 열리지 않는다면 해당 도메인이 지나치게 넓은 차단 규칙에 포함됐는지 확인하세요. 원인을 확인하지 않은 채 설정 파일 전체를 다시 작성하기보다 매칭 조건을 좁히거나 더 구체적인 예외를 추가하세요.
매칭 순서
규칙 모드에서는 위에서 아래로 규칙을 확인하며, 먼저 매칭된 규칙이 요청 정책을 결정합니다. 더 구체적인 규칙이라고 자동으로 앞으로 이동해 우선 적용되는 것은 아닙니다. 일반적으로 명확한 예외를 먼저 두고 범위가 넓은 규칙을 뒤에 배치한 다음 FINAL을 마지막에 둡니다. 순서를 바꾼 뒤 요청을 다시 보내 새 매칭 결과를 확인하세요.
예외는 앞에, 기본 규칙은 뒤에
아래 예시는 api.example.com에 DIRECT를 적용하고, 같은 도메인 접미사에 속하는 나머지 요청에는 PROXY를 적용하며, 그 밖의 요청은 FINAL로 처리합니다. 순서를 이해하기 위한 예시이므로 적용 전에 자신의 대상과 보유한 연결 정보를 확인하세요.
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECTDOMAIN-SUFFIX를 첫 번째 줄로 옮기면 api.example.com은 해당 줄에 먼저 매칭됩니다. 뒤에 있는 DOMAIN은 이미 결정된 정책을 덮어쓰지 않습니다. 전체 항목과 규칙 예시는 설정 항목 참고에서 확인하세요.
[Host] / [URL Rewrite]
구독 및 설정 파일
서버 항목, 규칙 파일, 구입 내역은 서로 다른 정보입니다. 한 종류를 가져오거나 복원해도 다른 작업이 자동으로 완료되지는 않습니다.
Subscribe
Subscribe는 사용자가 이미 보유한 서버 목록을 가져오고 업데이트하는 기능입니다. 구독 내용은 해당 구독 출처에서 관리합니다. 구독을 업데이트해도 현재 설정 파일이 전환되거나 규칙 정책이 바뀌지는 않습니다. 구독 주소에 접근 인증 정보가 포함될 수 있으므로 스크린샷, 로그, 문의 자료에서는 전체 주소와 인증 매개변수를 가리세요.
서버 정보
서버 정보는 연결에 필요한 주소, 포트, 프로토콜, 인증 등의 매개변수 모음이며, 일상적으로 노드 정보라고도 합니다. 서버 표시 이름은 구분을 위한 라벨일 뿐 실제 연결 방식을 결정하지 않습니다. 보유한 정보를 기준으로 입력하고 주요 항목을 확인하세요. 가져오는 방법은 빠른 시작을 참고하세요.
설정 파일
설정 파일은 General, Rule, Host, URL Rewrite 등의 섹션으로 구성되며 각 섹션의 역할은 다릅니다. 서버 구독은 주로 연결 정보를 제공하고, 설정 파일은 요청을 해석하고 매칭해 처리하는 방식을 정의하므로 서로 같은 것이 아닙니다. 편집 전에 원본 파일을 저장하고, 전환한 뒤 현재 적용 중인 파일과 Global Routing 옵션을 확인하세요.
Host
[Host] 섹션은 지정한 도메인에 주소를 매핑합니다. 도메인에 대응하는 주소를 바꾸는 기능이지 PROXY나 DIRECT를 직접 지정하는 기능은 아닙니다. 잘못되었거나 오래된 매핑은 요청을 부적절한 대상으로 보내 접속을 실패하게 할 수 있습니다. Rule 문법이 맞더라도 문제가 생길 수 있으므로 이름 해석을 점검할 때 이 매핑과 DNS 설정을 함께 확인하세요.
URL Rewrite
[URL Rewrite] 섹션은 매칭 조건에 따라 요청 URL을 처리하며, Rule의 연결 정책과는 역할이 다릅니다. 재작성된 대상에 따라 요청 경로나 접속 결과가 달라질 수 있으므로 재작성 규칙을 일반 도메인 분기 규칙처럼 사용하면 안 됩니다. 조정하기 전에 원래 URL과 매칭 범위, 예상 결과를 확인하고 필요한 요청 내용을 처리할 수 있는지도 살펴보세요.
iCloud 동기화
iCloud 동기화는 앱의 관련 설정과 함께 작동합니다. 실제 동기화 항목과 옵션은 앱 내 표시를 기준으로 확인하세요. 데이터를 동기화해도 App Store 구입 내역이 복원되는 것은 아니며, 기기 변경 후 연결 확인을 대신하지도 않습니다. 기기를 바꾼 뒤에는 서버 목록과 현재 설정, 라우팅 모드, 첫 연결에 필요한 시스템 권한을 확인하세요.
구입 항목
구입 항목은 App Store에서 기존 계정의 구입 내역을 찾아 앱을 다시 받는 메뉴이며, 규칙이나 서버 정보를 복원하는 기능은 아닙니다. Shadowrocket은 주로 iPhone과 iPad에서 사용하며, 다른 Apple 기기의 호환성, 시스템 요구 사항, 유니버설 구입 여부는 App Store 페이지의 안내를 기준으로 확인하세요. 기기 변경 및 복원 방법은 구입 항목 복원 안내를 참고하세요.