Home
서버 항목과 현재 선택 항목, 연결 스위치를 확인하는 기본 화면입니다. 목록에 항목이 있다는 것은 정보가 저장되었다는 뜻일 뿐, 연결이 성공적으로 설정되었다는 의미는 아닙니다. 처음 사용할 때는 선택된 서버를 확인한 다음 연결 스위치를 조작하고, 시스템 알림과 실제 접속 결과도 살펴보세요.
공식 매뉴얼 / 용어 정리
Shadowrocket 용어 및 규칙 키워드
사용 상황에 맞춰 인터페이스 용어, 프로토콜, 구성 관련 개념을 찾아보세요. 먼저 조정하려는 항목이 전체 모드인지, 매칭 조건인지, 실행 정책인지 구분한 다음 해당 화면에서 설정하면 됩니다. 이름에 Proxy가 들어가더라도 같은 단계의 항목은 아닐 수 있습니다.
인터페이스 용어는 영어 그대로 사용
규칙은 위에서 아래로 매칭
기존 구독 또는 서버 정보가 필요
인터페이스 및 스위치
화면과 전체 모드
모드는 구성에 따라 트래픽을 분기할지 결정하고, 연결 스위치는 연결을 설정할지 결정합니다. 각각 따로 확인해야 합니다.
Global Routing
전체 연결 처리 방식을 정하는 모드 선택으로, 구성·프록시·직접 연결은 각각 Config / Proxy / Direct에 해당합니다. 규칙이 적용되지 않을 때는 먼저 여기서 Config가 선택되어 있는지 확인한 다음 규칙 내용을 살펴보세요. 모드를 바꿔도 서버 매개변수가 자동으로 수정되지는 않으며, 연결 상태 점검을 대신할 수도 없습니다.
Config
Global Routing 모드에서 Config를 선택하면 현재 활성화된 구성의 규칙에 따라 정책이 정해집니다. 구성 파일을 관리하는 Config 페이지와 이름은 같지만 의미는 다릅니다. 이 모드를 선택한 뒤에는 어떤 구성이 활성화되어 있는지, 해당 구성에 필요한 Rule이 포함되어 있는지 확인해야 합니다.
Proxy
Global Routing의 프록시 모드로, 현재 선택한 프록시를 통해 연결을 처리합니다. Config 모드와 비교해 문제를 점검할 때 유용합니다. 특정 프로토콜을 뜻하는 것도 아니며 현재 서버가 작동한다는 보장도 없습니다. Proxy에서는 접속되지만 Config에서 실패한다면 모든 서버 매개변수를 다시 입력하기 전에 매칭된 규칙과 정책 선택을 확인하세요.
Direct
Global Routing의 직접 연결 모드로, 현재 네트워크를 통해 대상에 직접 연결합니다. 규칙에 대문자로 표시되는 DIRECT와는 단계가 다릅니다. 전자는 전체 모드이고 후자는 개별 규칙의 실행 정책입니다. 비교 테스트에서는 대상과 로컬 네트워크를 동일하게 유지해야 차이가 어느 단계에서 비롯됐는지 판단하기 쉽습니다.
On Demand
설정된 네트워크 조건에 따라 연결 동작을 실행하는 기능으로, Wi-Fi와 셀룰러 네트워크 간 전환 등에 사용할 수 있습니다. 언제 연결할지를 정하는 기능이며, 각 도메인에 PROXY 또는 DIRECT를 선택하지는 않습니다. 수동으로 연결을 끊은 뒤 다시 연결된다면 스위치를 반복해서 조작하기보다 On Demand 조건과 현재 시스템 네트워크를 확인하세요.
Connectivity Test
연결 상태를 확인하는 진단 기능입니다. 결과는 테스트 방식, 대상, 현재 네트워크에 따라 달라질 수 있습니다. 지연 시간은 한 번의 테스트에서 응답에 걸린 시간이며 지속적인 전송 속도와는 다릅니다. 테스트에 성공해도 모든 웹사이트에 접속할 수 있다는 뜻은 아닙니다. 시간 초과가 발생하면 프로토콜 매개변수, 시스템 시간, 실제 연결 결과를 함께 확인하세요.
프로토콜
서버 연결 방식
프로토콜은 클라이언트와 서버가 함께 따르는 통신 방식입니다. 이미 보유한 서버 정보를 사용할 때는 주소와 포트만 비교하지 말고 프로토콜, 인증, 전송 매개변수를 한꺼번에 확인해야 합니다.
Shadowsocks
공유 키와 암호화 방식을 사용하는 프록시 프로토콜로, 연결 양쪽에서 호환되는 설정을 사용해야 합니다. 서버 주소, 포트, 비밀번호, 암호화 방식을 중점적으로 확인하세요. 추가 전송 설정이 있다면 원래 제공된 정보와 일치하는지도 살펴봐야 합니다. 이름이 비슷하다는 이유만으로 암호화 방식을 바꾸지 마세요. 매개변수가 맞지 않으면 연결이 실패할 수 있습니다.
VMess
사용자 식별자 등의 정보로 인증하는 프록시 프로토콜로, 다양한 전송 방식과 조합할 수 있습니다. 주소와 포트 외에도 사용자 식별자, 전송 유형, TLS 관련 설정을 확인해야 합니다. 기존 구독을 정상적으로 가져올 수 있다면 값을 직접 수정하기 전에 가져온 결과와 원래 매개변수를 비교해 Host나 경로 같은 연관 항목이 빠지지 않았는지 확인하세요.
VLESS
인증 구조가 비교적 간결한 프록시 프로토콜로, 인증 방식과 전송 보안은 구분해서 이해해야 합니다. VLESS 자체는 전송 구간 전체의 암호화를 보장하지 않으며, 실제 연결에는 관련 보안 및 전송 설정도 필요합니다. VMess 항목의 유형만 VLESS로 바꾸고 모든 항목을 그대로 사용하지 마세요. 사용자가 이미 보유한 서버 정보를 기준으로 설정해야 합니다.
Trojan
일반적으로 TLS 연결을 통해 프록시 데이터를 전송하고 비밀번호로 인증합니다. 확인할 때는 연결 주소, TLS 검증에 사용하는 서버 이름, 비밀번호를 구분하세요. 각각 역할이 다릅니다. 인증서 검증에 실패하면 먼저 서버 이름, 시스템 시간, 서버 인증서를 확인하세요. 검증을 끄는 것은 일반적인 해결 방법이 아닙니다.
Hysteria2
QUIC 기반 프록시 프로토콜로, 연결 상태는 네트워크의 UDP 지원 여부에 영향을 받습니다. 인증 정보, TLS 매개변수, 서버에서 제공한 관련 옵션을 함께 설정해야 합니다. 로컬 네트워크를 바꾼 뒤 결과가 크게 달라진다면 먼저 네트워크 차이를 기록하고 문제를 확인하세요. 프로토콜 이름만으로 속도나 안정성을 단정할 수 없습니다.
WireGuard
공개 키와 개인 키, 상대 측 설정으로 암호화 터널을 만드는 프로토콜입니다. 비밀번호만 입력하는 서버 항목과는 매개변수 구성이 다릅니다. 키, 엔드포인트, 터널 관련 설정을 함께 확인하고 공개 키를 일반 비밀번호 항목에 입력하지 마세요. 개인 키는 민감한 정보이므로 설정 일부나 진단 기록을 공유할 때는 반드시 가려야 합니다.
규칙 키워드
매칭 조건 및 기본 규칙
규칙 유형은 ‘무엇을 기준으로 매칭하는지’를, 마지막 정책은 ‘매칭 후 어떻게 처리하는지’를 정합니다. 아래 주소와 도메인은 문법 설명용이며 서버나 구독 출처가 아닙니다.
DOMAIN
도메인 하나를 정확히 매칭합니다. 예: DOMAIN,example.com,PROXY. 이 규칙은 example.com과 매칭되지만 하위 도메인 관계만으로 모든 하위 도메인이 자동 포함되지는 않습니다. 도메인 전체 범위를 적용하려면 DOMAIN-SUFFIX를 고려하고, 앞에 있는 규칙이 먼저 매칭되지 않는지도 확인하세요.
DOMAIN-SUFFIX
지정한 도메인과 그 하위 도메인을 매칭합니다. 예: DOMAIN-SUFFIX,example.com,PROXY. 도메인 계층의 경계를 기준으로 매칭하며, 비슷한 문자열이 아무 데나 포함되어 있는지를 찾는 방식은 아닙니다. 같은 도메인 범위에 정책을 통일할 때 적합합니다. 특정 하위 도메인에 예외를 적용하려면 더 구체적인 규칙을 앞에 두세요.
DOMAIN-KEYWORD
도메인에 지정한 문자열이 포함되어 있는지 확인해 매칭합니다. 예: DOMAIN-KEYWORD,ads,REJECT. 키워드가 완전한 도메인 계층을 이룰 필요가 없으므로 의도하지 않은 도메인까지 매칭될 수 있습니다. 짧은 키워드를 사용할 때는 특히 매칭 기록을 확인해 문자열이 비슷하다는 이유만으로 관련 요청으로 오인하지 않도록 하세요.
GEOIP
IP 지리 데이터베이스의 지역 분류를 기준으로 매칭합니다. 예: GEOIP,CN,DIRECT. 데이터베이스의 분류가 기기의 실제 위치를 의미하지 않으며 웹사이트 운영자의 위치를 알려주는 것도 아닙니다. 대상이 CDN을 사용하거나 DNS 결과가 바뀌면 매칭 결과도 달라질 수 있으므로 문제를 확인할 때 실제 대상 IP를 확인해야 합니다.
IP-CIDR
IPv4 주소와 프리픽스 길이로 네트워크 대역을 지정하고 대상 주소를 매칭합니다. 예: IP-CIDR,192.168.0.0/16,DIRECT. 슬래시 뒤의 숫자는 네트워크 범위를 정하며 서버 포트가 아닙니다. 로컬 네트워크 규칙을 작성하기 전에 실제 대역을 확인해 범위를 지나치게 넓게 지정하여 다른 정책을 적용하려던 연결까지 포함하지 않도록 하세요.
IP-CIDR6
IPv6 주소 대역을 매칭하는 키워드입니다. 예: IP-CIDR6,2001:db8::/32,DIRECT. 주소는 문서 설명용 예시입니다. IPv4와 IPv6는 각각 확인해야 하며, IPv4 규칙이 있다고 해서 IPv6 연결도 매칭되는 것은 아닙니다. 같은 도메인인데 처리 결과가 다르면 실제로 사용 중인 주소 유형을 확인하세요.
USER-AGENT
User-Agent 정보를 가져올 수 있는 경우 그 내용을 기준으로 매칭하는 규칙 키워드입니다. 모든 앱을 식별하는 방식은 아니며, 암호화된 요청에서 관련 정보를 항상 확인할 수 있다고 가정해서는 안 됩니다. 매칭되지 않는 문제를 확인할 때는 먼저 요청에 사용할 수 있는 정보가 있는지, 그다음 규칙 조건이 올바른지 살펴보세요.
FINAL
앞선 규칙에 매칭되지 않은 연결에 기본 정책을 지정합니다. 예: FINAL,PROXY. 보통 Rule 목록의 마지막에 두며 도메인이나 네트워크 대역 조건을 추가로 입력할 필요는 없습니다. FINAL을 구체적인 규칙보다 앞에 두면 뒤에 있는 규칙이 매칭될 기회를 잃을 수 있으므로 규칙 순서를 확인해야 합니다.
정책 및 매칭 순서
매칭 후 처리 방식
대문자로 표기된 PROXY, DIRECT, REJECT는 규칙 정책입니다. Global Routing의 인터페이스 모드와 혼동하지 마세요.
PROXY
규칙에 매칭된 연결을 프록시로 처리합니다. 실제 출구는 현재 프록시 선택과 구성에 따라 달라집니다. PROXY는 처리 방향만 지정하며 서버 주소, 인증 정보, 작동 여부를 보장하지 않습니다. 로그에 PROXY 매칭이 표시되는데도 접속이 안 되면 선택된 서버, 프로토콜 매개변수, 연결 상태를 확인하세요.
DIRECT
규칙에 매칭된 연결을 프록시 서버를 거치지 않고 대상에 직접 연결합니다. DNS를 건너뛴다는 뜻도 아니며 현재 로컬 네트워크에서 대상에 반드시 접속할 수 있다는 의미도 아닙니다. 직접 연결은 실패하고 프록시 연결은 정상이라면 규칙 순서만으로 모든 문제를 설명하려 하지 말고 로컬 네트워크, DNS 결과, 대상 상태를 함께 확인하세요.
REJECT
규칙에 매칭된 연결을 거부합니다. 명확히 필요하지 않은 요청을 차단할 때 주로 사용합니다. 정책이 연결을 거부하는 경우와 서버 시간 초과는 다릅니다. 전자는 정책에 따른 의도적인 동작이고, 후자는 네트워크나 매개변수 문제일 수 있습니다. 정상 기능에 문제가 생기면 모든 규칙을 한꺼번에 삭제하기보다 매칭된 거부 규칙을 찾아 조건을 좁히거나 예외를 추가하세요.
첫 번째 매칭
규칙은 위에서 아래로 확인하며, 조건에 맞는 첫 번째 규칙이 일반적으로 연결 정책을 결정하고 이후 규칙은 선택에 참여하지 않습니다. 규칙이 더 구체적이라고 해서 자동으로 우선순위가 높아지는 것은 아니며 위치도 중요합니다. 구체적인 예외를 앞에 두고 범위가 넓은 규칙을 뒤에 둔 다음, 마지막에 FINAL로 기본 처리를 지정하세요.
구독 및 Config 파일
출처, 구성 및 DNS
서버 정보는 ‘어디에 연결할지’를, 구성은 ‘어떤 방식으로 처리할지’를 정합니다. 가져오기에 성공한 뒤에도 현재 선택 항목, 활성화된 구성, 실제 연결 상태를 확인해야 합니다.
구독
URL을 통해 사용자가 이미 보유한 서버 항목을 가져오고 업데이트하는 방식입니다. 링크는 사용자가 자신의 서비스 제공업체에서 받아야 합니다. 구독 주소에는 접속 자격 증명이 포함될 수 있으므로 민감 정보로 취급하고 공개 스크린샷에 노출하지 마세요. 서버 목록 업데이트가 Config의 분할 라우팅 규칙 업데이트를 뜻하지는 않으므로 각각 확인해야 합니다.
Subscribe
구독 소스를 추가할 때 사용하는 유형입니다. URL에는 계정 관리 웹페이지가 아니라 사용자가 이미 보유한 전체 구독 주소를 입력해야 합니다. 예시 https://example.com/sub?token=xxxx는 형식 설명용이며 연결에 사용할 수 없습니다. 저장한 뒤 예상한 서버 항목이 생성됐는지 확인하고, 복사 과정에서 공백이 들어가거나 쿼리 매개변수가 잘리지 않았는지도 살펴보세요.
Config 파일
연결 동작과 규칙을 구성하는 텍스트 파일입니다. 일반적인 섹션에는 [General], [Rule], [Host], [URL Rewrite]가 있습니다. 섹션마다 역할이 다르므로 규칙을 파일 끝에 임의로 추가하지 말고 해당 위치에 넣어야 합니다. 가져온 뒤에는 현재 활성화된 항목을 확인하고, 수정하기 전에 기존 구성을 보관해 비교하거나 복원할 수 있도록 하세요.
DNS
도메인을 IP 주소로 변환하는 메커니즘으로, 여러 네트워크 연결을 설정하기 전에 필요한 과정입니다. 변환 성공 여부와 반환되는 주소는 연결 대상에 영향을 주며 IP 기반 규칙의 판정에도 영향을 줄 수 있습니다. 도메인 접속에 실패하면 여러 설정을 한꺼번에 바꾸지 말고 DNS 문제와 프록시 연결 문제를 나누어 확인하세요.
URL Rewrite
조건에 따라 요청 URL을 처리하는 설정 영역으로, Rule에서 연결 출구를 선택하는 규칙과는 역할이 다릅니다. 요청이 조건을 충족하는지, 관련 정보를 처리할 수 있는지에 따라 적용 여부가 달라지므로 모든 암호화 요청을 바로 변경할 수 있다고 가정해서는 안 됩니다. 직접 연결과 프록시 중 어느 쪽으로 보낼지 조정하려는 경우에는 URL Rewrite 규칙을 추가하기보다 먼저 Rule을 확인하세요.
순서에 따라 설정해야 한다면 사용 안내부터 확인하세요. 규칙 결과가 예상과 다르면 현재 구성과 매칭 기록을 먼저 보관한 다음 항목별로 조정하세요.