이 글은 Shadowrocket에 본인이 이용 중인 구독을 이미 추가한 사용자를 위한 안내입니다. 연결과 규칙이 실제로 적용되는지 확인한 뒤, 같은 네트워크에서 지연 시간의 변동, 대상 서비스에 필요한 지역, 프로토콜 호환성을 비교하세요. 가장 낮은 지연 시간만 보고 선택하지 않도록 반복해서 비교할 수 있는 방법을 소개합니다. 구독 링크는 이용 중인 서비스 제공업체에서 받으세요.
1. 테스트 조건을 고정한 뒤 기존 노드 비교하기
노드 이름에는 보통 지역, 프로토콜 또는 서비스 제공업체가 붙인 표기가 포함되지만, 이름만으로 성능을 판단할 수는 없습니다. 먼저 구독이 최신 상태인지, 선택한 항목의 매개변수가 모두 입력되어 있는지 확인한 다음 네트워크와 테스트할 웹사이트를 고정하세요. Wi-Fi와 셀룰러 네트워크를 번갈아 쓰거나 서로 다른 웹페이지로 비교하면 차이가 노드 때문인지 로컬 네트워크 때문인지 알기 어렵습니다.
-
구독 확인
Home에서 기존 구독과 항목, 만료일을 확인하세요. 다시 추가해야 한다면 Home → + → Type → Subscribe로 이동해 서비스 제공업체에서 받은 링크를 입력하고 저장합니다. 구독을 업데이트한 뒤 비교를 시작하고, 만료된 항목은 비교 대상에서 제외하세요.
-
네트워크 고정
같은 Wi-Fi 또는 같은 셀룰러 네트워크를 계속 사용하고, 다른 기기의 대용량 데이터 전송은 일시 중지하세요. Settings → On Demand에서 온디맨드 연결 조건도 확인해 테스트 중 네트워크 조건 변화로 연결 상태가 바뀌지 않도록 합니다.
-
라우팅 확인
Home → Global Routing에서 현재 Proxy, Direct, Config 또는 Scene 중 무엇을 사용하는지 확인하세요. 기존 설정을 기록해 두고, Proxy로 임시 비교했다면 끝난 뒤 원래 설정으로 되돌려 평소의 트래픽 분할 방식까지 바뀌지 않도록 합니다.
-
항목별 재테스트
Home에서 비교할 항목 하나를 선택해 연결한 다음 Connectivity Test를 실행하고 같은 페이지에 접속하세요. 후보마다 세 차례 연속으로 확인해 연결 여부, 첫 화면이 뜨기까지 걸리는 시간, 사용 중 멈춤 현상을 기록하세요. 밀리초 수치 하나만 기록하지 마세요.
기존 구독을 업데이트하면 항목 수, 주소 또는 매개변수가 달라질 수 있습니다. 업데이트 전후에 선택한 항목을 각각 기록해 실제 선택이 바뀌었는데도 예전 결과를 그대로 적용하는 일이 없도록 하세요. 구독 주소의 token은 접근 자격 증명입니다. 공개 스크린샷이나 공유 로그, 테스트 기록에 포함하지 마세요.
2. Ping, 연결 지연 시간, 실제 로딩 속도는 서로 다른 지표
일상적으로 ‘Ping’은 지연 시간을 통칭하는 말로 쓰이지만, 테스트마다 측정하는 경로는 다릅니다. ICMP 탐색, TCP 연결 설정, 프록시를 통한 테스트 주소 접속은 각각 확인하는 단계가 다릅니다. 비교하기 전에 테스트 방법과 대상 주소를 확인하세요. 같은 목록의 수치도 테스트 조건이 같을 때만 직접 비교할 수 있습니다.
지연 시간은 탐색 요청의 왕복이나 연결 과정에 걸리는 시간을 나타내고, 처리량은 지속적인 데이터 전송 능력을 나타냅니다. 웹페이지 로딩에는 DNS, 연결 설정, TLS 핸드셰이크, 서버 응답, 여러 리소스 요청도 영향을 줍니다. 지연 시간이 짧으면 일부 대기 시간이 줄어들 수 있지만, 대용량 파일 전송이 더 빠르다는 뜻은 아니며 대상 웹사이트가 해당 출구 주소를 허용한다는 보장도 없습니다.
| 관찰 결과 | 알 수 있는 점 | 다음 확인 사항 |
|---|---|---|
| 탐색 결과 지연 시간이 짧음 | 이번 테스트 경로의 응답이 빠름 | 실제로 이용할 웹사이트를 열어 첫 화면과 연속 로딩을 확인 |
| 탐색은 시간 초과지만 웹페이지는 이용 가능 | 탐색 방법이나 테스트 대상이 적절하지 않을 수 있음 | 테스트 방법을 확인하고 같은 대상을 기준으로 다시 비교 |
| 연결은 성공했지만 계속 멈춤 | 연결이 완료되어도 이후 데이터 전송이 안정적이라는 뜻은 아님 | 로컬 네트워크 혼잡을 배제한 뒤 패킷 손실과 서버 부하를 비교 |
| 일반 웹페이지는 정상인데 특정 사이트만 실패 | 대상 사이트, DNS 또는 규칙 문제일 수 있음 | 요청에 적용된 규칙과 실제 출구를 확인 |
예를 들어 후보 A의 측정값이 세 차례에 걸쳐 45, 260, 시간 초과이고 후보 B가 85, 88, 91밀리초라고 가정해 보겠습니다. 이 예시에서는 B의 변동 폭이 더 작지만, 실제 대상 서비스에 접속해 확인해야 합니다. 이는 실측 성능 순위가 아니며 특정 지역이나 프로토콜이 항상 더 빠르다는 의미도 아닙니다. 우연히 나온 최저값보다 반복해서 확인한 결과를 기준으로 선택하세요.
3. 지역 선택 시 입구, 출구, 대상 서비스를 구분하기
노드에 표시된 지역은 출구를 가리킬 수도 있고, 서비스 제공업체가 붙인 이름에 불과할 수도 있습니다. 기기에서 입구에 연결한 뒤 트래픽이 서비스 제공업체의 네트워크를 거쳐 출구에 도달하고, 마지막으로 대상 서비스에 접속합니다. 지리적 거리는 이 과정의 일부만 설명합니다. 지도상 가까운 곳이라고 네트워크 경로가 더 짧다는 보장은 없으며, 노드 이름의 지역 표기도 실제 출구에 관한 서비스 제공업체의 안내를 대신할 수 없습니다.
지역별 비교: 일반 웹 이용과 특정 지역 서비스
일반 웹 이용
- 기존 구독에서 출구 지역이 서로 다른 후보 두 개를 선택합니다.
- 같은 네트워크에서 비슷한 시간대에 같은 페이지들을 방문합니다.
- 지도상 거리보다 지속적인 이용 가능 여부와 지연 시간의 변동을 우선 기록합니다.
특정 지역 서비스
- 먼저 대상 서비스의 지역 요건과 이용 약관을 확인합니다.
- 서비스 제공업체에 해당 항목의 실제 출구 지역을 확인합니다.
- 대상 요청이 실제로 해당 출구를 이용하는지 확인하고, 대상 서비스의 응답을 기준으로 판단합니다.
지역은 선택 기준일 뿐 이용 가능성을 보장하지 않습니다. 같은 지역의 서로 다른 회선도 각각 확인해야 합니다.
지역 판단에는 계정 정보, 기기의 위치 정보, 기존 세션, 서비스 자체 정책도 영향을 줄 수 있습니다. 따라서 ‘지역을 바꿨는데도 기존 지역으로 표시됨’만으로 Shadowrocket의 연결 실패라고 단정할 수는 없습니다. 먼저 라우팅과 출구를 확인한 뒤 대상 서비스의 정상적인 절차에 따라 세션을 다시 설정하세요. 원인을 파악하는 대신 항목을 계속 바꾸지는 마세요.
4. 서버 매개변수와 네트워크 조건에 맞는 프로토콜 선택
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 서로 다른 프로토콜 옵션이지 속도 등급이 아닙니다. 서버에서 해당 프로토콜을 실제로 지원하고 필요한 매개변수를 모두 제공해야 클라이언트 설정을 사용할 수 있습니다. Type을 다른 이름으로 바꿔도 기존 서버가 새 프로토콜을 지원하게 되지는 않습니다. 포트 번호만으로 프로토콜을 판단할 수도 없습니다.
| 프로토콜 | 우선 확인할 매개변수 | 비교 시 유의 사항 |
|---|---|---|
| Shadowsocks | 서버, 포트, 암호화 방식, 비밀번호 | 매개변수가 서버 설정과 일치해야 합니다. 주소를 확인하는 것만으로는 충분하지 않습니다. |
| VMess / VLESS | UUID, 전송 방식, TLS 및 관련 전송 매개변수 | 인증 방식이 서로 다르므로 Type을 그대로 바꿔 사용할 수 없습니다. |
| Trojan | 비밀번호, 포트, TLS, SNI | SNI는 인증서 및 서버 설정과 일치해야 합니다. 매개변수를 바로잡는 대신 검증을 끄면 안 됩니다. |
| Hysteria2 | 인증 정보, TLS, 서버에서 요구하는 기타 매개변수 | UDP 기반 QUIC를 사용하므로 네트워크의 UDP 제한이 연결에 영향을 줍니다. |
| WireGuard | PrivateKey、PublicKey、Endpoint、Address、MTU | UDP를 사용합니다. 키, 주소, 라우팅 조건이 모두 올바른지 확인해야 합니다. |
예를 들어 한 항목의 서버 포트가 8443으로 설정되어 있다면 서비스 제공업체가 안내한 8443을 입력해야 합니다. HTTPS에서 흔히 쓰는 포트가 443이라는 이유로 임의로 바꾸면 안 됩니다. Hysteria2와 WireGuard가 모두 UDP를 사용한다고 해서 같은 네트워크에서 결과가 반드시 같지는 않습니다. 서버 위치, 구현 방식, 회선 부하, 매개변수도 서로 다릅니다.
- 같은 프로토콜에서 특정 항목만 실패하면 먼저 해당 항목의 주소, 포트, 인증 정보, 서비스 상태를 확인하세요.
- 같은 네트워크에서 UDP 프로토콜 항목 여러 개가 실패하면, 사용 권한이 있는 다른 네트워크에서 재테스트해 UDP 제한 여부를 확인할 수 있습니다.
- 모든 프로토콜로 접속할 수 없다면 먼저 로컬 네트워크, 시스템 시간, 연결 권한, 현재 라우팅을 확인하세요. 곧바로 프로토콜이 호환되지 않는다고 판단하지 마세요.
5. 노드를 선택해도 사용되지 않는 상황을 막으려면 Global Routing 확인
Home에서 항목을 선택해도 모든 요청이 해당 항목을 거치는 것은 아닙니다. 요청의 처리 방식은 Global Routing에서 결정합니다. Config에서는 규칙에 따라 정책이나 정책 그룹이 지정될 수도 있습니다. 노드별 차이를 점검하기 전에 대상 요청이 실제로 어디로 향하는지 확인해야 합니다. 그렇지 않으면 계속 직접 연결 경로를 측정할 수 있습니다.
Config
권장현재 구성된 규칙에 따라 요청 경로를 결정합니다. 먼저 Config에서 적용 중인 구성을 확인한 다음 대상 도메인에 적용된 규칙과 정책을 확인하세요. 규칙에 일치하지 않은 요청이 모두 직접 연결된다고 단정할 수는 없습니다.
적합한 경우: 분할 라우팅 구성이 올바르게 설정된 상태로 일상적으로 이용할 때
Proxy
프록시 처리 대상 요청에 프록시 모드를 적용해 규칙별 분할 라우팅에서 생기는 변수를 줄일 수 있습니다. 다만 시스템과 구성에서 제외한 트래픽이 있을 수 있으므로 기기의 모든 트래픽이 프록시를 거친다는 증거로 볼 수는 없습니다.
적합한 경우: 프록시 경로를 임시로 비교한 뒤 원래 설정으로 되돌릴 때
Direct
직접 연결 경로를 사용합니다. Home에서 노드를 선택했더라도 해당 노드의 접속 성능을 평가할 수는 없습니다. 로컬 네트워크를 비교하는 조건으로 활용할 수 있습니다.
적합한 경우: 프록시를 거치지 않을 때 대상에 접속할 수 있는지 확인할 때
Scene
설정한 Scene 조건에 따라 해당 설정을 적용합니다. 테스트 전에 현재 어떤 Scene이 적용되는지 확인하세요. 네트워크를 바꿔도 같은 라우팅 조건이 유지된다고 가정하지 마세요.
적합한 경우: Scene을 명확하게 설정해 두고 환경에 따라 전환해 사용하는 경우
규칙은 일반적으로 위에서 아래로 순서대로 적용되며, FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 아래 내용은 문법 설명용이므로 기존 구성을 통째로 덮어쓰면 안 됩니다. PROXY의 실제 대상은 현재 설정을 확인해야 합니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY이 예시에서는 example.com과 하위 도메인이 먼저 DOMAIN-SUFFIX에 일치합니다. IP-CIDR은 지정된 주소 대역과 일치하며, no-resolve는 해당 규칙을 위해 도메인 이름을 별도로 조회하지 않는다는 뜻입니다. 다음으로 GEOIP를 확인하고, 마지막으로 FINAL이 나머지 요청을 처리합니다. 대상이 앞쪽의 DIRECT 규칙에 일치한다면 Home에서 노드만 바꿔도 접속 경로는 대개 달라지지 않습니다.
6. 자주 발생하는 현상과 재테스트 방법
지연 시간이 가장 짧은 노드에서 동영상이 끊기는 이유는 무엇인가요?
짧은 지연 시간은 테스트 단계의 응답 시간만 보여 줍니다. 같은 네트워크에서 동일한 동영상을 같은 화질로 재생해 후보 두 개의 연속 재생과 버퍼링 후 재개 상태를 각각 확인하세요. 백그라운드에서 대용량 데이터를 전송하는 작업도 일시 중지합니다. 특정 시간대에만 끊긴다면 해당 시간대를 기록해 다시 비교하세요. 한 번의 탐색 결과만으로 지속적인 전송 성능을 판단할 수는 없습니다.
Home에 시간 초과가 표시되면 노드가 이미 만료된 건가요?
먼저 테스트 방법과 대상을 확인한 다음 해당 항목을 선택해 연결하고 Home → Connectivity Test를 실행한 뒤 실제 대상에 접속해 보세요. 테스트는 실패했지만 서비스는 정상이라면 탐색 조건을 확인하세요. 둘 다 실패하면 구독 업데이트 여부, 주소, 포트, 인증 매개변수를 확인합니다.
노드를 바꿨는데 웹페이지 속도와 지역이 그대로인가요?
먼저 Home → Global Routing이 Direct로 설정되어 있는지 확인하세요. Config를 사용한다면 Config에서 대상이 DIRECT 또는 고정 정책 그룹에 일치하는지 확인합니다. 대상에 다시 연결한 뒤 결과를 살펴보세요. 기존의 장시간 연결은 항목을 선택해도 즉시 새로 설정되지 않을 수 있습니다. 목록에서 항목이 강조 표시된 것만으로 실제 출구를 판단하지 마세요.
Wi-Fi에서는 되는데 셀룰러 네트워크에서 같은 항목이 실패하면 어떻게 하나요?
먼저 셀룰러 데이터 연결 자체가 되는지 확인한 뒤 Settings → On Demand에서 네트워크 조건을 점검하고 현재 Global Routing과 Scene을 확인하세요. 매개변수는 그대로인데 네트워크를 바꾸자마자 실패한다면 프로토콜, 발생 시간, 오류 증상을 기록하고 서비스 제공업체에 해당 네트워크에서 접속할 수 있는지 문의하세요. 비밀번호나 키를 반복해서 바꾸지 마세요.
7. 최저 수치만 좇기보다 재테스트 결과를 기록하기
자주 사용할 항목 하나와 검증을 마친 예비 항목 하나를 남겨 둘 수 있습니다. 이는 기존 구독을 정리하는 방법일 뿐, 특정 서비스를 추천하는 내용은 아닙니다. 기록에는 네트워크, 테스트 시간, 프로토콜, 출구 안내, 연속 테스트 결과, 실제 앱 사용 경험을 포함하세요. 구독 링크 전체, 비밀번호, PrivateKey 등 인증 정보는 기록하지 마세요.
- 연결 단계: 연결에 성공하는지, Connectivity Test를 반복해서 통과하는지 확인합니다.
- 사용 경험: 같은 웹페이지의 첫 화면이 안정적으로 표시되는지, 계속 사용해도 연결이 끊기지 않는지 확인합니다.
- 라우팅 단계: Global Routing, 현재 구성, 대상에 적용된 정책이 서로 일치하는지 확인합니다.
- 재테스트 시점: 네트워크를 바꾸거나 구독을 업데이트했을 때, 또는 문제가 지속될 때 다시 비교합니다. 한 번의 변동만으로 바로 바꿀 필요는 없습니다.
확인 순서는 ‘연결 가능 → 라우팅 정상 → 대상 서비스 이용 가능 → 지속적인 안정성 → 지연 시간 비교’로 유지하세요. 이렇게 하면 매개변수 오류, 규칙 문제, 회선 성능을 구분할 수 있어 모든 접속 문제를 노드 속도 탓으로 돌리지 않게 됩니다.