Shadowrocket 노드 선택법: 지연 시간 테스트·지역·프로토콜 확인

이 글의 핵심

Shadowrocket에서 이미 보유한 서버를 선택할 때는 먼저 연결 가능 여부를 확인하고, 같은 네트워크와 테스트 방식으로 지연 시간을 비교한 뒤 실제 웹페이지나 동영상으로 검증하세요. 본인 소유의 서비스와 구독 정보를 갖고 있는 사용자를 위해 Home, Global Routing, Config의 확인 순서를 설명합니다. 지역 태그, 프로토콜 종류, 실제 접속 결과를 각각 기록해 지연 시간이 가장 짧다는 이유만으로 서버를 선택하지 않도록 안내합니다.

1. 지연 시간 수치로 알 수 있는 것

Home에 표시되는 테스트 결과는 특정 시점의 탐지에 걸린 시간이지, 전체 경로의 종합 점수가 아닙니다. 결과는 테스트 방식에 따라 의미가 달라집니다. TCP 탐지는 보통 지정한 주소와 포트에 연결을 설정하는 데 걸린 시간을 나타냅니다. HTTP 탐지는 테스트 주소와 요청 경로, 연결 방식의 영향도 받습니다. 비교 전에 두 테스트의 방식과 대상이 같은지 확인하세요. 서로 다른 방식으로 측정한 수치를 한 순위표에 놓고 비교해서는 안 됩니다.

웹페이지를 여는 데는 DNS 조회, 연결 설정, TLS 핸드셰이크, 요청 전송, 서버 처리, 콘텐츠 전송 등 여러 단계가 있습니다. 한 페이지에서 이미지나 스크립트처럼 여러 도메인에 요청할 수도 있습니다. 서버 입구의 응답이 빠르다는 것은 경로 일부가 짧거나 당시 한산했다는 뜻일 뿐입니다. 대상 웹사이트의 응답이 빠르거나 지속 전송에 충분한 대역폭이 있다는 의미는 아닙니다.

4가지

Global Routing：Proxy / Direct / Config / Scene

6가지

이 글에서 다루는 프로토콜: Shadowsocks / VMess / VLESS / Trojan / Hysteria2 / WireGuard

443

HTTPS의 기본 포트이며 모든 서버에서 고정적으로 사용하는 포트는 아닙니다

테스트에 실패했다고 해서 서버가 모든 상황에서 사용할 수 없는 것은 아닙니다. 주소 조회 실패, 테스트 대상에 연결할 수 없는 경우, 지정 포트가 응답하지 않는 경우에도 탐지는 실패할 수 있습니다. 반대로 포트에 연결된다고 해서 비밀번호, TLS 또는 프로토콜 매개변수가 올바르다는 뜻도 아닙니다. 판단할 때는 ‘서버 입구가 응답하는지’와 ‘프록시 요청이 완료되는지’를 별도로 확인하세요.

2. Home에서 반복 가능한 비교 조건 만들기

보유 중인 목록에서 비교할 서버를 몇 개만 고르고, DNS·규칙·프로토콜 매개변수·네트워크를 한꺼번에 바꾸지 마세요. 한 번에 변수 하나만 바꿔야 결과가 달라진 원인을 파악할 수 있습니다. 실제 접속을 확인할 때는 요청이 선택한 서버를 실제로 통과하는지도 확인하세요. Direct 상태에서 웹페이지를 열 수 있다고 해서 프록시 서버가 작동한다는 뜻은 아닙니다.

서버 정보 확인

Home에서 기존 서버 항목과 구독 업데이트 결과를 확인하세요. 본인이 보유한 서비스 정보와 대조해 주소, 포트, Type을 확인합니다. 구독을 업데이트해야 한다면 먼저 업데이트를 완료하고 비교할 항목을 다시 확인하세요. 비교 도중 매개변수가 바뀌는 일을 방지할 수 있습니다.
네트워크 고정

같은 Wi-Fi 또는 셀룰러 네트워크를 유지하고 대용량 파일 전송은 일시 중지하세요. Settings → On Demand에서 자동 연결 조건을 확인해 테스트 도중 네트워크 조건 변화로 연결이 끊기거나 다시 연결되지 않도록 합니다.
라우팅 모드 확인

