Shadowrocket 지연 시간 테스트와 서버 선택 방법

이 글 한눈에 보기

Shadowrocket의 지연 시간 수치는 기존 서버를 미리 비교하는 데 유용하지만, 대역폭이나 전체적인 접속 품질을 단독으로 보여주지는 않습니다. 이미 이용 중인 서비스와 구독이 있다는 전제하에, 테스트 조건을 통일하고 지역과 프로토콜을 확인한 뒤 여러 차례 측정하고 실제 접속까지 확인하는 순서로 살펴봅니다. 응답 속도, 연결 안정성, 다운로드 속도를 구분하는 데 도움이 됩니다.

지연 시간 수치의 의미: 먼저 측정 대상을 확인하세요

지연 시간은 보통 밀리초(ms)로 표시합니다. 수치가 낮을수록 해당 테스트에서 상호작용에 걸린 시간이 짧다는 뜻입니다. 다만 먼저 테스트 방식을 확인해야 합니다. TCP 연결 설정 시간과 프록시를 통해 보낸 HTTP 요청의 응답 시간은 측정 범위가 다릅니다. ICMP 왕복 시간도 프록시 요청에 걸리는 시간과 동일하게 볼 수 없습니다. 테스트 방식을 확인하지 않았다면 목록의 모든 수치를 Ping이라고 부르지 마세요.

TCP 연결에 성공했다는 것은 해당 시점에 지정된 주소와 포트로 연결을 설정할 수 있었다는 뜻일 뿐, 프로토콜 인증과 TLS 핸드셰이크, 대상 웹 페이지 요청까지 모두 성공한다는 의미는 아닙니다. HTTP 테스트 결과에도 테스트 주소, DNS, TLS, 서버 응답이 영향을 줍니다. 테스트가 실제 요청에 가까울수록 참고할 만하지만, 여전히 해당 시점의 요청 결과만 보여줍니다.

지연 시간: 한 번의 상호작용에 걸리는 시간을 나타내며, 초기 응답을 확인할 때 유용합니다.
처리량: 일정 시간 동안 전송되는 데이터 양을 나타냅니다. 보통 Mbps 또는 MB/s로 표시하며, ms에서 환산할 수 없습니다.
변동 폭: 같은 조건에서 결과가 얼마나 일정한지 나타냅니다. 한 번 측정한 최저값보다 여러 차례 측정한 결과가 더 유용합니다.
시간 초과: 제한 시간 안에 테스트가 완료되지 않았다는 뜻입니다. 네트워크, 포트, 프로토콜 매개변수 또는 테스트 대상이 원인일 수 있으며, 서버 장애만을 의미하지는 않습니다.

조건을 먼저 맞춘 뒤 Home에서 기존 서버 테스트하기

유효하게 비교하려면 서버만 바꾸고 나머지 조건은 최대한 동일하게 유지해야 합니다. 같은 iPhone 또는 iPad, 같은 네트워크 접속 방식, 같은 테스트 대상과 방법을 정한 다음 측정하세요. Wi-Fi와 셀룰러 네트워크는 외부로 나가는 경로가 완전히 다를 수 있습니다. 네트워크를 바꿨다면 다시 테스트해야 하며, 이전 순위를 그대로 적용하면 안 됩니다.

기존 설정 확인하기

Home에서 기존 서버를 확인하세요. 직접 추가해야 한다면 Home 오른쪽 위의 “+”를 눌러 Add Server로 이동한 뒤, 보유한 정보를 바탕으로 Type, 주소, 포트를 입력합니다. 기존 구독은 먼저 업데이트한 다음 비교를 시작해야 변경된 주소를 테스트하는 일을 피할 수 있습니다.
연결 환경 고정하기

Wi-Fi 또는 셀룰러 네트워크 중 하나를 선택하고 대용량 네트워크 작업은 잠시 중단하세요. Settings → On Demand에서 현재 설정을 확인해 기록합니다. 자동 재연결로 테스트 조건이 달라지지 않도록 잠시 꺼야 한다면, 원래 설정을 먼저 기록하고 테스트가 끝난 뒤 복원하세요.
서버를 하나씩 선택해 테스트하기

Home으로 돌아가 후보 서버를 하나씩 선택한 다음 Connectivity Test로 연결을 확인하세요. 화면에 표시된 결과와 테스트 방법, 시간을 기록합니다. 연결 테스트에 한 번 성공했다고 해서 모든 웹사이트에 접속할 수 있다는 뜻은 아닙니다.
세 차례 반복 측정하기

