Shadowrocket의 지연 시간 수치는 특정 조건에서 한 번 측정한 결과일 뿐, 속도 순위가 아닙니다. 이미 서비스 제공업체와 구독을 이용 중인 경우를 전제로, 테스트 조건을 통일하고 지역과 프로토콜을 확인한 뒤 실제 규칙이 적용되는 경로를 점검하는 방법을 안내합니다. 기존 서버 중 주 서버와 예비 서버를 정할 때는 실제 요청을 처리할 수 있는지와 안정성을 먼저 확인하고, 지연 시간은 마지막에 비교하세요.
1. 지연 시간 테스트로 알 수 있는 것과 알 수 없는 것
지연 시간은 보통 밀리초(ms)로 표시되며, 특정 테스트에 걸린 시간을 뜻합니다. 먼저 테스트 방식을 확인해야 합니다. TCP 연결 테스트는 서버 포트에 연결을 설정하는 데 걸린 시간을 주로 보여 줍니다. 프록시를 통해 테스트 주소에 접속하는 방식은 프록시 핸드셰이크, 테스트 주소의 DNS 조회, 대상 사이트의 응답에도 영향을 받습니다. 두 방식의 수치를 같은 순위표에서 직접 비교할 수는 없습니다.
Home에서 기존 서버의 지연 시간을 테스트하기 전에 Settings에서 현재 테스트 방식을 확인하세요. 테스트 주소를 사용하는 방식이라면 주소도 동일하게 유지해야 합니다. 메뉴 위치와 선택 가능한 테스트 방식은 현재 앱에 표시되는 내용을 기준으로 확인하세요. 한 번 테스트에 성공했다는 것은 해당 테스트가 그 시점에 완료됐다는 뜻일 뿐, 웹페이지 접속이나 지속적인 데이터 전송, 실시간 통화까지 정상이라는 의미는 아닙니다.
| 확인된 결과 | 판단할 수 있는 내용 | 바로 판단할 수 없는 내용 |
|---|---|---|
| TCP 연결 시간이 짧음 | 테스트 당시 대상 포트에 빠르게 연결됨 | 프록시 인증이 올바르고 대상 웹사이트가 반드시 열린다는 점 |
| 프록시 요청 테스트 성공 | 지정된 경로를 통해 해당 테스트 요청이 완료됨 | 다른 웹사이트나 UDP 앱도 반드시 정상 작동한다는 점 |
| 한 번의 시간 초과 | 제한 시간 안에 테스트가 완료되지 않음 | 서버가 영구적으로 중단됐거나 비밀번호가 반드시 틀렸다는 점 |
| 테스트 결과가 매번 크게 다름 | 테스트 경로나 대상에 변동이 있어 추가 확인이 필요함 | 가장 낮게 나온 한 번의 결과만으로 주 서버를 선택할 수 있다는 점 |
처리량은 일정 시간 동안 전송할 수 있는 데이터의 양을, 지연 시간은 한 번의 응답을 기다리는 시간을 나타냅니다. 서로 다른 지표입니다. 작은 요청에 빠르게 응답하는 연결도 지속 전송 시에는 가용 대역폭, 혼잡, 패킷 손실, 서버 부하의 영향을 받을 수 있습니다. 반대로 핸드셰이크가 조금 느린 연결도 설정이 끝난 뒤에는 안정적으로 데이터를 전송할 수 있습니다.
2. Global Routing을 고정한 뒤 기존 서버 비교하기
Home에서 선택한 서버를 바꿔도 모든 요청이 해당 서버를 사용한다는 보장은 없습니다. Global Routing 모드, 현재 Config의 규칙, 정책 그룹 선택에 따라 실제 경로가 달라집니다. 테스트하려는 웹페이지가 규칙에 따라 Direct로 연결된다면, 해당 페이지의 로딩 속도로 현재 선택된 프록시 서버를 평가할 수 없습니다.
Config: 평소 사용 환경에서 확인
권장현재 설정의 규칙과 정책에 따라 연결을 처리합니다. 먼저 테스트 대상이 어떤 정책과 일치하는지 확인한 다음, 그 정책에서 실제로 사용하는 서버를 점검하세요. 중국 본토의 모든 주소가 Direct를 사용하거나 그 밖의 모든 주소가 Proxy를 사용한다고 미리 단정할 수 없습니다.
적합한 경우: 평소의 분할 라우팅을 유지하면서 실제 사용 환경을 확인할 때
Proxy: 규칙 영향을 잠시 분리
Shadowrocket이 처리하는 연결을 프록시 경로로 보내 Config의 분할 라우팅이 문제의 원인인지 확인할 수 있습니다. 네트워크나 대상 사이트에 반드시 연결된다는 뜻은 아닙니다. 테스트를 마치면 원래 모드로 복구하세요.
적합한 경우: 같은 웹페이지를 잠시 비교해 규칙이나 정책 선택 문제를 확인할 때
Direct: 직접 연결 기준선
처리 범위에 포함된 연결을 직접 연결 경로로 보냅니다. 이때 확인한 웹페이지 이용 경험은 선택한 프록시 서버의 성능이 아니라 현재 네트워크에서 직접 연결했을 때의 참고 결과입니다.
적합한 경우: 직접 연결에서도 대상에 같은 문제가 발생하는지 확인할 때
Scene을 사용한다면 현재 네트워크에서 실제로 어떤 라우팅 모드가 적용되는지 먼저 확인하세요. Scene 이름을 별도의 지연 시간 테스트 방식으로 여겨서는 안 됩니다. 문제를 확인하는 동안 Settings → On Demand도 점검해 자동 연결 조건이 방금 수동으로 끊은 연결을 다시 바꾸지 않도록 하세요.
- Home → Global Routing에서 현재 선택한 모드와 Config에서 사용 중인 설정을 기록합니다.
- 기존 서버 하나를 선택하고 같은 테스트 방식으로 연속 세 번 측정합니다. 성공한 수치뿐 아니라 시간 초과도 기록하세요.
- 연결한 뒤 고정된 테스트 대상에 접속하고, 요청 기록에 표시된 규칙·정책·서버가 예상과 일치하는지 확인합니다.
- 다음 서버를 테스트할 때는 서버 선택만 바꾸고 네트워크, 대상 주소, 라우팅 모드는 그대로 유지합니다.
- 비교를 위해 Proxy로 잠시 전환했다면 테스트가 끝난 후 원래 Config 또는 Scene 설정으로 복구합니다.
3. 지역 표시는 범위를 좁히는 참고 자료일 뿐, 연결 경로 확인을 대신하지 않습니다
서버 이름에 표시된 지역은 대개 설정 제공자가 붙인 라벨이며, 클라이언트가 물리적 위치를 독립적으로 인증한 결과가 아닙니다. 진입 주소의 위치, 최종 출구 주소의 위치, 대상 웹사이트가 판단하는 지역은 서로 다를 수 있습니다. 이름에 ‘가깝다’고 표시되어도 네트워크 경로가 짧다는 뜻은 아닙니다. 통신사 간 연결과 우회 라우팅에 따라 실제 소요 시간이 달라집니다.
지역을 선택하기 전에 어떤 용도로 사용할지 먼저 생각하세요. 일반적인 웹 이용에서는 요청이 안정적으로 완료되는지가 중요합니다. 특정 지역에서만 제공되는 콘텐츠를 이용하려면 대상 서비스가 인식하는 실제 출구 지역을 확인해야 합니다. 이름이나 지연 시간, 단일 IP 주소의 위치 조회 결과만으로는 대상 서비스가 해당 출구를 허용한다고 보장할 수 없습니다.
Wi-Fi와 셀룰러 네트워크를 나눠서 확인
Wi-Fi
- 같은 Wi-Fi 액세스 포인트에 연결하고 대용량 작업은 일시 중지합니다.
- 자주 이용하는 대상 하나를 먼저 확인한 다음, 다른 대상도 테스트합니다.
- 평소 이용하는 시간대에 시간 초과와 연결 끊김이 발생하는지 기록합니다.
셀룰러 네트워크
- Wi-Fi 연결이 해제됐는지 확인해 접속 네트워크를 잘못 기록하지 않도록 합니다.
- 가능한 한 같은 장소에서 동일한 테스트를 반복합니다.
- 네트워크를 전환한 뒤에는 테스트 연결을 새로 설정하고 이전 요청을 재사용하지 않습니다.
같은 서버라도 두 접속 네트워크에서 나온 결과는 따로 기록해야 합니다. 현재 주로 사용하는 네트워크에 맞춰 주 서버를 정하고, 기존 목록에서 실제로 확인한 예비 서버도 골라 두세요.
테스트 시간대도 통일해야 합니다. 오전에는 정상인데 저녁마다 연결이 끊긴다면 사용량이 많은 시간대의 혼잡이나 서버 부하가 원인일 수 있습니다. 서버 이름에 적힌 지역만으로는 설명되지 않습니다. 문제가 잘 발생하는 시간대에 다시 테스트한 뒤 선택을 조정하세요. 한 번 가장 낮게 나온 지연 시간을 좇아 서버를 자주 바꾸지는 마세요.
4. 프로토콜 유형은 연결 조건을 결정하지만, 고정된 속도 순위를 뜻하지 않습니다
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 프로토콜 유형을 나타내는 이름이지 회선 품질 등급이 아닙니다. 서버 측에서 해당 프로토콜과 매개변수를 지원해야 합니다. 기존 설정의 유형을 다른 프로토콜로 바꿔도 서버에 그 기능이 생기는 것은 아닙니다. 오히려 핸드셰이크가 실패할 수 있습니다.
| 프로토콜 | 확인할 조건 | 문제 확인 시 참고 사항 |
|---|---|---|
| Shadowsocks | 주소, 포트, 암호화 방식, 비밀번호. 플러그인이 있다면 해당 설정도 일치해야 합니다 | TCP가 작동하더라도 UDP 전달 설정까지 올바르다는 뜻은 아닙니다 |
| VMess / VLESS | 사용자 ID, 전송 방식, 설정에서 요구하는 TLS, Host, 경로 등의 매개변수 | 주소와 포트만 확인해서는 핸드셰이크에 필요한 조건이 모두 갖춰졌는지 알 수 없습니다 |
| Trojan | 비밀번호, TLS, 서버 이름 등 실제 설정에 사용된 매개변수 | 포트 연결에 성공해도 TLS와 인증이 성공한 것은 아닙니다 |
| Hysteria2 | QUIC 기반 UDP 연결 가능 여부, 인증, TLS 매개변수 | 네트워크에서 UDP가 제한되면 TCP 테스트 결과로 실제 프로토콜의 작동 여부를 판단할 수 없습니다 |
| WireGuard | 키, Peer, Endpoint, 터널 주소 등의 설정 | UDP를 사용합니다. Endpoint 주소만으로는 터널을 올바르게 설정할 수 없습니다 |
예를 들어 설정에서 TCP 443을 사용한다면 포트에 연결된 뒤에도 TLS나 인증 단계에서 실패할 수 있습니다. UDP 443을 사용한다면 TCP 443 연결 성공으로 UDP 연결까지 가능하다고 증명할 수 없습니다. 포트 번호가 같아도 전송 방식은 다릅니다. 기존 설정에 맞춰 확인하고, 모든 서버를 443으로 일괄 변경하거나 한 번의 테스트를 성공시키려고 인증서 검증을 끄지 마세요.
결론: 먼저 프로토콜 연결을 확인한 뒤 실제 작업으로 비교하세요
기존 설정이 셀룰러 네트워크에서만 실패한다면 해당 네트워크에서 사용하는 전송 방식의 연결 가능 여부와 핸드셰이크 기록을 먼저 확인하세요. 프로토콜 전체가 느리다고 바로 결론 내려서는 안 됩니다. 인증과 대상 요청이 완료된 뒤 동일한 작업에서 응답 대기 시간, 끊김, 지속적인 안정성을 비교하세요.
5. 지연 시간, 규칙, DNS, 구독 문제를 나눠서 확인하기
‘서버 지연 시간 테스트는 통과했는데 웹페이지가 열리지 않는’ 경우는 테스트 범위와 실제 요청 경로가 다를 때 흔히 발생합니다. 테스트는 포트 연결만 확인했을 수 있지만, 웹페이지를 열려면 도메인 조회, 프록시 인증, 올바른 정책 적용, 대상 사이트 접속까지 필요합니다. 서버를 계속 바꾸고 점검을 끝내기보다 요청 경로를 따라 단계별로 확인하세요.
- 먼저 규칙을 확인하세요: Config에서 사용 중인 설정의
DOMAIN-SUFFIX,GEOIP,IP-CIDR,FINAL순서와 적용 대상 정책을 확인합니다. 규칙은 순서대로 일치 여부를 확인하며,FINAL은 앞선 규칙에 일치하지 않은 연결을 처리합니다. - 다음으로 정책을 확인하세요: 규칙에 일치한 정책은 Direct일 수도 있고 다른 정책 그룹일 수도 있습니다. Home에서 현재 선택한 항목이 해당 요청에 최종적으로 사용되는 서버라는 보장은 없습니다.
- DNS를 확인하세요: 주소로는 연결되지만 도메인 요청이 실패한다면 현재 Config의 DNS 설정과 요청 기록을 확인합니다. DNS, 프로토콜, 서버를 한꺼번에 바꾸면 어떤 변경이 효과를 냈는지 파악하기 어렵습니다.
- 구독을 확인하세요: 기존 서비스의 주소, 포트, 인증 정보가 바뀌었다면 먼저 Home에서 해당 구독을 업데이트한 다음 업데이트된 항목을 테스트하고 있는지 확인합니다. 목록 업데이트에 성공했다고 해서 모든 항목을 사용할 수 있다는 뜻은 아닙니다.
- 연결을 새로 요청하세요: 설정을 바꾼 후에는 이전 테스트 페이지를 닫고 새로 요청합니다. 기존 장시간 연결은 잠시 이전 경로를 유지해 비교 결과에 영향을 줄 수 있습니다.
문제를 확인한 결과를 기록할 때는 서버를 구분하기 위한 로컬 이름, 접속 네트워크, 테스트 방식, 증상만 적으세요. 구독 URL, 비밀번호, 사용자 ID, 키는 민감한 정보이므로 공개 스크린샷이나 테스트 기록에 포함하지 마세요. 기존 구독의 가져오기 및 관리 방법은 구독 매뉴얼에서 확인할 수 있습니다.
6. 자주 묻는 질문과 주 서버·예비 서버 정하기
지연 시간이 수십 ms인데 동영상은 왜 계속 버퍼링되나요?
먼저 동영상 요청이 실제로 선택한 서버를 통과하는지 확인한 뒤, 같은 콘텐츠와 화질로 지속 전송 상태를 살펴보세요. 지연 시간 테스트는 전송 데이터가 매우 적어 대역폭, 혼잡, 콘텐츠 전달 경로를 반영하지 못합니다. 버퍼링이 발생한 시간대를 기록하고 기존 예비 서버와 같은 조건으로 비교하세요.
목록에는 시간 초과로 표시되지만 실제 웹페이지는 열립니다. 계속 사용해도 되나요?
먼저 Settings에서 테스트 방식과 테스트 주소를 확인한 다음 웹페이지 요청 기록을 살펴보고 실제로 해당 서버를 통과했는지 확인하세요. 실제 요청은 안정적인데 테스트만 실패한다면 테스트 대상이나 방식이 적절한지 점검하세요. 시간 초과 표시만으로 기존 설정을 삭제하지 마세요.
같은 지역에 서버가 여러 개라면 항상 숫자가 가장 낮은 것을 선택해야 하나요?
아닙니다. 같은 조건에서 각각 세 번 테스트한 다음 자주 이용하는 웹페이지와 지속적인 작업 하나를 확인하세요. 반복해서 시간 초과되거나 연결이 끊기는 항목은 따로 표시합니다. 작업을 안정적으로 완료하는 서버 후보 중에서 지연 시간과 지역 조건을 비교해 현재 접속 네트워크의 주 서버를 정하세요.
Wi-Fi를 바꾼 뒤 기존 설정이 작동하지 않으면 구독을 다시 가져와야 하나요?
먼저 새 네트워크에서 로그인 절차를 마쳤는지 확인한 뒤 Settings → On Demand의 자동 연결 조건을 점검하고 기존 설정으로 다시 연결해 테스트하세요. 원래 네트워크로 돌아가면 정상 작동한다면 새 네트워크의 연결 가능 여부부터 확인합니다. 기존 구독의 매개변수가 실제로 변경되었거나 누락된 경우에만 해당 구독을 업데이트하거나 다시 가져오세요.
마지막으로 주 서버, 예비 서버, 적용되는 접속 네트워크, 테스트 방식, 자주 이용하는 대상의 안정적인 접속 여부를 간단히 기록하세요. 예비 서버도 실제로 테스트해야 합니다. 목록에서 지연 시간이 낮아 보이는 항목을 임의로 고르는 것은 적절하지 않습니다. 이후에는 지속적인 연결 실패, 접속 네트워크 변경, 기존 설정 업데이트가 있을 때 다시 테스트하세요. 일시적인 수치 변동만으로 설정을 바꿀 필요는 없습니다.
Shadowrocket은 Apple 플랫폼용 유료 앱이며, 주로 iPhone과 iPad에서 사용합니다. 앱을 받을 수 있는 유일한 경로는 App Store입니다. 앱의 일회성 구매와 회선 요금제는 별개입니다. 이 글에서는 사용자가 이미 보유한 서버를 확인하고 선택하는 방법만 다루며, 서버나 구독 서비스를 제공·판매·추천하지 않습니다. 시스템 요구 사항과 기기 호환성은 App Store 페이지의 안내를 기준으로 확인하세요.