Home → Global Routing으로 이동합니다. 프록시 접속을 비교할 때는 Proxy를 임시로 사용한 뒤 Home에서 비교할 서버를 선택해 연결하세요. 테스트가 끝나면 기존 설정으로 되돌립니다. 정책 그룹을 사용하는 경우 실제로 선택된 구성원도 확인하세요.
여러 차례 테스트

Home에서 비교할 서버의 지연 시간 테스트를 실행하고 테스트 방식과 대상을 동일하게 유지하세요. 각 서버를 최소 세 번 테스트해 전체 결과와 시간 초과 여부를 기록하고, 가장 낮은 수치만 남기지 마세요.
실제 접속 확인

비교할 서버를 하나씩 선택해 같은 웹페이지를 열고 동일한 동영상 구간을 테스트하세요. 처음 콘텐츠가 화면에 나타나는 데 걸린 시간과 연속 재생 중 멈춤 여부를 기록한 다음, 평소 사용하는 Global Routing 설정으로 되돌립니다.

Global Routing의 Proxy는 트래픽을 프록시 방식으로 처리하고, Direct는 직접 연결하며, Config는 현재 설정된 규칙에 따라 처리합니다. Scene은 선택한 시나리오 설정에 따라 달라집니다. 이는 네 가지 지연 시간 측정 방식이 아닙니다. 평소 Config를 사용한다면 최종 검증 때 Config로 되돌리고 Config에서 현재 활성화된 구성 파일을 확인하세요. 관련 도메인에 적용되는 정책이 방금 테스트한 서버를 가리키는지도 확인해야 합니다.

3. 지역 태그와 실제 출구 지역은 따로 확인

목록에 표시된 지역명은 대개 항목 이름에 포함된 정보일 뿐, 앱이 물리적 위치를 별도로 인증한 결과가 아닙니다. 특정 지역으로 표시된 항목의 서버 입구는 다른 곳에 있을 수 있으며, 이후 중계 서버를 거쳐 출구에 도달할 수도 있습니다. 웹사이트가 인식하는 지역은 출구 IP 데이터베이스, 계정 지역, 콘텐츠 이용 조건에 따라 달라질 수 있습니다. 이름만 보고 접속 경로나 특정 웹사이트의 이용 가능 여부를 판단할 수는 없습니다.

물리적 거리는 일반적으로 전파 시간에 영향을 주지만, 인터넷 경로는 지도 위의 직선과 다릅니다. 네트워크 간 연결 방식, 통신사 라우팅, 혼잡도, 서버 입구 위치에 따라 사용 경험이 달라집니다. 같은 서버를 집 Wi-Fi와 셀룰러 네트워크에서 테스트해 결과가 다른 것은 이상한 일이 아닙니다. 접속 경로의 일부가 달라졌다는 뜻입니다.

비교 조건: 같은 네트워크와 네트워크 변경 후 재테스트

같은 Wi-Fi에서 비교

기기, 테스트 방식, 대상을 동일하게 유지합니다.
서버를 하나씩 바꾸고 백그라운드 전송은 피합니다.
서버 입구 지연 시간과 실제 웹페이지 응답을 각각 기록합니다.

셀룰러 네트워크로 전환해 재테스트

같은 후보 서버를 사용하되 Wi-Fi 테스트 순위를 그대로 적용하지 않습니다.
연결 상태와 On Demand 조건을 다시 확인합니다.
시간 초과가 반복되는지, 네트워크 전환 후 연결이 어떻게 복구되는지 확인합니다.

Wi-Fi와 셀룰러 결과를 각각 기록하세요. 특정 지역으로 표시된 항목이 한 네트워크에서 잘 작동해도 다른 네트워크에서 같은 결과를 보장하지는 않습니다.

특정 지역의 콘텐츠에 접속하려는 경우, 먼저 본인의 적법한 이용 조건과 실제 접속 결과를 통해 출구 지역을 확인한 다음 성능을 비교하세요. 일반 웹페이지 이용이 목적이라면 지역별로 고정된 순위를 정할 필요는 없습니다. 평소 사용하는 네트워크에서 응답이 안정적이고 요청이 정상적으로 완료되는 기존 항목을 선택하면 됩니다.