각 후보를 같은 방법으로 세 번 테스트하세요. 예를 들어 측정 사이에 약 10초 간격을 둘 수 있습니다. 최저값만 기록하지 말고 모든 결과를 남기세요. 시간 초과가 발생했다면 평균값에서 임의로 제외하지 말고 함께 기록해야 합니다.
실제 요청으로 확인하기

Home → Global Routing에서 현재 라우팅 모드를 확인하세요. 규칙의 영향을 잠시 분리하려면 Proxy로 선택한 서버를 테스트한 뒤 같은 대상 페이지에 접속합니다. 테스트가 끝나면 기존 Config나 다른 설정을 복원하고, 실제 요청이 해당 서버를 거쳤는지도 확인하세요.

Global Routing의 Direct는 요청이 직접 연결되므로 프록시 서버의 실제 접속 성능을 확인하는 데 적합하지 않습니다. Config는 현재 설정에 따라 요청을 처리하므로 DIRECT 규칙이 적용될 수 있습니다. Scene도 설정된 시나리오에 따라 처리되므로 현재 적용 조건을 먼저 확인해야 합니다. 따라서 “웹 페이지가 빠르다”는 사실이 “선택한 서버가 빠르다”는 뜻은 아닙니다.

지역과 프로토콜 선택하기: 경로를 확인한 뒤 결과 비교

지역 이름은 후보를 분류할 때 참고할 수 있지만, 대개 서비스 정보에 표시된 이름일 뿐 실제 서버가 있는 물리적 위치가 확인됐다는 뜻은 아닙니다. 입구에서 출구까지의 경로를 직접 보여주지도 않습니다. 지리적으로 가까우면 전송 시간이 줄어들 가능성이 있지만, 통신사 간 연결과 우회 경로, 혼잡이 그 이점을 상쇄할 수 있습니다. 지역 이름만으로 순위를 정하지 말고 현재 이용 중인 네트워크에서 직접 비교하세요.

두 가지 접속 환경의 테스트 결과를 따로 기록하기

Wi-Fi에서 테스트

같은 장소와 Wi-Fi를 유지해 무선 신호 변화의 영향을 줄입니다.
기존 목록에서 지역이 다른 후보 두세 개를 골라 동일한 테스트 대상을 사용합니다.
저녁과 낮에 각각 한 번씩 측정해 혼잡 시간대에 변동이 있는지 확인합니다.

셀룰러 네트워크에서 테스트

먼저 움직이지 않고 신호가 안정적인 곳에서 비교해 이동 중 기지국이 바뀌는 상황을 피합니다.
기존 후보를 다시 테스트하고, Wi-Fi에서 1위였던 서버를 그대로 선택하지 마세요.
테스트 당시의 네트워크 환경을 기록하고, 신호나 위치가 바뀌면 다시 확인합니다.

두 환경의 후보 순서를 각각 기록하면 하나의 서버로 모든 네트워크를 해결하려는 것보다 문제를 파악하기 쉽습니다.

프로토콜 이름은 연결 방식을 나타내며, 정해진 속도 등급을 뜻하지 않습니다. Shadowsocks, VMess, VLESS, Trojan의 실제 성능은 전송 방식, 암호화, TLS, 서버 설정에 따라 달라집니다. 이름만 보고 어느 쪽이 더 빠른지 판단할 수 없습니다. Hysteria2는 QUIC 기반이므로 UDP 연결 가능 여부가 중요합니다. WireGuard도 UDP를 사용하지만 터널 작동 방식은 다르므로 두 프로토콜을 동일한 테스트 대상으로 보면 안 됩니다.

먼저 유형 확인:Add Server의 Type은 기존 서비스 정보와 일치해야 합니다. 수치를 낮추려고 프로토콜을 임의로 바꾸지 마세요.
다음은 매개변수 확인:포트, 인증 정보, TLS 매개변수가 서로 맞아야 합니다. 443은 포트 번호일 뿐, 이를 근거로 프로토콜이 반드시 Trojan이라고 판단하거나 연결 성공을 보장할 수는 없습니다.
전송 방식 구분:UDP를 사용하는 설정은 같은 주소의 TCP 포트만 따로 확인해도 실제 프로토콜의 사용 가능 여부를 알 수 없습니다. 프로토콜 연결과 실제 요청을 함께 확인해야 합니다.
변수 유지:지역과 프로토콜이 모두 다른 두 후보의 결과를 선택에 참고할 수는 있지만, 이 결과만으로 “프로토콜 자체가 더 빠르다”고 결론 내릴 수는 없습니다.

