Shadowrocket의 Home에 서버를 가져왔지만 어떤 항목을 선택해야 할지 잘 모르겠다면 이 글을 참고하세요. 먼저 테스트가 무엇을 측정하는지 확인한 뒤, 네트워크와 Global Routing을 동일하게 유지하면서 지연 시간·지역·프로토콜 설정·실제 웹페이지 로딩을 차례로 살펴봅니다. 구독 링크는 이용 중인 서비스 제공업체에서 받으세요. 이 글은 이미 보유한 서버를 판단하는 방법만 안내하며 서버 출처는 제공하지 않습니다.
1. Home에서 지연 시간 확인하기: 테스트 수치가 의미하는 것
Home을 열고 목록의 서버가 현재 사용하는 구독에서 가져온 항목인지 확인한 다음, Connectivity Test로 연결을 확인합니다. 결과를 보기 전에 테스트 방식과 대상을 확인하세요. 방식마다 측정하는 구간이 다르므로 ms로 표시된 모든 수치를 ‘웹페이지를 여는 데 걸리는 시간’으로 해석할 수는 없습니다.
TCP 연결 테스트는 지정한 서버 포트에 연결이 성립하는지 주로 확인하며, 프록시 요청 전체가 성공했음을 뜻하지는 않습니다. 프록시를 통해 테스트 대상에 접속하는 방식은 프록시 핸드셰이크, 대상 서버의 응답, 관련 이름 확인 과정에도 영향을 받습니다. 테스트에 성공해도 다른 웹사이트까지 모두 접속 가능하다는 뜻은 아니며, 시간 초과가 발생했다고 서버를 영구적으로 사용할 수 없다는 의미도 아닙니다.
지연 시간과 대역폭은 서로 다른 지표입니다. 짧은 테스트 요청이 빠르게 완료되어도 장시간 다운로드에 충분한 처리량이 보장되지는 않으며, 한 번의 테스트로 혼잡 시간대의 상태를 파악하기도 어렵습니다. 테스트 결과는 문제를 확인하는 단서로 보고 실제 작업으로 검증하세요. 한 번 측정한 최저 수치만으로 장기간 사용할 서버를 결정하지 마세요.
2. Global Routing을 고정하고 서버 비교하기
Home에서 Global Routing을 확인합니다. Config를 사용하면 현재 구성에 따라 요청이 분기되므로 특정 웹페이지가 DIRECT로 연결되거나 규칙에 따라 다른 정책을 사용할 수 있습니다. 이때 Home에서 현재 서버를 바꿔도 웹페이지의 실제 경로는 바뀌지 않을 수 있습니다. 서버를 비교하려면 먼저 라우팅 조건을 통일한 뒤 속도를 비교하세요.
-
비교할 항목 정하기
Home에서 이미 보유한 후보 서버를 2~3개 선택하고 이름, 지역 표시, 프로토콜을 기록합니다. 테스트 도중 목록이나 설정이 바뀌지 않도록 필요한 구독 업데이트를 먼저 마치세요.
-
네트워크 고정하기
같은 Wi-Fi 또는 같은 셀룰러 네트워크에서 테스트하고 대용량 파일 전송은 일시 중지하세요. 집의 Wi-Fi 결과와 외출 중 셀룰러 결과를 그대로 비교하지 마세요.
-
라우팅 확인하기
Home → Global Routing에서 현재 모드를 확인합니다. 짧게 프록시 경로를 비교하려면 Proxy를 사용할 수 있습니다. Config에 설정된 정책 선택도 확인하고, 테스트가 끝나면 원래 모드로 되돌리세요.
-
서버 선택하기
Home에서 후보 서버 왼쪽의 원형 버튼을 눌러 현재 항목으로 선택한 뒤, 상단 연결 스위치를 켭니다. 처음 연결할 때는 시스템 안내에 따라 VPN 구성을 추가하도록 허용하세요.
-
반복해서 확인하기
Connectivity Test 결과를 확인하고 같은 대상을 3회 테스트합니다. 그런 다음 같은 웹페이지를 열어 콘텐츠가 처음 표시되는 시점, 이미지 로딩 완료 여부, 오류 발생 여부를 기록하세요.
Global Routing의 Proxy, Direct, Config, Scene은 서로 다른 라우팅 모드이지 속도 등급이 아닙니다. Direct는 프록시 서버의 실제 접속 성능을 확인하는 데 적합하지 않습니다. Config에서는 적용 중인 구성과 일치한 정책을 함께 확인해야 합니다. Scene은 상황별 선택이 관련되므로 테스트 전에 실제로 적용되는 라우팅을 확인하세요. 상단 스위치가 켜져 있다는 이유만으로 모든 요청이 현재 서버를 통과한다고 판단하지 마세요.
3. 서버 지역 선택하기: 접속 위치와 출구 위치, 대상 웹사이트 구분
Home에 표시되는 지역명은 보통 서비스 제공업체가 지정한 이름이며, 이름만으로 접속 지점과 출구가 모두 해당 지역에 있다고 단정할 수는 없습니다. 기기가 처음 연결되는 위치와 트래픽이 최종적으로 대상 웹사이트에 접속하는 위치는 구분해야 합니다. 이름이 같은 서버 두 개도 네트워크 경로가 다를 수 있습니다.
지리적으로 가까운 서버는 1차 후보를 추리는 기준이 될 수 있지만, 네트워크 트래픽이 항상 지리적으로 가장 짧은 경로를 따라가는 것은 아닙니다. 네트워크 간 연결, 시간대별 혼잡, 서버에서 대상 웹사이트까지의 경로가 결과에 영향을 줍니다. 특정 지역의 웹사이트에 접속할 때는 출구 위치에 따라 웹사이트가 제공하는 콘텐츠 서버도 달라질 수 있으므로 기기에서 서버까지의 구간만 비교해서는 안 됩니다.
기기에서 서버까지
- 위치 확인
- Home에 표시된 현재 서버와 연결 설정
- 조건 유지
- 같은 Wi-Fi 또는 같은 셀룰러 네트워크
- 확인할 항목
- 연결 시간, 시간 초과 횟수, 반복 테스트 간 편차
- 지역 판단 기준
- 서비스 제공업체의 안내를 참고하고 이름만으로 경로를 추측하지 않기
이 구간의 성능이 좋아도 서버에서 대상 웹사이트까지의 경로를 확인해야 합니다.
서버에서 웹사이트까지
- 대상 고정
- 같은 웹페이지에서 같은 작업 수행
- 경로 확인
- 요청이 예상한 프록시 정책을 사용하는지 확인
- 확인할 항목
- 본문 표시, 리소스 로딩, 장시간 전송 중단 여부
- 재테스트 시간대
- 평소 자주 사용하는 시간대에 다시 테스트
자주 사용하는 대상의 결과를 기준으로 판단하고, 하나의 테스트 대상이 모든 웹사이트를 대표한다고 보지 마세요.
웹페이지가 계정 지역이나 출구 위치에 민감하다면 지역을 자주 바꿀 때 추가 인증이 발생할 수 있습니다. 웹사이트의 이용 조건에 맞는 안정적인 접속 환경을 유지하세요. 지연 시간 수치를 낮추려고 여러 지역을 계속 바꾸지 마세요.
4. 프로토콜 확인하기: 설정을 먼저 맞춘 뒤 네트워크 적응성 살펴보기
Home에서 서버 편집 화면을 열고 Type과 서비스 제공업체가 안내한 설정을 확인합니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 방식과 필요한 설정이 서로 다르며, 프로토콜 이름만으로 성능 순위를 매길 수는 없습니다. 구독에서 가져온 항목은 서비스 제공업체가 안내한 설정을 기준으로 사용하세요. Type만 바꾼다고 서버가 다른 프로토콜로 전환되는 것은 아닙니다.
| 프로토콜 | 우선 확인할 설정 | 테스트 시 유의사항 |
|---|---|---|
| Shadowsocks | 서버 주소, 포트, 암호화 방식, 비밀번호 | 포트에 연결된다고 암호화 방식과 비밀번호까지 올바른 것은 아니므로 프록시 요청을 확인해야 합니다. |
| VMess / VLESS | 인증 정보, 전송 방식 및 관련 보안 설정 | 구성에서 TLS 또는 특정 전송 경로를 사용하는 경우 관련 설정도 일치해야 합니다. |
| Trojan | 비밀번호, 포트 및 TLS 관련 설정 | 연결 시간 초과와 인증서 검증 실패는 각각 따로 확인하세요. 검증을 끄는 방식은 일반적인 해결 방법이 아닙니다. |
| Hysteria2 | 인증 정보, 포트 및 TLS 관련 설정 | 전송에 QUIC를 사용하므로 현재 네트워크에서 UDP 연결이 가능한지 확인해야 합니다. |
| WireGuard | 키, 피어 주소, 터널 주소 등의 설정 | UDP를 사용하므로 TCP 포트만 테스트해서는 터널 사용 가능 여부를 판단할 수 없습니다. |
서버 포트가 항상 443인 것은 아닙니다. 웹페이지에서 HTTPS를 자주 사용한다는 이유로 프록시 포트를 임의로 바꾸지 마세요. 현재 네트워크에서 특정 프로토콜만 실패하고 다른 기존 항목은 사용할 수 있다면 오류 양상을 기록하고 설정과 네트워크 제한을 확인하세요. 이를 근거로 해당 프로토콜이 모든 네트워크에서 작동하지 않는다고 판단해서는 안 됩니다.
- 프로토콜과 서버가 모두 다르면 회선과 부하도 결과에 영향을 줍니다. 차이를 전부 프로토콜 탓으로 돌릴 수는 없습니다.
- 같은 프로토콜도 시간대에 따라 결과가 달라질 수 있습니다. 혼잡 시간대의 영향을 고려해 비슷한 시간에 비교하세요.
- 설정이 불분명하거나 오래되었다면 먼저 서비스 제공업체에 확인하고, 필요한 경우 구독을 업데이트하세요. 인증 정보를 임의로 수정하지 마세요.
5. 실제 웹페이지로 확인하기: 첫 로딩과 지속 사용 구분
서버를 선택한 뒤 평소 이용하는 웹페이지나 앱 작업으로 확인합니다. 첫 로딩에는 이름 확인, 연결, 리소스 요청이 포함되며 이후 새로고침에서는 연결을 재사용하거나 로컬 캐시를 쓸 수 있습니다. 따라서 두 번째로 열었을 때 더 빠르다고 해서 서버 성능이 개선된 것은 아닙니다. 브라우저가 처리할 작업이 줄었기 때문일 수도 있습니다.
아래는 기록 방법이며 실제 성능 측정값이 아닙니다. 각 후보의 테스트 결과를 세 번씩 기록하고, 시간 초과 여부와 같은 작업의 완료 상태도 함께 적으세요. 가장 좋아 보이는 수치 하나만 남기지 마세요. 세 번 중 두 번 실패했다면 간혹 측정되는 낮은 지연 시간으로 사용성 문제를 상쇄할 수 없습니다.
- 텍스트 페이지: 본문이 표시되는지, 반복해서 대기하거나 연결 오류가 발생하는지 확인합니다.
- 이미지가 많은 페이지: 이미지가 차례로 모두 로드되는지 확인합니다. 특정 리소스 도메인만 실패한다면 규칙에 따른 라우팅 때문일 수 있습니다.
- 장시간 전송 작업: 이용 권한이 있는 콘텐츠로 전송이 자주 멈추는지 확인합니다. 짧은 테스트 요청만으로 장시간 처리량을 추정하지 마세요.
- 네트워크 전환: Wi-Fi와 셀룰러 결과를 각각 기록합니다. 같은 서버도 두 네트워크에서 성능이 다를 수 있습니다.
6. 자주 묻는 질문: 지연 시간이 낮은데 느림, 시간 초과, 서버 변경 후에도 차이 없음
수십 ms로 표시되는데 웹페이지는 왜 느린가요?
먼저 Home에서 Global Routing과 현재 서버를 확인한 뒤 Connectivity Test로 검증하세요. 테스트가 연결 성립이나 특정 테스트 대상만 확인했을 수 있지만 웹페이지에는 다른 도메인과 리소스도 포함됩니다. 본문은 정상인데 이미지가 멈춘다면 지연 시간 순위만 다시 매기지 말고 실제 요청에 적용된 정책, 리소스 접속 가능 여부, 지속 전송 상태를 확인하세요.
시간 초과로 표시되면 서버 항목을 삭제해야 하나요?
먼저 항목을 그대로 두고 같은 네트워크에서 다시 테스트한 뒤 이미 보유한 다른 항목과 비교하세요. 모두 시간 초과라면 로컬 네트워크와 테스트 대상을 확인합니다. 이 항목만 실패한다면 주소, 포트, 인증 설정을 확인하세요. 업데이트가 필요하면 서비스 제공업체에서 받은 구독을 사용하고, 업데이트 후 현재 선택된 항목을 다시 확인하세요.
서버를 바꿨는데 웹페이지가 전혀 달라 보이지 않나요?
Home에서 새 항목 옆의 원형 버튼이 선택되어 있는지, 연결 상태가 정상인지 확인하세요. 이어서 Global Routing을 확인합니다. Config에서는 규칙이나 정책 그룹이 Home에서 선택한 항목을 사용하지 않을 수 있습니다. 기존 연결이 아직 전환되지 않았을 수도 있으니 새 요청을 보내 다시 확인하세요. 페이지를 한 번 새로고침한 결과만으로 전환 실패를 판단하지 마세요.
셀룰러로 전환하면 자동 연결되어 비교에 영향을 줍니다. 어떻게 해야 하나요?
Settings → On Demand에서 설정된 자동 연결 조건을 확인하세요. 테스트 중에는 네트워크를 바꾸지 않아 자동 연결 동작과 수동 전환이 섞이지 않도록 합니다. On Demand를 임시로 조정했다면 원래 설정을 기록해 두고 테스트 후 복원하세요. On Demand는 연결이 시작되는 조건을 관리할 뿐, 회선을 자동으로 최저 지연 시간으로 바꾸지는 않습니다.
최종 선택은 설정과 연결이 정상인지 확인하고, 대상 웹사이트에 접속한 뒤, 자주 사용하는 시간대에도 안정적인지 살펴본 다음 지연 시간을 비교하는 순서로 진행하세요. 같은 방식으로 검증한 기존 후보 하나를 대체 항목으로 남겨 두면 충분합니다. 목록의 모든 항목을 순위별로 테스트할 필요는 없으며, 한 번의 테스트 결과를 장기적으로 보장되는 성능으로 받아들이지 마세요.