Shadowrocket 노드 선택 방법: 지연 시간 테스트, 지역과 프로토콜, 낮은 지연 시간이 실제 사용 경험을 보장하지 않는 이유

이 글의 핵심

이 글은 Shadowrocket에 직접 보유한 서비스 제공업체의 설정을 가져온 사용자를 위한 안내입니다. 지연 시간, 처리량, 안정성의 차이를 이해하고 네트워크와 테스트 방식, 라우팅 설정을 통일한 뒤 기존 연결 설정의 지역과 프로토콜을 비교하세요. 목록에서 가장 낮은 숫자가 아니라 실제로 사용할 앱의 작동 여부와 반복 테스트 결과를 기준으로 판단해야 합니다. 이 글에서는 노드나 구독을 제공하거나 판매·추천하지 않습니다.

1. 지연 시간 수치가 측정하는 연결 구간

지연 시간은 보통 밀리초(ms)로 표시하며, 특정 탐색이 완료되는 데 걸린 시간을 나타냅니다. 짧은 상호작용에 관한 수치이지 초당 전송 가능한 데이터량은 아닙니다. Shadowrocket의 테스트 결과는 사용한 테스트 방식과 함께 해석해야 합니다. 같은 연결 설정도 테스트 방식, 대상 또는 현재 네트워크에 따라 결과가 달라질 수 있으므로 모든 수치를 하나의 순위표에 그대로 넣어 비교하면 안 됩니다.

예를 들어 TCP 탐색은 지정된 서버 포트에 TCP 연결을 설정하는 데 걸리는 시간을 주로 보여 줍니다. 포트에 연결할 수 있다고 해서 프로토콜 인증이 성공하거나 원격 서버에서 대상 웹사이트에 정상적으로 접속할 수 있다는 뜻은 아닙니다. 프록시를 통한 HTTP 탐색은 더 많은 구간을 확인하지만, 테스트 URL과 DNS, TLS 핸드셰이크, 응답 방식에도 영향을 받습니다. 테스트 항목 이름만 보고 실제 서비스의 전체 연결 경로를 모두 확인한다고 단정하지 마세요.

확인 방식	주로 확인할 수 있는 내용	이것만으로 확인할 수 없는 내용
ICMP 탐색	대상 호스트의 ICMP 도달 가능 여부와 왕복 시간	프록시 포트와 인증, 대상 웹사이트의 정상 작동 여부. 서버에서 ICMP를 제한할 수도 있습니다.
TCP 탐색	지정된 호스트와 포트에 TCP 연결을 설정할 수 있는지 여부	프록시 프로토콜의 정상 작동, 지속적인 전송 속도 또는 UDP 경로의 정상 여부
프록시를 통한 HTTP 탐색	지정된 테스트 URL에 요청을 보내 완료할 수 있는지와 소요 시간	다른 도메인이나 지역의 콘텐츠, 장시간 연결도 정상적으로 작동하는지 여부
실제 앱 사용	현재 설정에서 대상 페이지, 동영상 또는 통화가 어떻게 작동하는지	시간대와 네트워크가 달라져도 같은 성능이 유지되는지 여부

시간 초과가 반드시 서버가 오프라인이라는 뜻은 아닙니다. 테스트 대상에 접속할 수 없거나 포트가 잘못 입력되었거나 현재 네트워크가 특정 전송 방식을 제한하는 경우, 또는 테스트 방식이 프로토콜과 맞지 않는 경우에도 시간 초과가 발생할 수 있습니다. 반대로 지연 시간이 매우 짧게 표시되더라도 해당 탐색이 빠르게 완료되었다는 뜻일 뿐입니다. 연결한 뒤 실제 앱에서 정상 작동하는지 확인해야 합니다.

2. 테스트 조건을 통일한 뒤 기존 설정 비교하기

먼저 기존 구독 설정을 Home에 정상적으로 가져왔는지, 서버 주소와 포트, 프로토콜 항목이 빠짐없이 입력되었는지 확인하세요. 구독 업데이트는 설정 정보를 동기화할 뿐 서버 대역폭을 높이거나 대상 웹사이트의 제한을 자동으로 해결하지 않습니다. 서비스 제공업체에서 주소나 인증 정보를 변경했다면 먼저 업데이트한 뒤 비교하세요. 각 테스트 사이에 구독 업데이트, 네트워크 전환, 규칙 변경을 동시에 하지 마세요.

네트워크 통일

같은 Wi-Fi 또는 셀룰러 네트워크를 선택하고 대역폭을 사용하는 동기화 작업을 일시 중지하세요. 테스트 중에는 두 네트워크 사이를 전환하지 말고 테스트 시간대를 기록하세요.
설정 확인

