Shadowrocket 서버 선택: 지연 시간 테스트와 지역·프로토콜 확인

이 글 미리보기

이 글은 Shadowrocket에 본인의 구독을 이미 추가한 사용자를 위한 안내입니다. 서버를 고를 때는 같은 방식으로 테스트해 연결할 수 없는 항목을 먼저 제외한 다음, 이용하려는 서비스에 필요한 지역과 프로토콜 설정, 실제 접속 결과를 함께 확인하세요. 목록에서 지연 시간이 가장 짧은 항목만 보고 바꾸기보다 반복해서 확인할 수 있는 테스트 기록을 만드는 것이 좋습니다. 본인이 이미 서비스 제공업체와 구독을 보유한 경우를 전제로 하며, 서비스 제공처를 선택하는 방법은 다루지 않습니다.

1. 테스트 대상과 실제 연결이 일치하는지 확인

Home에서 선택한 서버, Global Routing의 현재 모드, Config의 규칙이 실제 요청의 경로에 함께 영향을 줍니다. 목록에서 서버 테스트에 성공했더라도 웹페이지가 반드시 그 서버를 거치는 것은 아닙니다. 특히 Config 모드에서는 대상 도메인에 DIRECT 규칙이 적용될 수 있습니다. 이때 웹페이지 로딩 속도로 서버를 평가하면 테스트 대상과 결과가 달라집니다.

테스트를 시작하기 전에 대용량 파일 전송을 중지하고, 같은 Wi-Fi 또는 셀룰러 네트워크에서 진행하세요. 접속 네트워크를 바꾸면서 서버 두 개를 비교하면 무선 신호, 통신사 경로, 서버 자체의 영향이 뒤섞입니다.

목록 확인

Home으로 이동해 본인의 구독이 펼쳐져 있고 서버 목록이 비어 있지 않은지 확인하세요. 구독을 방금 업데이트했다면 항목 이름과 설정을 다시 확인하세요. 기존 항목이 여전히 같은 서버를 가리킨다고 단정하지 마세요.
모드 고정

Home → Global Routing으로 이동하세요. 규칙의 영향을 분리해야 한다면 잠시 Proxy를 선택하고, 테스트가 끝나면 기존 Config 등의 설정으로 되돌리세요. Direct는 프록시 서버를 통한 웹 접속 성능을 확인하는 용도가 아닙니다. Scene의 실제 동작은 선택한 시나리오에 따라 확인해야 합니다.
테스트 실행

Home으로 돌아가 Connectivity Test를 실행하세요. 사용한 테스트 방식을 기록하세요. ICMP, TCP, HTTP는 결과가 의미하는 바가 다르므로 서로 다른 방식으로 측정한 지연 시간을 한데 놓고 순위를 매기지 마세요.
항목별 확인

후보 서버 하나를 선택해 연결한 뒤 정해 둔 웹페이지에 접속하세요. 다른 후보도 같은 방식으로 확인하면서 접속 성공 여부, 시간 초과, 첫 화면이 표시되기까지 걸린 시간, 로딩 중단 여부를 기록하세요.
설정 복원

비교를 마치면 평소 사용하는 Global Routing 모드로 되돌린 뒤 해당 모드에서 대상 서비스에 다시 접속하세요. 결과가 달라졌다면 서버를 계속 바꾸기보다 규칙 적용 여부와 정책을 먼저 확인하세요.

2. 지연 시간으로 알 수 있는 것과 알 수 없는 것

지연 시간은 특정 시점에 특정 탐색 요청이 완료되는 데 걸린 시간입니다. 대역폭이나 웹페이지 전체 로딩 시간과는 다릅니다. ICMP는 주로 네트워크 계층의 응답을 확인하지만 서버에서 해당 패킷을 제한할 수 있습니다. TCP 테스트는 지정한 포트로 연결을 설정하는 상태를 확인합니다. HTTP 테스트는 테스트 주소, 애플리케이션 계층의 응답, 선택한 테스트 경로에도 영향을 받습니다. 테스트 방식이 명확해야 결과를 서로 비교할 수 있습니다.

목록 테스트 기록

접속 네트워크: 같은 Wi-Fi에서 테스트하고, 도중에 셀룰러로 전환하지 않기
테스트 방식: 항상 같은 방식으로 테스트하고 결과를 섞지 않기
반복 횟수: 후보별로 연속 3회 테스트하고 실패 기록도 남기기
중점 확인 사항: 계속 성공하는지, 결과 변동 폭이 큰지 확인

여기서 제안하는 3회는 테스트 방법에 관한 권장 사항이며, 앱에서 정해 둔 테스트 횟수가 아닙니다.

실제 접속 기록

라우팅 모드: DIRECT 규칙의 영향을 분리하려면 잠시 Proxy 사용
대상 주소: 매번 같은 웹페이지나 리소스 사용
확인 항목: 첫 접속, 로딩 지속 여부, 도중에 멈추는지 확인
재테스트 시간대: 평소 사용하는 시간대에 한 차례 더 테스트

