이 글은 Shadowrocket에 직접 구독을 가져온 사용자를 위한 안내입니다. 먼저 Connectivity Test로 현재 연결할 수 없는 항목을 걸러낸 뒤, 같은 네트워크에서 반복 테스트하고 이용하려는 웹사이트와 출구 지역, 프로토콜 전송 조건을 함께 살펴보세요. 마지막으로 실제 웹 탐색과 지속 전송으로 확인해야 하며, 목록에서 숫자가 가장 낮은 항목을 곧바로 선택해서는 안 됩니다. 기존 설정을 사용하는 방법만 안내하며 노드나 구독을 제공·판매·추천하지 않습니다.
1. 테스트 대상과 현재 라우팅 확인
노드는 기존 설정에 포함된 연결 엔드포인트로, 보통 서버 주소와 포트, 프로토콜, 인증 매개변수로 구성됩니다. 구독은 이러한 항목을 업데이트하는 출처입니다. 노드 이름에 표시된 지역, 배율, 용도는 라벨일 뿐 클라이언트가 측정한 결과가 아닙니다. 구독을 새로고침하면 주소나 매개변수가 바뀔 수 있으므로 비교 전에 목록 업데이트가 완료됐는지 확인하고, 현재 사용할 수 있는 설정을 백업용으로 남겨 두세요.
아래 절차는 iPhone / iPad의 Home, Config, Settings 화면을 기준으로 합니다. 다른 플랫폼은 화면 배치가 다를 수 있으므로 버튼 위치를 그대로 따라 해서는 안 됩니다. 테스트 전에는 ‘어떤 노드를 선택했는지’와 ‘요청이 실제로 어떤 정책을 따랐는지’를 구분해야 합니다. Global Routing이 Direct이면 실제 웹 탐색은 보통 선택한 프록시 노드를 사용하지 않습니다. Config를 사용하면 현재 설정의 규칙에 따라 요청이 처리됩니다.
- Proxy: 프록시를 통한 일괄 연결 테스트에 사용합니다. 적용 중인 정책이 자동으로 선택된 다른 항목이 아니라 테스트 대상 노드를 가리키는지 확인하세요.
- Direct: 현재 네트워크에서 직접 연결합니다. 선택한 프록시 노드의 실제 접속 성능을 확인하는 용도로 사용할 수 없습니다.
- Config: 현재 Config의 분할 라우팅 규칙을 따릅니다. 그 안의 DIRECT, REJECT 또는 다른 정책에 따라 테스트 웹사이트의 경로가 달라질 수 있습니다.
- Scene: 설정된 장면별 동작을 적용합니다. 결과를 비교하기 전에 장면에서 실제로 사용하는 라우팅과 설정을 확인하세요.
2. Connectivity Test 결과 읽는 법
Connectivity Test는 웹페이지 전체 로딩 테스트도, 지속 다운로드 속도 측정도 아닙니다. 결과는 선택한 테스트 방식과 대상, 현재 네트워크에 따라 달라집니다. TCP 기반 테스트는 주로 연결 설정에 걸리는 시간을 나타내며, HTTP 기반 테스트에는 프록시 협상과 TLS, 대상 서버의 응답 시간이 포함될 수 있습니다. 여기서 말하는 ‘핸드셰이크 속도’는 짧은 연결 확인 결과를 요약한 것으로, 앱을 연 뒤 기다리는 전체 시간과 같지 않습니다.
한 번 낮은 밀리초 값이 나왔다면 해당 테스트가 그때 빠르게 완료됐다는 뜻일 뿐입니다. 이를 Mbps로 환산할 수 없으며 동영상의 지속 재생, 파일 다운로드, 장시간 연결의 안정성을 보장하지도 않습니다. 반대로 Timeout은 제한 시간 안에 테스트가 완료되지 않았다는 뜻입니다. 테스트 대상이나 네트워크 경로, 포트, 설정 매개변수가 원인일 수 있으므로 이 결과만으로 서버가 영구적으로 작동하지 않는다고 단정할 수 없습니다.
- 비교 전에 테스트 방식과 대상을 고정하세요. TCP와 HTTP 결과를 같은 순위표에서 비교하면 안 됩니다.
- 후보마다 최소 3회 반복해 중간값 수준과 편차, 시간 초과 횟수를 기록하고 가장 빠른 결과만 기록하지 마세요.
- 기기 백그라운드 트래픽으로 업로드나 다운로드 대역폭이 포화되지 않도록 시스템 업데이트, 클라우드 동기화, 대용량 파일 전송을 일시 중지하세요.
- 사용한 Wi-Fi 또는 셀룰러 네트워크를 기록하세요. 접속 네트워크를 바꾸면 이전 순위는 참고 기록으로만 볼 수 있습니다.
3. 기존 목록에서 후보를 고르는 5단계
먼저 연결 상태를 확인한 뒤 실제 용도로 테스트하세요. 노드를 바꿀 때마다 DNS와 규칙, 프로토콜 매개변수를 함께 수정하면 결과가 달라져도 어떤 변경이 영향을 줬는지 알기 어렵습니다. 아래 절차에서는 후보 두 개만 남겨도 충분하며 구독의 모든 항목을 하나씩 장시간 다운로드 테스트할 필요는 없습니다.
-
목록 확인
Home으로 이동해 구독 업데이트가 완료됐는지 확인하세요. 테스트할 항목의 서버 주소와 포트, 프로토콜 정보가 모두 있는지 살펴보세요. 이름이 중복되면 연결 매개변수로 구분하고, 이름만 보고 같은 경로라고 추측하지 마세요.
-
조건 고정
같은 Wi-Fi 또는 셀룰러 네트워크를 유지하고 Home → Global Routing에서 현재 선택된 모드를 기록하세요. 테스트 중에는 Config를 바꾸지 마세요. Settings → On Demand가 활성화되어 있다면 테스트 도중 연결 상태를 바꾸는 규칙이 없는지 먼저 확인하세요.
-
반복 테스트
Home에서 Connectivity Test를 열고 같은 방식으로 3회 테스트하세요. 연속해서 결과가 나오고 편차가 작은 항목을 우선 남기고 Timeout 횟수도 기록하세요. 한 번 실패했다고 바로 삭제하지 마세요.
-
실제 접속 확인
Home에서 후보를 선택한 뒤 연결을 켜고 같은 웹사이트를 열어 확인하세요. 필요하면 잠시 Global Routing → Proxy를 사용하되 정책이 해당 후보를 가리키는지 확인하세요. 첫 화면과 이후 페이지, 실제 사용하려는 기능이 정상인지 기록하세요.
-
분할 라우팅 복원
테스트가 끝나면 원래 Global Routing과 On Demand 설정으로 되돌리세요. 현재 네트워크에서 사용할 수 있다고 확인된 항목을 백업용으로 남겨 두고, 네트워크를 바꾸거나 구독을 업데이트한 뒤에는 다시 확인하세요. 오늘 결과를 장기적인 순위로 간주하지 마세요.
4. 지역은 이용 서비스와 접속 네트워크를 기준으로 판단
지리적 거리는 경로에 영향을 주는 요소 중 하나일 뿐입니다. 기기와 서버 사이에 서로 다른 통신사 간 연결이나 중계 경로, 혼잡한 구간이 있을 수 있으므로 더 가까운 지역으로 표시된 노드가 반드시 지연 시간이 짧은 것은 아닙니다. 서버 이름에 적힌 지역이 최종 출구 IP의 위치와 일치한다는 보장도 없습니다. 서비스는 IP 데이터베이스와 계정 지역, 기기 설정을 함께 참고해 지역을 판단할 수 있습니다.
이용 중인 서비스에서 특정 지역을 요구한다면 먼저 해당 조건을 충족하는 기존 항목을 추린 뒤 안정성을 비교하세요. 테스트 수치를 낮추려고 필요한 서비스 지역을 무시하지 마세요. 계정 기반 서비스는 테스트 중 추가 인증이 발생하지 않도록 지역을 자주 바꾸지 않는 편이 좋습니다.
같은 후보를 두 가지 접속 네트워크에서 각각 확인
Wi-Fi에서 테스트
- 먼저 Wi-Fi에서 기본 네트워크 서비스에 정상적으로 접속할 수 있는지 확인하세요.
- 같은 액세스 포인트를 유지하고 테스트 중 다른 방으로 이동해 신호가 바뀌지 않도록 하세요.
- 자주 이용하는 시간대의 결과를 기록해 로컬 네트워크 혼잡과 원격 경로의 변동을 구분하세요.
셀룰러 네트워크
- 신호가 비교적 안정적인 장소에서 테스트하고 이동하면서 비교하지 마세요.
- Connectivity Test를 다시 실행하고 Wi-Fi에서의 순위를 그대로 적용하지 마세요.
- 장시간 전송은 데이터를 소모하므로 확인 시간과 데이터 양을 제한하세요.
네트워크별로 다른 후보를 남겨도 됩니다. 모든 접속 환경에 공통으로 적용할 ‘가장 빠른 노드’를 정할 필요는 없습니다.
5. 프로토콜 종류가 결정하는 것과 결정하지 않는 것
프로토콜 이름은 연결 및 전송 방식을 설명할 뿐 속도 등급을 뜻하지 않습니다. 먼저 기존 서버가 요구하는 프로토콜과 매개변수를 충족하는지 확인한 다음, 현재 네트워크에서 해당 전송 방식을 사용할 수 있는지 살펴보세요. 클라이언트에서 유형 이름만 다른 것으로 바꿔도 서버가 자동으로 호환되는 것은 아닙니다. 특히 인증 정보와 TLS, 전송 계층, 서버 포트는 기존 설정과 일치해야 합니다.
| 프로토콜 | 사용 전 확인 사항 | 이 정보만으로 판단할 수 없는 점 |
|---|---|---|
| Shadowsocks | 서버 주소와 포트, 암호화 방식, 비밀번호가 일치해야 합니다. UDP 사용 가능 여부는 양쪽 설정과 네트워크에 따라 달라집니다. | 이름이 짧다고 처리가 더 빠른 것은 아닙니다. |
| VMess | UUID와 전송 방식, TLS 설정을 일치시키세요. 인증 오류가 발생하면 시스템 시간도 확인하세요. | 핸드셰이크에 성공해도 모든 대상 서비스에 접속할 수 있다는 뜻은 아닙니다. |
| VLESS | UUID와 사용하는 전송 방식, 보안 계층 매개변수가 일치해야 합니다. 프로토콜 이름만으로 연결 보호 방식을 판단할 수 없습니다. | 다른 프로토콜과 이름이 다르다는 사실은 속도 순위를 나타내지 않습니다. |
| Trojan | 비밀번호와 TLS 인증서 검증, Server Name 설정이 올바른지 확인하세요. | TLS를 사용한다고 모든 네트워크 제한을 우회할 수 있는 것은 아닙니다. |
| Hysteria2 | QUIC 기반입니다. UDP 경로를 사용할 수 있는지, 인증 및 인증서 매개변수가 올바른지 확인하세요. | 지연 시간이 긴 네트워크에서도 대역폭이 일정하게 보장되지는 않습니다. |
| WireGuard | 키와 Peer, Endpoint, 터널 주소, 라우팅 범위를 확인하세요. 전송에는 UDP가 사용됩니다. | 터널이 연결됐다고 DNS와 모든 라우팅이 올바르다는 뜻은 아닙니다. |
포트 번호만으로 프로토콜을 판별할 수도 없습니다. 예를 들어 TCP 443과 UDP 443은 서로 다른 전송 포트입니다. ‘443’이라고 해서 반드시 Trojan이라고 단정할 수 없으며 네트워크에서 항상 허용된다고 볼 수도 없습니다. 실제 포트는 기존 설정을 따르세요. 지연 시간을 줄이려고 임의로 변경하거나 연결에 성공하려고 인증서 오류가 발생했을 때 검증을 끄지 마세요.
6. 규칙과 자동 연결로 인한 오판 방지
자주 발생하는 오해는 ‘노드를 바꿨는데 웹페이지가 달라지지 않는다’는 것입니다. Config 모드에서는 정상적인 결과일 수 있습니다. 도메인에 DIRECT가 적용됐거나 규칙이 다른 정책 그룹을 지정했을 수 있습니다. 규칙은 일반적으로 설정된 순서에 따라 일치 여부를 확인합니다. DOMAIN-SUFFIX는 도메인 접미사, IP-CIDR은 IP 주소 대역에 적용되며 GEOIP는 IP 위치 정보에 따라 판단합니다. FINAL은 다른 규칙에 해당하지 않을 때 적용되는 최종 규칙입니다. 노드를 선택해도 모든 규칙이 무시되지는 않습니다.
라우팅 확인 기록
- 항목
- Home → Global Routing
- 설정
- Config에서 현재 활성화된 설정
- 확인할 키워드
- DOMAIN-SUFFIX / IP-CIDR / GEOIP / FINAL
- 확인 사항
- 대상 요청이 테스트할 노드가 포함된 정책을 따르는지
웹페이지 결과의 원인을 노드로 돌리기 전에 규칙이 지정하는 경로부터 확인하세요.
연결 상태 확인
- 항목
- Settings → On Demand
- 기능
- 설정된 조건에 따라 연결 동작을 실행
- 확인 위치
- Home의 연결 스위치와 현재 네트워크
- 테스트 종료 후
- 기존 자동 연결 설정 복원
On Demand는 연결이 실행되는 조건을 관리하며 노드 속도 측정이나 품질 순위 기능이 아닙니다.
웹사이트 하나만 접속되지 않으면 먼저 해당 사이트에 적용되는 정책과 DNS 결과, 서비스 상태를 확인하세요. 모든 후보가 동시에 실패하면 로컬 네트워크와 구독 매개변수, 현재 연결 상태부터 확인합니다. 모든 설정을 한꺼번에 초기화하지 마세요. 한 번에 한 항목만 바꾸고 결과를 기록해야 같은 문제를 재현하고 원인을 파악할 수 있습니다. 자세한 절차는 연결 문제 해결 가이드를 참고하세요.
7. 지연 시간 테스트와 실제 사용에 관한 자주 묻는 질문
지연 시간이 가장 짧은데 웹페이지는 왜 더 느리게 열리나요?
먼저 Global Routing에서 요청이 실제로 어디로 가는지 확인한 뒤, 같은 페이지에서 두 후보를 비교하세요. 페이지를 표시하려면 DNS와 TLS, 여러 리소스 요청, 콘텐츠 전송이 필요합니다. 짧은 연결 테스트에는 이 과정이 포함되지 않습니다. 브라우저 캐시도 재방문 결과에 영향을 주므로 캐시된 페이지와 처음 로드하는 페이지를 비교하지 마세요.
Timeout으로 표시되지만 웹페이지는 열립니다. 삭제해야 하나요?
바로 삭제할 필요는 없습니다. 노드와 네트워크를 그대로 둔 채 Connectivity Test의 방식과 대상을 확인한 뒤 반복 테스트하세요. 특정 테스트 대상에 접속하지 못해도 모든 서비스에 접속할 수 없는 것은 아닙니다. 웹 요청이 DIRECT나 다른 정책이 아니라 실제 해당 노드를 거치는지도 확인하세요.
같은 노드가 저녁에 느려졌습니다. 프로토콜을 바꿔야 하나요?
먼저 같은 시간대에 백업 후보와 비교하고 로컬 네트워크가 혼잡한지 확인하세요. 서버에서 해당 프로토콜 설정을 제공하는 경우에만 프로토콜을 비교할 수 있습니다. Type을 임의로 바꾸지 마세요. ‘테스트는 안정적이지만 지속 전송이 느림’ 또는 ‘핸드셰이크도 자주 시간 초과됨’처럼 기록하면 단순히 ‘느림’이라고 적는 것보다 원인 파악에 도움이 됩니다.
셀룰러 네트워크로 바꾸자 모든 후보가 불안정해졌습니다. 어떻게 해야 하나요?
먼저 셀룰러 네트워크 자체가 정상인지 확인한 다음 Home에서 Connectivity Test를 다시 실행하세요. UDP에 의존하는 기존 설정에서만 문제가 발생한다면 현재 네트워크에서 UDP를 사용할 수 있는지 확인하세요. 구독에 다른 전송 유형이 이미 있다면 비교 대상으로 활용할 수 있습니다. 특정 네트워크의 제한을 모든 환경에서 해당 프로토콜을 사용할 수 없다는 뜻으로 받아들이지 마세요.
선택 순서는 다음과 같이 정할 수 있습니다. 이용 조건 충족, 연결 가능, 반복 결과 안정성, 실제 용도 확인. 지연 시간은 후보를 좁히는 기준 중 하나일 뿐 최종 판단은 아닙니다.