세 차례 측정 결과 읽기: 최저값보다 안정성이 중요합니다

다음 수치는 기록 방법을 보여주기 위한 가상 예시입니다. 이 사이트에서 직접 측정한 결과가 아니며 특정 지역이나 프로토콜의 성능을 나타내지도 않습니다. 먼저 테스트 성공 여부를 확인하고 중앙값과 변동 폭을 살펴보세요. 마지막으로 실제 페이지 접속과 지속적인 데이터 전송도 확인해야 합니다.

기존 후보	세 차례 측정 결과	판단 기준
A, 같은 테스트 방식	72 / 180 / 95 ms	중앙값 95 ms, 변동 폭이 큽니다. 혼잡 시간대 결과를 확인하세요.
B, 같은 테스트 방식	104 / 108 / 106 ms	중앙값 106 ms, 세 번의 결과가 비슷합니다. 실제 접속을 추가로 확인할 수 있습니다.
C, 같은 테스트 방식	60 ms / 시간 초과 / 65 ms	최저값은 낮지만 한 번 실패했으므로, 60 ms만 보고 1위로 판단할 수 없습니다.

세 번의 측정은 후보를 추리는 데는 유용하지만 장기간의 패킷 손실률을 신뢰성 있게 계산하기에는 부족합니다. A가 가끔 빠르고 B가 꾸준히 안정적이라면, 상호작용이 많은 웹 페이지는 B에서 더 원활할 수 있습니다. 실제 접속 결과가 다르다면 반복해서 확인할 수 있는 실제 작업 결과를 우선하세요. 모든 네트워크에 적용되는 고정 지연 시간 기준을 합격선으로 삼지 마세요.

지연 시간 기록표

접속 네트워크: 같은 Wi-Fi를 유지하고 테스트 중에는 전환하지 않음
측정 조건: 같은 테스트 방식과 같은 테스트 대상
반복 횟수: 후보마다 3회, 약 10초 간격
기록할 결과: 모든 ms 수치, 시간 초과 여부, 테스트 시간

먼저 조건을 동일하게 맞춘 뒤 순위를 비교하세요. 테스트 방식이 다른 수치는 따로 기록해야 합니다.

실제 접속 확인표

연결 모드: Home → Global Routing → Proxy에서 임시 확인한 뒤 원래 설정으로 복원
페이지 테스트: 같은 페이지를 3회 다시 열어 첫 로딩과 캐시 로딩을 구분
지속 전송: 접근 권한이 있는 같은 파일을 사용해 안정적인 전송 속도를 확인
최종 판단 기준: 성공률, 대기 시간, 지속 전송 성능을 함께 고려

실제 요청이 테스트 대상 서버를 거쳐야 해당 연결의 성능을 평가할 수 있습니다.

지연 시간은 낮은데 웹 페이지가 느릴 때: 요청 경로별 점검

웹 페이지를 열 때는 왕복 통신이 한 번만 발생하지 않습니다. DNS 조회, 연결 설정, TLS 핸드셰이크, 기본 문서와 여러 하위 리소스 요청이 모두 대기 시간을 늘립니다. 일부 리소스는 다른 도메인에서 제공되기도 합니다. 지연 시간 테스트 대상의 응답이 빠르더라도 실제 웹사이트의 DNS 조회, 외부로 나가는 경로, 서버 응답까지 빠르다는 뜻은 아닙니다. 대용량 파일 다운로드는 지속 대역폭, 혼잡, 패킷 손실의 영향을 더 크게 받습니다.