웹페이지 캐시와 연결 재사용이 결과에 영향을 줄 수 있으므로 두 번째 접속 속도만 비교해서는 안 됩니다.

예를 들어 한 차례 테스트에서 후보 A의 TCP 결과가 45, 48, 210ms이고 후보 B가 85, 88, 86ms라고 가정해 보겠습니다. 이 결과로 알 수 있는 것은 이번 테스트에서 B의 응답이 더 안정적이었다는 점뿐이며, B의 다운로드 속도가 반드시 더 빠르다는 뜻은 아닙니다. 이는 수치 해석을 위한 예시이며, 본 사이트가 특정 서버를 직접 테스트한 결과가 아닙니다. A를 이용한 웹 접속에서도 자주 멈춘다면 A를 후보 목록에서 잠시 제외할 근거가 더해집니다.

지연 시간은 짧은데 웹페이지가 느림: 도메인 확인, TLS 핸드셰이크, 대상 사이트의 응답, 서버 출구의 부하를 추가로 살펴보세요. 지연 시간 하나만으로 문제 원인을 특정할 수는 없습니다.
간헐적으로 시간 초과 발생: 시간 초과 기록도 남기세요. 성공한 결과 중 가장 짧은 값만 고르면 간헐적인 연결 불가를 놓칠 수 있습니다.
전송 속도가 계속 느림: 지연 시간 테스트는 전송 데이터가 매우 적어 지속적인 전송 테스트를 대신할 수 없습니다. 대역폭 제한과 혼잡은 별도로 확인해야 합니다.

3. 거리가 아니라 출구 지역의 용도를 확인

서버 이름에 표시된 지역은 설정에 붙은 라벨일 뿐, 출구 위치를 독립적으로 확인해 주지는 않습니다. 진입 주소의 위치, 실제 경로가 지나는 지역, 대상 웹사이트가 파악하는 출구 IP의 지역은 서로 다를 수 있습니다. 물리적으로 가까우면 전파 시간이 줄어드는 데 도움이 될 수 있지만, 우회 경로나 네트워크 간 연결, 혼잡이 이점을 상쇄할 수 있습니다.

대상 서비스를 이용할 때 특정 지역 조건이 있다면 해당 서비스가 실제로 인식하는 지역과 접속 결과를 기준으로 판단하세요. 계정 지역, 위치 정보 권한, 이전 세션, 대상 사이트의 데이터베이스도 페이지 내용에 영향을 줄 수 있습니다. 홈페이지 언어만 바뀌었다고 네트워크 출구가 전환된 것으로 판단하지 마세요.

일반적인 웹 탐색: 접속 조건을 충족하는 후보 중에서 특정 지역이 항상 더 빠르다고 가정하지 말고 안정성과 실제 첫 화면 표시 시간을 비교하세요.
지역 제한이 있는 서비스: 먼저 필요한 출구 지역을 확인한 다음 같은 지역의 후보끼리 비교하세요. 지연 시간이 짧더라도 용도에 맞지 않는 항목은 비교할 필요가 없습니다.
모바일 환경: 집 Wi-Fi에서 잘 작동해도 셀룰러 네트워크에서 같은 결과가 나온다는 보장은 없습니다. 네트워크를 바꾼 뒤에는 같은 테스트를 다시 실행하세요.
장시간 세션: 로그인, 통화, 지속적인 데이터 전송 중에는 출구를 반복해서 바꾸지 마세요. 세션 중단을 서버 장애로 오인할 수 있습니다.

4. 이름으로 속도를 판단하지 말고 프로토콜 호환성을 확인

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 방식과 필요한 설정이 서로 다릅니다. 프로토콜 이름만으로 속도를 판단할 수는 없습니다. 서버 구성, 전송 방식, 접속 네트워크에서 해당 트래픽을 허용하는지, 설정값이 완전한지가 실제 사용 가능성에 더 직접적인 영향을 주는 경우가 많습니다. 기존 구독에 보통 필요한 값이 포함되어 있으므로 먼저 원래 설정을 유지한 채 확인하세요.

6종

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

443

HTTPS에서 흔히 사용하는 포트입니다. 서버 연결 포트는 본인의 설정을 기준으로 확인하세요.

UDP

Hysteria2는 QUIC 기반이고 WireGuard는 UDP를 사용하므로 네트워크에서 허용되는지 확인해야 합니다.

Trojan은 일반적으로 TLS를 사용합니다. VMess와 VLESS의 실제 전송 방식 및 TLS 설정은 구성에 따라 확인해야 하며, 프로토콜 이름만으로 추측해서는 안 됩니다. Hysteria2를 사용할 수 있는지는 UDP 경로에 영향을 받습니다. WireGuard는 키, 피어, 주소 설정도 올바르게 구성되어야 합니다. TCP 테스트만으로 UDP 기반 세션이 사용 가능한지 완전히 확인할 수 없으며 프로토콜 인증을 대신할 수도 없습니다.