Home에서 기존 설정 하나를 선택하고 편집 화면에서 Type, 주소와 포트를 확인하세요. 예를 들어 서버가 TCP 443을 요구한다면 추측으로 8443으로 바꾸면 안 됩니다. 포트는 보유한 서버 설정을 기준으로 해야 합니다.
라우팅 통일

Home → Global Routing으로 이동해 현재 설정이 Config인지 Proxy인지 기록하세요. 규칙의 영향을 분리해서 확인하려면 일시적으로 Proxy를 선택해 비교한 뒤 원래 설정으로 되돌리면 됩니다. Settings → On Demand도 확인해 자동 연결 조건이 테스트 상태를 바꾸지 않도록 하세요.
반복 테스트

Home에서 Connectivity Test를 실행하고 테스트 방식과 대상을 동일하게 유지하면서 후보별로 3~5회 반복하세요. 가장 낮은 수치만 적지 말고 시간 초과 횟수와 일반적인 소요 시간, 최장 소요 시간을 기록하세요.
실제 사용 확인

연결한 뒤 같은 대상을 열어 처음 표시될 때, 계속 로드할 때, 잠시 유휴 상태였다가 다시 사용할 때를 차례로 확인하세요. 예를 들어 후보마다 5분간 관찰하는 등 같은 시간을 적용한 뒤 다음 후보로 넘어가세요.

아래는 기록 방법을 보여 주기 위한 가상 데이터이며, 제품 실측 결과나 실제로 이용할 수 있는 서비스와 관련이 없습니다. 5회 테스트 중 시간 초과가 발생하면 별도로 세어야 하며 평균에 0ms로 포함하면 안 됩니다. 성공한 결과의 중앙값은 단일 이상치의 영향을 줄여 주지만 실패 기록도 함께 남겨야 합니다.

후보 A: 가상 기록

테스트 네트워크: 같은 Wi-Fi, 같은 위치
5회 결과: 38, 41, 시간 초과, 210, 43ms
성공 결과 중앙값: 42ms, 시간 초과 1회 별도 기록
실제 사용 관찰: 5분 동안 로딩이 두 차례 멈춤

최저 수치인 38ms만으로 시간 초과와 큰 변동을 가릴 수는 없습니다.

후보 B: 가상 기록

테스트 네트워크: 후보 A와 조건 동일
5회 결과: 72、75、73、74、76 ms
성공 결과 중앙값: 74ms, 시간 초과 없음
실제 사용 관찰: 5분 동안 로딩이 계속 정상적으로 진행됨

지속적인 상호작용이 필요한 작업에서는 한 번의 낮은 지연 시간보다 안정적인 결과가 더 유용한 판단 기준일 수 있습니다.

3. 지역 표시는 실제 경로와 출구 성능을 뜻하지 않습니다

연결 이름에 표시된 지역은 보통 설정 제공자가 입력합니다. 해당 지역은 진입 지점이나 출구, 서비스 그룹을 가리킬 수 있으며 클라이언트가 실제 물리적 위치를 독립적으로 확인한 결과가 아닙니다. 접속 경로에는 로컬 네트워크, 인터넷 서비스 제공업체, 진입 서버, 중계 구간, 출구와 대상 사이트가 포함될 수 있습니다. 지리적으로 가까운 지역이라고 경로가 반드시 짧은 것은 아닙니다. 우회 라우팅이나 네트워크 간 혼잡으로 거리상의 이점이 사라질 수 있습니다.

대상 앱이 출구 IP를 기준으로 지역을 판단한다면 Home 목록의 이름만 보지 말고 앱에서 실제로 확인되는 출구와 서비스 정책을 기준으로 하세요. 웹사이트는 계정 지역이나 위치 권한, 이전 세션 정보 등을 함께 판단에 사용할 수도 있습니다. 설정을 바꾼 뒤에도 이전 지역이 표시된다고 해서 지연 시간 테스트가 잘못되었다고 바로 결론 내릴 수는 없습니다. 두 항목은 서로 다른 내용을 확인합니다.

상호작용 중심 작업: 지역 이름만으로 판단하지 말고 첫 화면 표시, 검색, 제출, 연속 클릭에 대한 응답을 우선 확인하세요.
지속적인 전송: 전송이 계속 유지되는지, 자주 멈추는지 확인하세요. 짧은 탐색의 응답이 빠르다고 해서 장시간 연결에 충분한 처리량이 보장되는 것은 아닙니다.
실시간 서비스: 왕복 시간뿐 아니라 지터와 패킷 손실, UDP 연결 가능 여부도 확인하세요. UDP가 작동하지 않으면 TCP 테스트가 성공해도 서비스 사용이 가능하다고 볼 수 없습니다.
특정 지역 서비스: 대상 서비스의 이용 가능 지역과 계정 조건을 확인하고 요청이 예상한 출구를 실제로 통과하는지도 확인하세요.

