Shadowrocket 노드 선택 방법: 지연 시간 테스트, 지역 및 프로토콜 비교

이 글의 핵심

Shadowrocket에서 노드를 선택할 때는 동일한 네트워크와 테스트 방식으로 응답하는 후보를 추린 뒤, 실제로 연결해 사용하려는 작업을 확인하세요. 이 글은 사용자가 이미 서비스와 구독을 보유한 경우를 전제로 지연 시간 수치의 한계, 지역 표기의 용도, 프로토콜 매개변수 확인 방법, 규칙 분기 결과를 노드 성능으로 오해하지 않는 방법을 설명합니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다.

1. 지연 시간 테스트는 연결 여부를 확인하는 용도이며, 속도 순위가 아닙니다

지연 시간은 보통 ms 단위로 표시되며, 테스트를 시작한 뒤 응답을 받을 때까지 걸린 시간을 나타냅니다. 다운로드 속도나 웹페이지 전체 로딩 시간과는 다릅니다. TCP 연결만 설정하는 테스트라면 주로 연결 설정 단계가 반영됩니다. 프록시를 통해 HTTP 테스트 대상에 접속하면 프록시 핸드셰이크와 대상 서버의 응답 등에도 영향을 받습니다. 따라서 지연 시간이 연결 설정 속도만 보여 준다는 설명은 대역폭과 혼동하지 않도록 돕지만, 테스트 방식 자체를 확인할 필요가 없다는 뜻은 아닙니다.

먼저 Settings → Connectivity Test에서 현재 테스트 설정을 확인한 다음 Home으로 돌아가 Connectivity Test를 실행하세요. 같은 목록의 결과는 테스트 방식과 대상, 로컬 네트워크가 같을 때 비교하는 것이 적절합니다. 한 번의 Wi-Fi 테스트와 다른 시점의 셀룰러 네트워크 테스트를 그대로 순위로 비교하거나, 서로 다른 테스트 방식의 수치를 함께 평균 내지 마세요.

수치가 표시됨: 해당 조건에서 테스트 응답을 받았다는 뜻입니다. 모든 웹사이트나 모든 프로토콜 트래픽이 정상 작동한다는 의미는 아닙니다.
시간 초과: 서버에 연결할 수 없거나 포트가 차단된 경우, 테스트 대상이 응답하지 않는 경우, 매개변수가 맞지 않는 경우 등이 원인일 수 있습니다. 이 결과만으로 구독 전체가 작동하지 않는다고 단정할 수는 없습니다.
결과 편차가 큼: 같은 후보를 여러 번 확인하고 시간 초과가 반복되는지 기록하세요. 가장 낮은 수치만 남기지 마세요.

예를 들어 기록에 ‘후보 A: 80, 82, 450 ms’, ‘후보 B: 110, 115, 112 ms’가 있다면, 먼저 A의 편차가 크다는 점을 확인하고 실제 사용 환경에서 검증하세요. 이 수치는 기록 방법을 보여 주는 예시일 뿐, 이 사이트에서 측정한 결과나 성능 보장이 아닙니다. A의 최솟값이 더 낮더라도 지속적인 데이터 전송이 더 원활하다고 단정할 수 없습니다.

2. Home에서 재현 가능한 방식으로 후보를 추리기

결과가 달라진 원인을 파악하려면 한 번에 조건 하나만 바꾸세요. 테스트 전에 기기에서 대량으로 데이터를 전송하는 작업을 잠시 멈추고, 같은 Wi-Fi 또는 셀룰러 네트워크를 유지하세요. 백그라운드 트래픽이 전혀 없는 상태까지 만들 필요는 없지만, 대용량 파일을 내려받으면서 수십 ms 차이를 비교하지는 마세요.

목록 확인

Home에서 서버 항목이 있는지 확인하세요. 구독을 방금 업데이트했다면 항목이 그대로 있는지 먼저 살펴보세요. 항목 편집 화면에서 Type, 주소, 포트를 확인해 더 이상 유효하지 않은 이전 항목을 비교 대상에 넣지 않도록 하세요.
테스트 조건 통일