요청 경로 확인.Home → Global Routing에서 현재 연결 모드를 확인하세요. Config를 사용 중이라면 Home에서 선택한 서버만 보지 말고 Config에서 현재 활성화된 파일을 확인해야 합니다.
규칙 적용 여부 확인.예를 들어 DOMAIN-SUFFIX,example.com,DIRECT 규칙은 해당 도메인의 요청을 DIRECT로 보냅니다. FINAL,PROXY는 앞선 규칙에 일치하지 않은 요청에만 적용됩니다. 규칙은 위에서 아래 순서로 일치 여부를 확인하므로, 선택한 서버를 바꿔도 이미 적용된 DIRECT 정책은 바뀌지 않습니다.
최초 접속과 캐시 접속 구분.첫 로딩에는 DNS와 TLS 처리 시간이 포함될 수 있지만, 다시 열 때는 캐시를 사용하거나 연결을 재사용할 수 있습니다. 한 연결의 첫 로딩 결과를 다른 연결의 캐시 접속 결과와 비교하지 말고 각각 기록하세요.
설정을 마구 바꾸지 말고 테스트 대상을 변경.먼저 같은 페이지를 확인한 다음, 접근 권한이 있는 다른 대상을 테스트하세요. 특정 사이트 하나에서만 문제가 생긴다면 대상까지의 경로와 사이트 응답을 우선 살펴보세요. 포트, DNS, 프로토콜을 한꺼번에 바꾸지 마세요.
네트워크 혼잡 시간대 재확인.짧은 테스트는 정상이지만 지속 전송 속도가 점차 떨어진다면 같은 환경에서 시간을 두고 다시 측정하세요. 혼잡한 시간대에만 문제가 발생하는지도 기록합니다.

규칙의 GEOIP와 IP-CIDR은 IP 조건에 따라 트래픽 경로를 나누는 데 사용하며, 서버까지의 거리나 속도를 측정하지 않습니다. 설정에 특정 지역 조건이 있다고 해서 선택한 서버의 출구 위치가 확인되는 것도 아닙니다. 문제를 진단할 때는 “규칙이 요청 경로를 어떻게 정하는지”와 “실제 연결 품질이 어떤지”를 따로 살펴보세요.

자주 묻는 질문: 시간 초과, 업데이트, 자동 전환

시간 초과가 표시되면 서버를 사용할 수 없는 건가요?

먼저 현재 Wi-Fi나 셀룰러 네트워크 자체가 정상적으로 연결되는지 확인한 뒤 Home에서 다시 테스트하세요. Add Server의 기존 설정에서 유형, 주소, 포트를 확인하고 실제 연결도 점검합니다. 테스트 대상 하나에서만 실패하고 실제 웹 페이지는 정상이라면 테스트 방식과 대상을 더 살펴봐야 합니다. 시간 초과만으로 결론 내리지 마세요.

구독을 업데이트한 뒤 기존의 낮은 지연 시간 기록이 맞지 않는 이유는 무엇인가요?

업데이트 과정에서 주소, 포트, 서버 항목이 바뀔 수 있습니다. 이름이 같더라도 같은 연결 경로라는 보장은 없습니다. Home으로 돌아가 업데이트된 후보를 확인하고, 같은 네트워크와 테스트 대상에서 세 차례 다시 측정하세요. 업데이트 전 순위를 새 항목에 그대로 적용하거나, 낮은 수치를 유지하려고 만료된 매개변수로 되돌리지 마세요.

테스트 중 연결이 저절로 다시 켜집니다. 조건을 고정하려면 어떻게 해야 하나요?

Settings → On Demand에서 기존 온디맨드 연결 설정을 확인하고 현재 상태를 먼저 기록하세요. 필요하다면 설정을 잠시 끈 뒤 Home으로 돌아가 연결 상태를 확인합니다. 테스트가 끝나면 원래 설정을 복원하세요. On Demand는 조건에 따라 연결을 처리하는 기능이지, 지연 시간이 가장 낮은 서버를 자동으로 선택하는 기능은 아닙니다.

수치가 가장 낮은 서버를 계속 기본으로 사용해야 하나요?

실제 페이지 접속과 지속 전송을 먼저 확인한 뒤 기본 서버를 정하고, 검증을 마친 다른 후보도 하나 남겨 두세요. Wi-Fi에서 셀룰러로 전환하거나 구독을 업데이트했거나 이용 경험이 크게 달라졌다면 다시 테스트해야 합니다. 자동 정책 그룹을 사용한다면 그룹의 선택 조건도 확인하세요. 직접 선택한 항목과 그룹이 최종적으로 선택하는 서버가 다를 수 있습니다.

최종 선택 순서는 매개변수가 올바른지, 실제로 사용할 수 있는지, 반복 테스트에서 안정적인지, 필요한 작업에 적합한지 확인한 뒤 몇 ms 차이를 비교하는 것입니다. 이 글에서는 사용자가 이미 보유한 설정의 테스트와 사용 방법을 설명합니다. 클라이언트 구매 조건과 기존 서비스 이용 조건은 각각 별도로 확인해야 합니다.