4. 프로토콜 종류는 연결 조건에 영향을 주지만 속도 순위를 정하지 않습니다

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 방식이 서로 다르지만 프로토콜 이름만으로 어느 설정이 더 빠른지 단정할 수는 없습니다. 서버 위치와 부하, 전송 매개변수, 로컬 네트워크, 대상까지의 경로가 함께 결과를 좌우하는 경우가 많습니다. 먼저 가져온 항목이 서버 설정과 일치하는지 확인한 뒤 성능을 비교하세요. Type만 바꿔 기존 서버를 다른 프로토콜로 전환하려고 하지 마세요.

프로토콜	중점적으로 확인할 조건	테스트 시 유의점
Shadowsocks	서버에서 지원하는 암호화 방식과 비밀번호, 포트, UDP 설정	TCP가 정상이어도 UDP 전달이 정상이라는 뜻은 아닙니다.
VMess / VLESS	인증 정보와 전송 방식, 관련 TLS·Host·경로 등의 매개변수	포트에 연결할 수 있어도 인증 및 애플리케이션 계층의 전송 매개변수가 올바르다는 뜻은 아닙니다.
Trojan	비밀번호와 서버 포트, TLS, 서버 이름 등의 매개변수	TCP 연결에 성공한 뒤에도 TLS 또는 인증 실패로 사용할 수 없을 수 있습니다.
Hysteria2	UDP 연결 가능 여부와 인증, TLS, 서버에서 지정한 매개변수	QUIC 기반입니다. TCP 포트만 탐색해서는 연결 전체 상태를 판단할 수 없습니다.
WireGuard	키와 Endpoint, 터널 주소, AllowedIPs 등의 설정	UDP 기반입니다. 핸드셰이크와 터널 내부의 실제 통신을 함께 확인해야 합니다.

포트 번호만으로 프로토콜의 기능을 알 수는 없습니다. TCP 443과 UDP 443은 서로 다른 전송 프로토콜을 사용하므로 번호가 같아도 연결 조건은 다릅니다. 네트워크에서 TCP 443이 허용된다고 UDP 443도 연결 가능하다는 뜻은 아닙니다. 어떤 설정이 Wi-Fi에서는 작동하고 셀룰러에서는 작동하지 않는다면 기존 매개변수를 유지한 채 네트워크와 전송 조건을 각각 확인하세요. 포트를 무작정 바꾸거나 TLS 검증을 끄지 마세요.

5. Global Routing과 규칙으로 인한 오판부터 확인하기

설정 하나를 선택해도 모든 요청이 해당 설정을 사용하는 것은 아닙니다. Global Routing은 전체 라우팅 방식을 정하며, Config에서는 현재 활성화된 설정 파일과 적용된 규칙, 규칙이 지정하는 정책도 확인해야 합니다. 특정 도메인이 DIRECT 규칙에 해당한다면 프록시 설정을 계속 바꿔도 해당 도메인의 실제 경로는 바뀌지 않는 경우가 많습니다.

Config

권장

현재 설정의 규칙에 따라 정책을 결정합니다. 기존 규칙이 올바르고 평소처럼 트래픽을 분리해 사용하려는 경우에 적합합니다. 모든 대상이 현재 선택한 프록시를 거친다고 보장하지는 않습니다.

적합한 경우: 일상적인 사용 및 규칙 적용 여부를 확인한 뒤 실제 서비스 테스트

Proxy

전체 라우팅 방향을 프록시로 설정해 Config의 규칙이 미치는 영향을 비교할 수 있습니다. 시스템 설정과 라우팅 제외 항목, 처리 대상이 아닌 트래픽은 별도로 고려해야 합니다. 기기의 모든 통신이 프록시를 거친다고 단정할 수는 없습니다.

적합한 경우: 규칙의 영향을 일시적으로 분리해 확인한 뒤 원래 설정으로 복원

Direct

전체 라우팅 방향을 직접 연결로 설정해 로컬 네트워크에서 대상에 접속할 때의 상태를 확인합니다. 이때 실제 페이지의 작동 상태를 선택한 프록시 설정의 성능으로 판단할 수는 없습니다.

적합한 경우: 로컬 네트워크의 기준 상태를 확인하고 대상 자체의 문제와 프록시 경로 문제를 구분

Scene