Settings → Connectivity Test로 이동해 현재 테스트 방식과 대상을 확인하세요. 설정을 그대로 유지한 채 Home으로 돌아가 Connectivity Test를 실행하고, 응답한 후보와 시간 초과된 후보를 기록하세요.
반복 확인

후보를 몇 개 추린 뒤 세 차례에 걸쳐 결과를 기록하고 각 회차 사이에 간격을 두세요. 최솟값만 기록하지 말고 원래 수치와 시간 초과 횟수를 남기세요. 테스트 중에는 로컬 네트워크를 바꾸지 마세요.
라우팅 확인

Home → Global Routing에서 모드를 확인하세요. Proxy로 선택한 서버를 통한 실제 접속 결과를 비교하세요. Config를 사용한다면 현재 Config의 규칙이 최종적으로 어떤 정책을 가리키는지도 확인해야 합니다.
실제 작업으로 검증

후보를 선택하고 연결 스위치를 켠 다음, 같은 웹페이지나 같은 동영상을 이용해 보세요. 페이지가 열리는지, 리소스가 빠짐없이 표시되는지, 재생이 끊기지 않는지 각각 기록한 뒤 다음 후보로 바꿔 같은 방식으로 반복하세요.

Proxy 비교는 변수 범위를 좁히기 위한 방법일 뿐, 평소에도 계속 해당 모드를 사용해야 한다는 뜻은 아닙니다. 검증이 끝나면 원래 사용하던 Global Routing 설정으로 되돌리세요. 서버를 바꾼 뒤에도 열려 있던 웹페이지가 바로 달라지지 않는다면 해당 페이지를 닫았다가 다시 여세요. 기존 장기 연결이나 캐시된 콘텐츠만으로 새 연결의 경로를 판단해서는 안 됩니다.

3. 지역 표기는 후보를 추리는 데 활용하고 실제 경로는 검증하기

노드 이름의 지역 정보는 일반적으로 기존 서비스 제공자가 입력합니다. 이름만으로 실제 위치나 출구 위치, 접속 권한을 따로 확인할 수는 없습니다. 진입 주소와 최종 출구, 대상 웹사이트가 속한 네트워크가 서로 다른 지역일 수도 있습니다. 이름에 표시된 도시나 국기만으로 대상에 접속할 때 어떤 경로를 거치는지 알 수 없습니다.

가까운 지역은 전송 거리가 짧을 수 있지만, 전체 소요 시간은 통신사 간 연결, 우회 경로, 서버 부하, 대상 사이트 응답 속도에도 영향을 받습니다. 실제 작업에 맞춰 지역 범위를 먼저 좁힌 다음 연결 가능 여부와 안정성을 테스트하면, 지도상 거리만으로 순서를 정하는 것보다 결과를 더 쉽게 확인할 수 있습니다.

작업별 확인 항목

웹페이지 및 상호작용 요청

같은 대상 페이지를 지정해 처음 열 때와 이후 상호작용을 확인하세요.
제목 표시 여부만 보지 말고 이미지와 스크립트 같은 리소스가 모두 로드되는지 확인하세요.
반복해서 시간 초과되는 후보를 먼저 제외한 뒤 응답 차이를 비교하세요.

연속 재생 및 데이터 전송

같은 콘텐츠와 화질을 지정해 재생 중 데이터 전송이 끊기는지 확인하세요.
처음 재생 전 버퍼링과 재생 중 발생하는 추가 버퍼링을 구분하세요.
시간대를 바꿔 다시 확인해 한 번의 한가한 시간대 결과를 장기적인 성능으로 오해하지 마세요.

지역은 후보를 추리기 위한 조건입니다. 이번 작업의 판단 기준은 실제 접속 결과이며, 노드 이름만으로 대상 서비스의 지역 판정이나 이용 가능성이 보장되지는 않습니다.