4. 프로토콜 종류는 속도 등급이 아닙니다

프로토콜은 클라이언트와 서버가 데이터를 주고받고 인증하며 연결을 설정하는 방식을 정합니다. 하지만 속도는 서버 자원, 연결 품질, 서버 측 설정에도 좌우됩니다. 모든 네트워크에서 통용되는 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard의 빠르기 순위는 없습니다. Type만 수정한다고 기존 서버가 다른 프로토콜로 바뀌는 것도 아닙니다.

프로토콜	연결 전 확인 사항	비교 시 유의 사항
Shadowsocks	주소, 포트, 비밀번호, 암호화 방식.	암호화 방식은 서버 측 설정과 일치해야 합니다. TCP 요청이 성공해도 UDP 사용 가능 여부를 단독으로 확인할 수는 없습니다.
VMess	주소, 포트, UUID, 기존 서비스 정보에 지정된 전송 및 TLS 매개변수.	전송 방식에 따라 연결 과정이 달라지므로 프로토콜 이름만으로 비교할 수 없습니다.
VLESS	UUID, 전송 방식, 서비스 정보에 명시된 TLS 또는 기타 보안 매개변수.	인증 식별자, 전송 방식, 보안 계층을 각각 확인하세요. 포트 응답 여부만으로 판단할 수 없습니다.
Trojan	비밀번호, 포트, TLS, SNI, 인증서 검증.	SNI는 TLS 연결 설정에 영향을 줍니다. 테스트 결과를 얻기 위해 인증서 검증을 끄지 마세요.
Hysteria2	인증 정보, 포트, TLS 매개변수, 현재 네트워크에서 UDP에 도달할 수 있는지 확인합니다.	QUIC 기반이며 UDP에 의존합니다. TCP 포트 탐지만으로 전체 연결 가능 여부를 판단할 수 없습니다.
WireGuard	기존 설정에 포함된 키, 피어 주소, 포트, 터널 주소.	UDP 기반입니다. 피어 주소를 조회할 수 있어도 터널 핸드셰이크와 데이터 전송의 성공을 의미하지는 않습니다.

같은 지역의 서로 다른 프로토콜 서버 두 개는 입구, 출구, 자원이 다를 수 있습니다. 따라서 차이가 반드시 프로토콜에서 비롯된다고 볼 수는 없습니다. 현재 네트워크에서 프로토콜의 영향을 확인하려면 가능한 한 다른 조건을 동일하게 맞추세요. 조건을 동일하게 확인할 수 없다면 ‘이번 테스트에서는 이 항목이 더 안정적이었다’고 기록해야 합니다. ‘이 프로토콜은 항상 더 빠르다’고 일반화하지 마세요.

5. 기록으로 지연 시간과 실제 사용 경험 구분하기

아래 수치는 기록 방법을 설명하기 위한 가상 예시이며, 실제 경로 측정값이나 성능 보장이 아닙니다. 후보 A의 탐지 결과가 42, 45, 180ms이고 후보 B가 68, 70, 72ms라고 가정해 보겠습니다. A의 최솟값은 더 낮지만 세 번의 결과 편차는 더 큽니다. A로 동영상을 연속 재생할 때 멈춤이 반복되고 B에서는 멈춤이 없다면, 42가 68보다 작다는 이유만으로 순위를 정하지 말고 실제 사용 결과도 고려해야 합니다.

후보 A: 가상 기록

네트워크: 같은 Wi-Fi를 사용했으며 테스트 중 네트워크를 전환하지 않았습니다.
탐지 결과: 42 / 45 / 180ms, 세 번 모두 완료.
웹페이지 상황: 첫 콘텐츠는 빨리 표시되지만 이후 이미지가 간혹 늦게 로드됩니다.
동영상 상황: 같은 구간을 2분간 연속 재생했으며 두 차례 멈췄습니다.

기록 방법을 설명하기 위한 예시입니다. 최솟값이 낮더라도 결과 편차와 실제 이용 중 멈춤을 무시할 수는 없습니다.

후보 B: 가상 기록

