Shadowrocket에서 서버를 선택할 때는 먼저 연결 가능 여부를 확인하고, 여러 차례 테스트해 안정성을 비교한 다음 실제 웹페이지나 동영상으로 검증하세요. 이미 서비스와 구독을 이용 중인 사용자를 대상으로 Home → Connectivity Test 결과의 의미, 지역과 프로토콜을 살펴보는 방법, 구독 설정을 바꾸지 않고 평소 사용할 서버와 예비 서버를 정하는 방법을 설명합니다.
1. 지연 시간, 처리량, 실제 사용 가능성을 구분하세요
지연 시간이 낮다는 것은 한 번의 테스트에서 응답을 빨리 받았다는 뜻이지, 지속적인 데이터 전송 속도까지 빠르다는 뜻은 아닙니다. 처리량은 단위 시간당 전송되는 데이터의 양을 나타냅니다. 실제 사용 가능성에는 연결 성공 여부, 대상 서비스 접속 가능 여부, 연결이 오래 유지되는지도 포함됩니다. 세 지표는 서로 관련이 있지만 같은 의미는 아닙니다. 서버를 선택할 때 SERVER 목록에서 가장 낮은 수치만 보고 결정하지 마세요.
Home에서 Connectivity Test로 이동해 테스트 메뉴를 확인하세요. 결과를 보기 전에 테스트 방식과 대상부터 확인해야 합니다. TCP 연결 테스트는 서버의 지정 포트에 연결이 성립하는 과정을 주로 확인합니다. 프록시를 통해 HTTP 또는 HTTPS 대상에 접속하는 테스트에는 프록시 핸드셰이크, 이름 확인, 대상 사이트의 응답이 추가로 포함될 수 있습니다. 방식에 따라 측정하는 경로가 다르므로 결과를 그대로 한데 놓고 비교하기는 어렵습니다. 선택 가능한 항목은 앱의 영어 인터페이스를 기준으로 확인하세요.
서버 포트는 서비스 제공자가 안내한 설정과 일치해야 합니다. 예를 들어 원래 설정이 8443이라면 “더 빠르게” 하려고 임의로 443으로 바꾸면 안 됩니다. 포트 번호는 속도 등급이 아닙니다. 테스트에 성공해도 이번 탐지에서 확인한 단계가 정상이라는 뜻일 뿐, 동영상 재생이나 업로드 또는 모든 웹사이트가 정상이라는 보장은 없습니다.
결론: 테스트를 안정적으로 마치는 서버를 후보로 남기세요
테스트 방식과 대상을 고정하고 세 차례 연속으로 확인하세요. 반복해서 시간 초과가 발생하는 후보를 먼저 제외한 뒤, 남은 후보로 같은 실제 대상을 접속해 보세요. 한 번 측정한 최저값만으로 결정하지 마세요.
2. 정해진 순서로 테스트해 네트워크 변화를 서버 차이로 착각하지 마세요
한 번에 한 가지 조건만 바꾸세요. 기기, 현재 네트워크, 테스트 방식과 대상을 먼저 고정한 다음 서버를 바꿔 비교합니다. Wi-Fi 결과와 셀룰러 네트워크 결과를 그대로 비교하거나, 대용량 파일을 내려받으면서 테스트 수치로 연결 품질을 판단하지 마세요. 일괄 테스트는 후보를 추리는 데 활용하고, 최종 후보는 하나씩 다시 테스트해야 일시적인 변동을 구분하기 쉽습니다.
- 목록 출처를 확인하세요.Home의 SERVER 영역에서 기존 구독에 포함된 항목을 찾아 이름과 그룹을 확인합니다. 서비스 제공자가 설정을 변경했다면 비교를 시작하기 전에 해당 구독을 업데이트하세요.
- 테스트 조건을 고정하세요.Home → Connectivity Test에서 같은 테스트 방식을 사용하세요. 테스트 중에는 같은 Wi-Fi 또는 같은 셀룰러 네트워크를 유지하고, 다른 기기의 대용량 데이터 전송은 일시 중지하세요.
- 세 차례 기록하세요.각 회차의 응답값, 시간 초과 여부, 테스트 시각과 네트워크 종류를 적어 두세요. 회차 사이에 잠시 간격을 두고, 가장 잘 나온 결과만 기록하지 마세요.
- 후보를 선택한 뒤 연결하세요.현재 선택된 항목을 확인하고 Home → Global Routing도 살펴보세요. 정책 그룹을 사용한다면 그룹 안에서 실제로 선택된 항목도 확인해야 합니다. 목록에서만 선택을 바꾸고 대상 트래픽은 다른 경로를 계속 사용하는 상황을 방지할 수 있습니다.
- 실제 작업으로 검증하세요.같은 웹페이지를 열고 처음 로딩할 때와 새로고침할 때를 비교하세요. 같은 동영상과 고정된 화질로 재생 시작, 탐색, 연속 재생 상태를 확인하세요. 연결 재사용이 판단에 영향을 주지 않도록 기존 테스트 연결을 먼저 끊으세요.
다음은 기록 방법을 설명하기 위한 가정 사례이며 실제 연결 측정값이나 성능 보장이 아닙니다. 후보 A의 세 차례 결과는 42 / 260 / 시간 초과, 후보 B는 88 / 91 / 89 ms라고 가정해 보겠습니다. A의 최저값은 더 낮지만 변동이 큽니다. B를 실제 작업으로 검증하는 편이 낫습니다. 세 번의 표본은 후보를 추리는 데만 활용할 수 있으며, 장기적인 패킷 손실률을 계산하거나 다른 시간대의 성능을 보장할 수는 없습니다.
3. 지역 이름은 참고 정보일 뿐, 전체 접속 경로를 확인하세요
지역 간 거리는 전파 지연에 영향을 주지만, 기기에서 입구 서버까지, 입구에서 출구까지, 출구에서 대상 웹사이트까지의 경로는 각각 다릅니다. 서버 이름에 포함된 지역 표기는 대개 제공자가 붙인 정보로, 이름만으로 실제 입구나 출구의 위치 또는 중간 라우팅을 확정할 수 없습니다. 물리적으로 가까워도 경로 우회, 상호 접속망 혼잡, 서버 부하 때문에 느릴 수 있습니다.
지역을 비교하기 전에 어떤 작업을 할지 정하세요. 웹페이지 조작이나 원격 상호작용에서는 응답 대기가 두드러질 수 있고, 장시간 동영상을 볼 때는 데이터를 지속해서 공급하는 능력이 더 중요합니다. 대상 서비스는 출구 IP에 따라 콘텐츠 전송 지점을 달리 선택할 수도 있으므로 같은 후보라도 웹사이트마다 체감이 다를 수 있습니다. “서버까지 빠르다”는 이유만으로 “대상 웹사이트까지 빠르다”고 단정하지 마세요.
확인 방법: 실제 작업에 따라 후보를 따로 정하세요
웹페이지 및 상호작용 작업
- 같은 대상 페이지를 고정하고 첫 접속과 반복 작업을 비교하세요.
- 최저 지연 시간보다 응답의 안정성을 우선해서 확인하세요.
- 로그인 후 이동, 이미지 로딩, 요청 제출이 모두 정상인지 살펴보세요.
동영상 및 지속적인 데이터 전송
- 동영상과 화질을 고정해 자동 화질 저하가 차이를 가리지 않게 하세요.
- 재생 시작, 탐색, 연속 재생 중 끊김이 있는지 각각 확인하세요.
- 평소 이용하는 시간대에 다시 테스트하고 혼잡이 반복되는지 기록하세요.
지역 정보는 후보를 좁히는 데 활용하세요. 최종 선택은 현재 네트워크에서 실제 대상까지 이어지는 전체 경로에 따라 달라집니다.
Wi-Fi나 셀룰러 네트워크를 바꾸거나 다른 도시로 이동하면 기존 순위가 달라질 수 있습니다. 이미 검증한 후보를 매일 모두 다시 고를 필요는 없습니다. 사용 경험의 변화가 계속될 때 같은 절차로 재검사하세요. 순간적으로 가장 낮은 수치를 계속 좇기보다 검증된 예비 항목 하나를 남겨 두는 편이 문제를 확인하기 쉽습니다.
4. 프로토콜은 적합한 환경을 확인하고, 이름만으로 속도를 순위 매기지 마세요
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 방식과 설정값이 서로 다릅니다. 프로토콜이 정상 작동하려면 먼저 서버와 클라이언트의 설정이 일치해야 하며, 현재 네트워크가 해당 전송 방식을 지원하는지도 중요합니다. 프로토콜 이름만으로 “고속”이나 “저지연”을 보장할 수 없습니다. 기존 항목의 Type만 바꿔 다른 프로토콜로 사용할 수도 없습니다.
| 프로토콜 | 알아둘 특성 | 비교 전에 확인할 항목 |
|---|---|---|
| Shadowsocks | 설정에 지정된 암호화 방식과 인증 정보를 사용합니다. | 서버 주소, 포트, 암호화 방식, 비밀번호가 서로 일치하는지 확인합니다. |
| VMess / VLESS | 다양한 전송 방식과 보안 설정을 함께 사용할 수 있어 프로토콜 이름만으로 전체 연결 경로를 알 수 없습니다. | 인증 정보, 전송 방식, 서버에서 요구하는 TLS 등의 설정을 확인합니다. |
| Trojan | 일반적으로 TLS를 사용해 연결합니다. | 비밀번호, 서버 이름, 인증서 검증이 원래 설정과 일치하는지 확인합니다. |
| Hysteria2 | QUIC 기반이며 UDP에 연결할 수 있어야 합니다. | 현재 네트워크에서 해당 UDP 트래픽을 허용하는지, 인증 설정이 일치하는지 확인합니다. |
| WireGuard | UDP를 사용하며 키와 터널 설정으로 통신을 구성합니다. | 키, 피어 주소, 터널 설정이 모두 일치하는지 확인합니다. |
예를 들어 특정 Wi-Fi 네트워크가 UDP를 제한하면 UDP에 의존하는 후보는 정상 연결되지 않을 수 있습니다. 그렇다고 해당 프로토콜이 모든 네트워크에서 느리다는 뜻은 아닙니다. 반대로 TCP 연결 테스트에 성공해도 UDP를 사용하는 서비스가 정상이라는 보장은 없습니다. 하나의 테스트 결과로 모든 프로토콜을 평가하지 말고 실제 작업으로 확인하세요.
- 프로토콜을 비교할 때는 출구 지역, 테스트 대상, 테스트 시각을 가능한 한 비슷하게 맞추세요. 서버 차이가 프로토콜 차이보다 더 크게 작용할 수 있습니다.
- 구독에 포함된 원래 설정을 그대로 유지하고, 테스트를 통과시키려고 인증서 검증을 끄지 마세요.
- 문제 해결 기록을 공유할 때는 비밀번호, 키, 인증 정보, 구독 주소 전체를 숨기고 필요한 프로토콜 이름과 증상만 기록하세요.
5. Global Routing을 확인해 선택한 서버가 아닌 다른 경로를 측정하는 일을 방지하세요
서버를 바꿨는데 웹페이지 반응이 전혀 달라지지 않는다면 먼저 라우팅을 확인하세요. Home → Global Routing에서 전체 트래픽 처리 방식을 정합니다. 이는 속도 등급이 아닙니다. Config 페이지의 규칙과 정책에 따라 대상 요청이 실제로 사용하는 출구도 달라집니다. 대상 트래픽이 선택한 후보를 통과하는지 확인해야 테스트 결과를 비교할 수 있습니다.
Config
권장현재 활성화된 설정의 규칙에 따라 트래픽을 처리합니다. 규칙에 일치한 요청은 지정된 정책에 따라 처리되며, 앞선 규칙에 해당하지 않은 요청은 이후 규칙이나 FINAL에 따라 결정됩니다. 모든 요청이 직접 연결된다고 볼 수는 없습니다.
적합한 경우: 규칙과 정책의 연결 대상을 확인한 뒤 일상적으로 사용할 때
Proxy
전체 트래픽을 프록시 방식으로 처리합니다. 규칙 분기로 인한 변수를 일시적으로 줄이는 데 활용할 수 있지만, 실제 프록시 선택과 연결 성공 여부는 따로 확인해야 합니다.
적합한 경우: 규칙 때문에 대상이 다른 경로를 사용하는지 잠시 확인할 때
Direct
전체 트래픽을 직접 연결 방식으로 처리합니다. 이때 대상에 접속한 결과로 선택한 프록시 서버를 평가할 수는 없습니다. 현재 네트워크에서 해당 대상에 직접 연결되는지 확인할 때 사용할 수 있습니다.
적합한 경우: 직접 연결 결과와 비교할 때. 서버 속도 테스트 결과로 사용하는 것은 적합하지 않습니다.
Scene을 사용하는 경우 실제 적용되는 장면의 설정을 확인하세요. 장면 이름이 고정된 출구를 뜻하지는 않습니다. Settings → On Demand를 사용한다면 테스트 중 필요에 따른 연결 설정이 연결 상태를 바꾸는지도 확인하세요. 중요한 것은 테스트 조건을 일관되게 유지하는 것이며, 속도를 측정하려고 평소 설정을 영구적으로 바꾸는 것이 아닙니다.
결론: 서버를 바꾼 뒤에는 차이를 해석하기 전에 경로를 확인하세요
Global Routing, 규칙 정책, 현재 프록시 선택을 확인한 뒤 대상 연결을 새로 만드세요. 비교를 위해 잠시 Proxy를 사용했다면 테스트가 끝난 후 평소 설정으로 되돌리세요.
6. 지연 시간은 낮은데 웹이나 동영상이 느릴 때 증상별로 확인하세요
테스트 수치와 실제 체감이 다르면 먼저 “처음부터 느린 경우”와 “전송이 한동안 진행된 뒤 느려지는 경우”를 구분하세요. 전자는 이름 확인, 핸드셰이크, 대상 사이트 응답, 라우팅 선택과 관련 있을 수 있습니다. 후자는 지속 처리량, 혼잡, 연결 안정성을 확인하는 것이 좋습니다. 다음 순서대로 점검하면 불필요한 설정 변경을 줄일 수 있습니다.
- 테스트는 빠른데 모든 대상이 느린 경우:테스트 방식이 서버까지의 연결만 확인하는지 먼저 살펴보고 Global Routing과 실제 출구도 확인하세요. 백그라운드 데이터 전송을 일시 중지하고 이미 검증한 다른 후보와 비교하세요.
- 특정 웹사이트 하나만 느린 경우:다른 대상을 테스트해 해당 사이트의 응답, 콘텐츠 전송 경로, 접속 제한 문제인지 확인하세요. 한 사이트의 문제만으로 서버 전체를 사용할 수 없다고 단정할 수는 없습니다.
- 동영상은 바로 시작하지만 반복해서 버퍼링되는 경우:화질을 고정하고 계속 확인하세요. 짧은 핸드셰이크가 빠르다고 지속 처리량까지 충분한 것은 아닙니다. 비슷한 시간대에 예비 후보와 비교하는 것이 더 유용합니다.
- 저녁에는 느리고 다른 시간대에는 정상인 경우:같은 대상을 시간대별로 확인해 기록하고 공유 경로의 혼잡이나 부하 변화를 고려하세요. 한 번의 혼잡 시간대 결과만으로 프로토콜 설정을 바꾸지 마세요.
- 모든 후보에서 동시에 시간 초과가 발생하는 경우:먼저 기기의 현재 네트워크가 정상인지 확인한 뒤 구독이 최신인지, 서비스 설정이 바뀌었는지 확인하세요. 여러 후보에서 동시에 문제가 생기면 공통 원인을 먼저 찾아보는 것이 좋습니다.
문제를 문의할 때는 기기의 네트워크 종류, 프로토콜 이름, 테스트 방식, 발생 시간대, 특정 대상에서만 문제가 생기는지, 다른 후보로 바꿨을 때의 결과를 기록하세요. 실제 인증 정보는 공개하지 마세요. 이런 기록은 가장 낮은 지연 시간이 표시된 스크린샷 한 장보다 로컬 네트워크, 서비스 설정, 대상 사이트 중 어디에 문제가 있는지 구분하는 데 도움이 됩니다.