4. 프로토콜 종류는 호환되는 매개변수를 확인한 뒤 비교하기

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 방식과 매개변수 구조가 서로 다르며, 프로토콜 이름만으로 일률적인 속도 순위를 매길 수 없습니다. 같은 프로토콜도 서로 다른 전송 방식과 함께 사용할 수 있습니다. 기존 서비스에서 실제로 제공한 매개변수를 사용해야 합니다. Type에서 이름만 바꾼다고 기존 서버가 다른 프로토콜로 작동하는 것은 아닙니다.

포트도 프로토콜 이름만 보고 추측해서는 안 됩니다. 일부 설정에서 443을 사용하지만 모든 서비스의 고정 포트는 아니며, 연결이 반드시 같은 전송 방식을 사용한다는 뜻도 아닙니다. TLS 관련 설정이라면 서비스에서 요구하는 서버 이름 등의 매개변수도 확인하세요. 인증서 검증을 꺼서 설정 오류를 감추려 하지 마세요.

프로토콜 및 전송 설정 확인

Shadowsocks: 서버, 포트, 암호화 방식, 비밀번호를 확인하세요. 하나라도 맞지 않으면 연결이 실패할 수 있습니다.
VMess / VLESS: 사용자 ID, 전송 방식, 서비스에서 요구하는 TLS 설정 등을 확인하세요. 주소와 포트만으로는 대개 설정을 완전히 구성할 수 없습니다.
Trojan: 비밀번호와 TLS 관련 매개변수를 확인하고, 서버 이름이 서비스 설정과 일치하는지 확인하세요.

먼저 매개변수가 모두 맞는지 확인한 다음 지연 시간 차이를 비교하세요. 전송 설정이 다르면 Type만으로 같은 테스트 조건이라고 볼 수 없습니다.

네트워크 조건 확인

Hysteria2: QUIC 기반이며 UDP 경로를 사용합니다. TCP 포트만 테스트해서는 이 연결을 완전히 확인할 수 없습니다.
WireGuard: UDP를 사용하므로 키, Endpoint 및 터널 관련 매개변수가 일치해야 합니다. 포트에서 응답이 온다고 터널 설정까지 올바른 것은 아닙니다.
포트 예시: 443은 사용될 수 있는 포트의 한 예입니다. 실제 포트 번호는 사용자가 이미 보유한 설정을 따르고 임의로 바꾸지 마세요.

Wi-Fi와 셀룰러 네트워크는 UDP를 다르게 처리할 수 있습니다. 네트워크를 바꾸면 다시 확인하고 이전 순위를 그대로 적용하지 마세요.

특정 후보가 Wi-Fi에서는 실패하지만 셀룰러 네트워크에서는 정상이라면, 프로토콜이 ‘더 빠르다’거나 ‘더 느리다’고 바로 결론 내리지 말고 로컬 네트워크 경로도 점검하세요. Type, 전송 방식, 포트, 실패한 네트워크를 기록하면 이름을 계속 바꾸는 것보다 원인을 찾는 데 도움이 됩니다.

5. Global Routing 및 규칙으로 인한 오판 방지

Home에서 선택한 서버가 현재 웹페이지 요청을 반드시 처리하는 것은 아닙니다. Global Routing에서 Direct를 사용하면 트래픽이 직접 연결되고, Proxy는 프록시 경로를 사용합니다. Config에서는 현재 설정의 규칙에 따라 트래픽 경로가 결정되며, Scene을 사용한다면 해당 장면의 설정을 확인해야 합니다. 후보를 비교하기 전에 요청이 실제로 어떤 정책을 따르는지 파악하세요.

Config 모드에서 DOMAIN-SUFFIX는 도메인 접미사로, IP-CIDR은 주소 범위로, GEOIP는 IP 지리 정보로 일치 항목을 찾습니다. FINAL은 앞선 규칙에 일치하지 않은 트래픽을 처리합니다. 규칙은 위에서 아래로 적용되므로, 앞쪽 규칙에서 DIRECT 또는 REJECT에 일치했다면 뒤의 FINAL을 수정해도 해당 요청의 결과는 바뀌지 않습니다.