설정된 Scene 조건에 맞춰 해당 라우팅 방식을 사용합니다. 테스트 전에 현재 Scene에서 실제 적용되는 설정을 확인하세요. 환경이 바뀐 뒤 두 번의 테스트가 서로 다른 경로를 사용하지 않도록 주의해야 합니다.

적합한 경우: Scene 조건을 명확히 설정해 둔 환경

예를 들어 아래 설명용 규칙에서는 example.com 및 하위 도메인이 먼저 DIRECT에 일치하고, 그 외 요청은 FINAL에서 지정한 PROXY로 전달됩니다. 예시 도메인은 구문 설명용일 뿐 테스트 서비스나 실제로 사용할 수 있는 연결 설정이 아닙니다.

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

Config에서 현재 활성화된 파일을 확인하고 요청 기록에서 적용된 정책을 확인하세요. 규칙은 순서대로 일치하며, DOMAIN-SUFFIX 외에도 GEOIP, IP-CIDR 등의 조건이 경로에 영향을 줄 수 있습니다. FINAL은 앞선 규칙과 일치하지 않은 요청에 적용되는 기본값입니다. 정책이 다른 지정 설정이나 정책 그룹을 참조하는지도 확인하세요. 요청이 반드시 Home에서 현재 선택한 항목을 사용한다고 오해하지 않도록 주의해야 합니다.

6. 자주 겪는 문제와 다음 확인 단계

지연 시간이 수십 ms에 불과한데 동영상은 왜 계속 로딩되나요?

먼저 Home → Global Routing에서 테스트 방식을 확인하고 대상 요청에 적용된 정책을 살펴보세요. 같은 동영상을 5분 동안 재생해 처음 로딩이 느린 경우와 재생 중 멈추는 경우를 구분하세요. 처음 로딩이 느리다면 DNS나 핸드셰이크, 대상 응답이 원인일 수 있고, 재생 중 멈춘다면 지속적인 처리량과 패킷 손실, 혼잡을 확인해야 합니다. 한 번의 짧은 탐색으로는 이런 조건을 확인할 수 없습니다.

목록 테스트는 시간 초과되는데 실제 웹페이지는 열립니다. 설정을 삭제해야 하나요?

바로 삭제하지 마세요. Home에서 Connectivity Test의 테스트 방식과 대상을 확인한 다음 웹페이지 요청이 실제로 해당 설정을 통해 전달되는지 확인하세요. UDP 프로토콜인데 TCP 포트만 검사했거나 탐색 대상 URL에 접속할 수 없다면 시간 초과가 실제 서비스 장애를 뜻하지 않을 수 있습니다. 동일한 조건으로 테스트를 반복하고 실제 요청 결과도 기록하세요.

지역을 바꿨는데 웹사이트에 표시되는 위치는 왜 그대로인가요?

먼저 Global Routing이 Direct로 설정되어 있지 않은지 확인한 뒤 Config에서 해당 도메인이 DIRECT 규칙에 일치하거나 다른 정책을 지정받았는지 살펴보세요. 실제 출구는 목록에 표시된 지역과 다를 수 있습니다. 출구가 바뀌었더라도 웹사이트가 계정 지역이나 이전 세션 정보를 기준으로 표시할 수 있습니다. 연결을 계속 바꾸기보다 대상 서비스의 판단 기준을 확인하세요.

네트워크를 바꿀 때마다 결과가 달라집니다. 예비 설정은 어떻게 골라야 하나요?

평소 사용하는 Wi-Fi와 셀룰러 네트워크에서 같은 테스트를 각각 반복하고 성공률과 변동 폭, 실제 앱의 작동 상태를 기록하세요. Settings → On Demand 조건이 연결 상태를 바꾸는지도 확인하세요. 이미 보유한 설정 중 예비 네트워크에서 작동을 확인한 항목을 보관하고 사용할 때 전환이 완료되었는지 확인하세요. 가장 낮은 수치를 쫓아 프로토콜 매개변수를 자주 바꿀 필요는 없습니다.

마지막으로 ‘대상 서비스가 정상 작동하는가 → 평소 사용하는 네트워크에서 안정적인가 → 자주 사용하는 시간대에 반복해서 작동하는가 → 지연 시간과 처리량이 요구 사항에 맞는가’ 순서로 선택할 수 있습니다. 문제가 발생하면 네트워크 종류와 시간, 프로토콜, 라우팅 방식, 테스트 방식, 오류 증상을 기록한 뒤 서비스 제공업체에 서버 상태를 확인하세요. 기록을 공유할 때는 비밀번호와 키, 인증 정보, 전체 구독 주소를 가려 인증 정보가 포함된 화면을 공개하지 않도록 주의하세요.