포트: 443이 모든 문제를 해결하는 값은 아닙니다. 본인 서버가 실제로 다른 포트를 사용한다면 임의로 443으로 바꿀 경우 연결에 실패합니다.
TLS: 설정에 지정된 서버 이름과 인증서 요구 사항을 확인하세요. 평소 문제 해결 방법으로 인증서 검증을 끄지 마세요.
인증: 비밀번호, UUID 또는 키는 본인의 서버 설정과 일치해야 합니다. 포트에 연결할 수 있다고 인증에 성공한 것은 아닙니다.
전송: Type을 바꿔도 서버가 다른 프로토콜로 변환되지는 않습니다. 프로토콜과 관련 설정을 서로 맞춰야 합니다.

5. 증상별로 계층을 나누어 점검

문제를 해결할 때는 먼저 접속 네트워크를 확인하고, 이어서 서버에 연결할 수 있는지, 프로토콜 연결과 대상 서비스는 정상인지 차례로 살펴보세요. 한 번에 변수 하나만 바꾸고 같은 대상을 다시 테스트하세요. 지역과 프로토콜을 바꾸고 구독을 업데이트한 뒤 규칙까지 조정하면 접속이 복구되어도 어떤 조치가 효과가 있었는지 알기 어렵습니다.

지연 시간은 짧은데 웹페이지가 계속 로딩되는 이유는 무엇인가요?

먼저 Home → Global Routing에서 Proxy를 잠시 선택하고 해당 서버를 선택한 뒤 기존 웹페이지에 다시 접속하세요. 여전히 실패한다면 프로토콜 인증, TLS 설정, 대상 서비스 접속 가능 여부를 확인하세요. 정상적으로 접속된다면 Config로 돌아가 규칙과 정책을 확인하세요. 테스트가 끝나면 원래 라우팅 모드로 되돌리세요.

같은 서버가 집에서는 되는데 셀룰러에서는 안 되는 이유는 무엇인가요?

Wi-Fi와 셀룰러에서 각각 같은 테스트를 실행하고 사용한 프로토콜을 기록하세요. Hysteria2 또는 WireGuard를 사용한다면 UDP 경로가 제한되어 있는지 집중적으로 확인하세요. 한 번의 시간 초과만으로 서버 장애라고 판단하지 않도록 시스템에서 Shadowrocket의 셀룰러 데이터 사용을 허용했는지도 확인하세요.

구독을 업데이트한 뒤 기존에 선택한 항목이 바뀐 이유는 무엇인가요?

Home으로 돌아가 업데이트된 목록을 확인하고 후보를 다시 선택한 다음 Type, 서버 주소, 포트를 확인하세요. 구독 내용이 바뀌면서 항목 이름이 변경되거나 서버가 교체될 수 있으므로 기존 테스트 기록을 그대로 적용할 수 없습니다. 전체 구독 주소나 인증 정보를 공개된 문제 해결 기록에 올리지 마세요.

서버를 바꿨는데 대상 웹사이트가 달라 보이지 않는 이유는 무엇인가요?

먼저 Global Routing이 Direct로 설정되어 있지 않은지 확인한 다음 Config에서 대상 트래픽에 DIRECT가 적용되는지 살펴보세요. 기존 웹 세션을 종료하고 다시 접속하세요. 연결이 자동으로 복구되거나 전환 과정에서 영향을 받는다면 Settings → On Demand에서 현재 자동 연결 조건을 확인해 자동 동작과 수동 테스트 결과를 혼동하지 않도록 하세요.

6. 다음에도 활용할 수 있도록 선택 결과 기록

최종 후보는 세 가지 조건을 모두 충족해야 합니다. 대상 서비스를 이용할 수 있고, 실제 접속이 안정적이며, 평소 사용하는 네트워크에서도 같은 결과를 재현할 수 있어야 합니다. 지연 시간이 가장 짧은 항목은 1차 선별에 참고할 수 있지만 유일한 기준으로 삼아서는 안 됩니다. 평소 사용할 후보 하나와 검증된 예비 후보 하나를 기록해 두세요. 문제가 생기면 바로 바꾸기보다 먼저 다시 테스트해 일시적인 변동을 지속적인 문제로 오인하지 않도록 하세요.

접속 네트워크, 테스트 시간대와 방식, 후보 항목, 세 차례의 테스트 결과를 기록하세요. 실패한 결과도 빠뜨리지 마세요.
출구 지역이 용도에 맞는지, 정해 둔 웹페이지에 접속되는지, 로딩 도중 멈추는지 기록하세요. 비밀번호, 키, 전체 구독 주소는 기록하지 마세요.
구독을 업데이트하거나 접속 네트워크가 바뀌면 다시 확인하고, 이전 항목의 속도 순위를 그대로 적용하지 마세요.
임시 테스트가 끝나면 Config 등 평소 설정으로 되돌리고 대상 요청에 예상한 정책이 적용되는지 확인하세요.