웹페이지가 항상 빠르게 열림: 먼저 DIRECT 규칙에 일치하는지 확인하세요. 직접 연결된 페이지로는 선택한 프록시 서버의 속도를 판단할 수 없습니다.
특정 도메인만 접속 실패: REJECT 규칙에 일치하는지, 또는 현재 선택한 서버와 다른 정책을 사용하는지 확인하세요.
서버를 바꿔도 차이가 없음: 현재 Config가 다른 정책을 지정하는지 확인하고, 페이지 캐시와 기존 장기 연결의 영향도 배제하세요.
스위치가 자동으로 되돌아감: Settings → On Demand에서 조건을 확인해 자동 연결 동작이 수동 비교에 영향을 주지 않도록 하세요.

테스트에는 응답이 있지만 웹페이지가 열리지 않는다면 DNS 조회 결과와 대상 자체도 확인해야 합니다. 포트에 연결할 수 있다고 도메인 이름이 올바르게 해석되거나 대상 사이트가 현재 출구를 허용한다고 볼 수는 없습니다. 규칙 문법을 확인하려면 프로토콜 매뉴얼을 참고하세요. 노드를 선택하려고 Config 전체를 한꺼번에 수정하지 마세요.

6. 자주 묻는 선택 질문과 기록 방법

지연 시간이 가장 낮은 노드인데 동영상이 왜 끊기나요?

Home으로 돌아가 해당 후보를 선택하고 Global Routing을 확인한 뒤 동영상 화질을 고정해 재생하세요. 연결 설정 속도와 지속적인 전송 속도는 서로 다른 지표입니다. 혼잡, 패킷 손실, 대상 콘텐츠의 배포 경로가 연속 재생에 영향을 줄 수 있습니다. 버퍼링이 재생 시작 전인지 재생 도중인지 기록하는 편이 ms 수치 하나만 남기는 것보다 유용합니다.

테스트에서는 시간 초과가 표시되지만 연결 후 웹페이지가 열린다면 항목을 삭제해야 하나요?

먼저 Settings → Connectivity Test에서 테스트 대상과 방식을 확인한 뒤 실제 접속 결과와 비교하세요. 테스트 대상에만 접속할 수 없거나 테스트 방식이 실제 프로토콜 경로를 포함하지 않았을 수 있습니다. 한 번 시간 초과됐다고 항목을 바로 삭제하지 마세요. 구독에서 가져온 항목이라면 이후 업데이트 때 목록이 다시 동기화될 수 있다는 점도 고려하세요.

같은 지역, 같은 프로토콜인데 결과가 왜 크게 다른가요?

Home에서 각 항목의 편집 화면을 열어 주소와 포트, 전송 설정을 확인하세요. 지역 이름이 같아도 진입점과 출구, 경로가 같다는 뜻은 아닙니다. 프로토콜이 같아도 부하가 같다고 볼 수 없습니다. 같은 네트워크에서 테스트를 반복한 다음 동일한 실제 작업으로 결과를 비교하세요.

구독을 업데이트한 뒤 다시 노드를 선택해야 하나요?

먼저 내용을 확인하세요. 업데이트로 주소와 포트, 매개변수 또는 항목 목록이 바뀌었을 수 있어 이전 기록이 현재 항목과 일치하지 않을 수 있습니다. Home으로 돌아가 현재 항목을 확인하고 Connectivity Test를 실행하세요. 구독 내용이 실제로 바뀌었거나 사용 중 문제가 생긴 경우에만 전체 비교를 다시 할 필요가 있습니다.

실제 작업으로 검증한 후보 두세 개만 남겨도 충분합니다. 테스트 시간, 로컬 네트워크, 항목 이름, Type, 테스트 방식, 세 차례의 결과와 실제 접속 상황을 기록하세요. 네트워크나 구독 내용이 바뀌면 다시 확인하세요. 비밀번호와 키, 전체 구독 URL은 기록하지 말고 다른 사람에게 문제를 설명할 때도 해당 정보를 가리세요.