네트워크: 후보 A와 같은 Wi-Fi와 기기를 사용했습니다.
탐지 결과: 68 / 70 / 72ms, 같은 탐지 방식을 사용했습니다.
웹페이지 상황: 첫 콘텐츠는 약간 늦게 표시되지만 이미지가 더 연속적으로 로드됩니다.
동영상 상황: 같은 구간을 2분간 연속 재생했으며 멈춤이 관찰되지 않았습니다.

2분 동안 멈춤이 없었다는 것은 이번 관찰 결과일 뿐입니다. 평소 사용하는 시간대에 다시 테스트해야 합니다.

세 번의 결과에서는 먼저 중간값과 편차를 살펴보세요. 시간 초과는 횟수를 별도로 기록하고, 결과에서 제외해 보기 좋은 평균값을 만들지 마세요. 짧은 시간 동안의 표본만으로 하루 종일 안정적인지 추론할 수도 없습니다. 일상적인 사용에 중요한 서버는 평소 사용하는 시간대에 한 차례 더 테스트하고 네트워크 종류와 테스트 시간을 함께 기록하세요.

웹페이지: 첫 콘텐츠 표시, 이미지 로딩 완료, 페이지 상호작용 가능 시점을 구분하세요. 캐시가 적용되면 같은 페이지를 다시 열 때 더 빨라질 수 있습니다.
동영상: 화질과 재생 구간을 고정하세요. 자동 화질 조정으로 화질이 낮아지면 처리량 부족이 드러나지 않을 수 있으므로 ‘재생 가능’ 여부만 기록해서는 안 됩니다.
대용량 파일: 전송 시작 후 몇 초간의 최고 속도만 보지 말고 지속 전송 상태를 확인하세요. 여러 작업이 동시에 대역폭을 사용하지 않도록 합니다.
상호작용 앱: 요청 응답과 연결 끊김 여부를 확인하세요. 평균 지연 시간이 비슷해도 변동과 패킷 손실이 사용 경험에 더 큰 영향을 줄 수 있습니다.

6. 서버 선택 후 규칙과 업데이트 확인

테스트를 위해 Proxy를 임시로 사용했다면 완료 후 평소 설정으로 복원하세요. Proxy에서는 정상 작동하지만 Config로 바꾼 뒤 특정 웹사이트에 접속할 수 없다면 서버가 작동하지 않는다고 바로 판단하지 말고 규칙과 정책 참조부터 확인하세요. Config는 현재 구성 파일의 규칙을 따릅니다. 한 웹페이지가 여러 도메인에 요청을 보내면 요청에 따라 DIRECT와 PROXY가 각각 적용될 수도 있습니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

위 예시는 규칙의 매칭 순서를 설명하기 위한 것으로, 모든 용도에 맞는 완전한 설정이 아닙니다. Config에서 현재 활성화된 파일과 Rule 섹션을 확인하고 PROXY가 실제로 어떤 서버 또는 정책 그룹을 가리키는지 살펴보세요. 앞선 규칙이 이미 매칭되면 이후의 FINAL은 경로를 다시 선택하지 않습니다.

[Rule]은 뒤따르는 내용이 규칙 섹션에 속한다는 뜻입니다.
DOMAIN-SUFFIX,example.com,PROXY는 example.com과 그 하위 도메인에 매칭되며 PROXY로 처리합니다.
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve는 해당 사설 IP 대역에 DIRECT를 사용합니다. no-resolve는 이 IP 규칙을 위해 도메인 조회를 별도로 시작하지 않는다는 뜻입니다.
GEOIP,CN,DIRECT는 IP 지리 데이터베이스에서 CN으로 판정된 요청에 DIRECT를 사용합니다. 서버 항목의 지역명으로 판단하지 않습니다.
FINAL,PROXY는 앞선 규칙과 일치하지 않은 요청에 최종 정책을 지정합니다.

기존 구독을 업데이트하면 항목 이름, 주소, 포트 또는 그룹 구성원이 바뀔 수 있습니다. Home에서 선택한 서버, Config의 정책 참조, 실제 접속 결과를 다시 확인하세요. 선택 항목의 이름이 같아 보이더라도 매개변수 확인을 대신할 수는 없습니다. 문제를 점검할 때는 필요한 오류 정보만 공유하고 구독 링크, 비밀번호, UUID, 키는 공개하지 마세요.