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

이 글의 핵심

이 글은 iPhone 또는 iPad의 Shadowrocket에서 본인의 구독을 가져온 사용자를 위한 안내입니다. 먼저 테스트 조건을 통일하고, 연결 가능한 서버를 추린 다음 지역·프로토콜·실제 접속 결과를 확인합니다. 지연 시간이 짧은 경우, 목적지에 접속할 수 있는 경우, 연결이 지속되는 경우를 구분하고 일정한 순서로 시간 초과 문제를 점검할 수 있습니다.

테스트 대상을 먼저 확인하고 지연 시간만 보지 않기

Home(홈) 목록에 표시되는 서버는 보통 노드라고도 합니다. 목록 옆의 밀리초 값은 특정 조건에서 한 번 테스트한 결과이지, 전체 경로를 종합한 점수가 아닙니다. 값이 작을수록 해당 테스트에서 걸린 시간이 짧았다는 뜻일 뿐입니다. 사용 가능한 대역폭, 장시간 패킷 손실률, 대상 웹사이트의 응답 속도까지 측정한 결과는 아닙니다.

먼저 Connectivity Test(연결 테스트)의 방식을 확인하세요. 서버 포트 연결만 테스트한다면 주로 기기에서 서버 입구까지의 핸드셰이크 시간을 나타냅니다. 프록시를 통해 테스트 주소에 요청하는 방식이라면 프록시 협상, 도메인 이름 확인, 서버 출구 및 대상 서버의 응답 시간도 포함될 수 있습니다. ICMP(인터넷 제어 메시지 프로토콜) 탐지는 프록시 핸드셰이크와 다릅니다. 테스트 방식이 다르면 결과를 한데 모아 직접 순위를 매길 수 없습니다.

밀리초: 지연 시간을 나타내는 단위이며 전송 속도가 아닙니다

443

HTTPS의 기본 포트일 뿐, 서버가 반드시 이 포트를 사용해야 하는 것은 아닙니다

4가지

Global Routing：Proxy / Direct / Config / Scene

예를 들어 HTTPS(하이퍼텍스트 전송 보안 프로토콜) 테스트 주소에 접속할 때 대상은 보통 443 포트를 사용하지만, 프록시 서버는 서비스 제공업체가 설정한 다른 포트를 사용할 수 있습니다. 테스트에 실패하면 대상 주소와 서버 포트를 각각 확인하세요. 둘 다 443으로 바꾸면 안 됩니다. 이 글에서는 실시간 속도 측정 결과를 제시하지 않으며, 특정 밀리초 기준으로 연결 사용 가능 여부를 판단하지 않습니다.

같은 조건으로 테스트한 뒤 기본 서버 선택하기

테스트 전에 대역폭을 많이 사용하는 다른 작업을 중지하세요. 같은 Wi-Fi 또는 셀룰러 네트워크, 같은 테스트 방식, 같은 대상 주소를 유지합니다. 한 번에 한 가지 조건만 바꿔야 차이가 서버 때문인지 로컬 네트워크 때문인지 파악하기 쉽습니다. 기존 구독 내용이 변경됐다면 먼저 업데이트를 마친 뒤 목록의 서버를 비교하세요.

기존 설정 확인

Home(홈)을 열어 본인의 구독 그룹과 서버가 표시되는지 확인하세요. 기존 구독을 다시 추가해야 한다면 오른쪽 위의 “+”를 누르고 Type(유형)에서 Subscribe(구독)를 선택한 다음 본인의 구독 링크를 입력해 저장합니다. 구독 링크를 공개 기록에 올리지 마세요.
테스트 조건 고정

Home(홈)에서 Connectivity Test(연결 테스트)의 테스트 방식 설정으로 이동해 현재 선택된 항목을 기록하세요. 테스트 주소를 설정할 수 있다면 주소도 함께 기록합니다. 전체 비교 과정에서 동일한 설정을 사용하고, 서로 다른 방식의 결과를 합쳐 순위를 매기지 마세요.
테스트 반복

서버 목록의 지연 시간 테스트를 실행하고 후보 서버마다 최소 세 번 반복하세요. 매번 결과가 나오는지, 시간 초과가 반복되는지 기록합니다. 가장 낮은 값만 남기지 마세요. 가끔 매우 낮은 값이 나오더라도 나머지 테스트가 시간 초과라면 안정적인 서버라고 볼 수 없습니다.
기본 서버 선택

Home(홈)으로 돌아가 후보 서버 왼쪽의 선택 원을 누르고 선택 표시가 이동했는지 확인하세요. 연결 스위치를 켭니다. 처음 연결할 때는 시스템 안내에 따라 VPN 구성을 허용하세요. 서버 편집 화면에 들어가는 것만으로는 기본 서버 선택이 완료되지 않습니다.
대상 접속 확인

Home → Global Routing(전역 라우팅)에서 현재 모드를 확인한 뒤 실제로 필요한 웹사이트를 열어 여러 번 새로고침하세요. 이어서 짧은 시간 동안 재생이나 다운로드를 지속해 봅니다. 테스트가 끝나면 진단용 설정을 일상 설정으로 사용하지 않도록 기존 라우팅 모드로 되돌리세요.

이름으로 속도를 추측하지 말고 출구 용도에 맞춰 지역 확인하기

서버 이름에 표시된 지역은 서비스 제공업체가 붙인 설명이며, 실제 입구 위치나 출구 위치, 네트워크 경로를 단독으로 증명하지는 않습니다. 기기가 처음 연결하는 입구와 최종적으로 웹사이트에 접속하는 출구는 서로 다른 지역일 수 있습니다. 지리적으로 가까워도 네트워크 경로가 우회할 수 있으므로 지연 시간이 더 짧다고 단정할 수 없습니다.

대상 웹사이트가 특정 지역을 요구한다면 먼저 서비스 제공업체의 안내에서 출구 지역을 확인한 뒤 웹사이트에 표시되는 실제 이용 가능 상태를 살펴보세요. 계정 지역, 위치 권한, 캐시, 웹사이트 자체 정책도 결과에 영향을 줄 수 있습니다. 서버 이름에 특정 지역이 표시되어도 해당 콘텐츠에 접속할 수 있다는 뜻은 아닙니다.

접속 목적에 따라 나누어 선택하기

일반 웹 페이지 접속

테스트를 반복했을 때 시간 초과가 발생하는 서버부터 제외합니다.
같은 대상을 유지하고 첫 로딩과 다시 로딩할 때를 비교합니다.
연속해서 접속할 수 있는지 확인한 뒤 지연 시간을 참고합니다.

지역 조건이 있는 접속

먼저 기존 서비스의 출구 지역 안내를 확인합니다.
대상 요청이 선택한 서버를 실제로 거치는지 확인합니다.
대상이 표시하는 지역 안내나 오류 메시지를 기록합니다.

지역은 용도별 서버를 추리는 기준이고, 지연 시간은 같은 조건에서 응답을 비교하는 기준입니다. 어느 쪽도 실제 접속 확인을 대신할 수 없습니다.

프로토콜 유형과 설정값, 네트워크 조건 확인하기

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 서로 다른 프로토콜 유형이지 속도순으로 나열한 목록이 아닙니다. 프로토콜이 같아도 서버 부하, 입구 회선, 출구 경로, 전송 설정에 따라 결과가 달라질 수 있습니다. 먼저 서비스 제공업체가 안내한 유형과 관련 필드를 그대로 유지한 다음 현재 네트워크에서 해당 전송 방식을 사용할 수 있는지 테스트하세요.

속도를 높이려고 Type(유형)을 한 프로토콜에서 다른 프로토콜로 바로 바꾸지 마세요. 서버가 해당 프로토콜을 지원해야 하며 인증 정보도 일치해야 합니다. 도메인, 포트, 비밀번호, UUID(범용 고유 식별자), TLS(전송 계층 보안), 전송 경로는 원래 설정을 기준으로 확인하고 서버 이름만 보고 추측하지 마세요.

인증 정보와 전송 설정을 나누어 확인

Shadowsocks: 서버, 포트, 암호화 방식, 비밀번호를 확인하세요. 방식이 일치하지 않으면 연결이 실패할 수 있습니다.
VMess / VLESS: UUID를 확인하고 설정에 지정된 전송 방식, TLS, 호스트 이름 등의 항목도 확인하세요.
Trojan: 비밀번호와 TLS 관련 설정을 확인하고 인증서에 해당하는 서버 이름에 유의하세요.

프로토콜 이름이 같아도 설정 항목을 서로 바꿔 쓸 수 있는 것은 아닙니다. 구독을 업데이트한 뒤에는 서비스 제공업체의 안내를 기준으로 설정을 확인하세요.

UDP 조건은 별도로 확인

Hysteria2: QUIC(빠른 UDP 인터넷 연결) 기반이므로 네트워크 경로에서 해당 UDP 트래픽을 허용해야 합니다.
WireGuard: UDP를 사용하므로 키, 상대 주소 및 관련 네트워크 매개변수가 일치해야 합니다.
TCP 탐지: TCP 포트 탐지 결과만으로 UDP 프로토콜을 실제로 사용할 수 있는지 판단할 수 없습니다.

네트워크 제한이나 서버 설정 모두 시간 초과의 원인일 수 있습니다. 네트워크를 바꿔 다시 테스트할 때는 서버 설정을 동일하게 유지하세요.

UDP(사용자 데이터그램 프로토콜) 기반 연결의 경우, 특정 네트워크에서 일반 웹 페이지를 열 수 있다고 필요한 UDP 트래픽까지 허용된다는 뜻은 아닙니다. 반대로 특정 포트 탐지에 응답이 없더라도 프록시 연결 전체가 실패한다고 단정할 수 없습니다. 실제 프로토콜 연결 상태, 대상 접속 결과, 오류 메시지를 함께 확인하세요.

Global Routing을 확인해 트래픽 경로를 잘못 판단하지 않기

기본 서버를 선택해도 대상 요청이 반드시 해당 서버를 거치는 것은 아닙니다. Home → Global Routing(전역 라우팅)에서 트래픽 라우팅 방식을 정합니다. 특히 Config(구성) 모드에서는 규칙에 따라 특정 웹사이트에 직접 연결하거나 지정된 정책으로 보낼 수 있습니다. 따라서 “서버를 바꿨는데 웹 페이지가 달라지지 않는다”면 먼저 실제로 어떤 경로와 규칙이 적용됐는지 확인하세요.

Proxy(프록시): 프록시 모드로 트래픽을 처리합니다. 문제를 확인할 때는 현재 선택된 서버와 관련 설정도 확인하세요. 연결 스위치만 봐서는 충분하지 않습니다.
Direct(직접 연결): 대상에 직접 연결합니다. 이 경우 일반 웹 페이지가 열린다고 해서 선택한 프록시 서버를 사용할 수 있다는 뜻은 아닙니다.
Config(구성): 현재 활성화된 구성의 규칙에 따라 처리합니다. 규칙은 위에서 아래로 확인하며, 먼저 일치한 규칙이 해당 트래픽에 적용되는 정책을 결정합니다.
Scene(장면): 설정된 장면 조건에 따라 해당 라우팅 설정을 적용합니다. 다시 테스트하기 전에 현재 장면을 확인해 장면 전환으로 인한 변화를 서버의 영향으로 오해하지 않도록 하세요.

아래는 라우팅을 이해하기 위한 예시이며, 현재 사용 중인 전체 구성을 교체할 필요는 없습니다. DOMAIN-SUFFIX(도메인 접미사 일치)는 예시 도메인을 PROXY(프록시 정책)로 보내고, FINAL(최종 규칙)은 다른 규칙과 일치하지 않은 나머지 요청을 DIRECT(직접 연결 정책)로 보냅니다. 예시 도메인은 설명을 위한 텍스트입니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

현재 구성에 GEOIP(IP 지리 정보 일치) 또는 IP-CIDR(IP 대역 일치)도 있다면 규칙의 위치와 정책을 확인하세요. 테스트 대상 웹사이트가 앞선 규칙과 일치하면 뒤에 있는 규칙은 해당 요청의 처리 결과를 바꾸지 않습니다. 문제를 확인할 때는 먼저 모드를 살펴보고, 다음으로 활성화된 Config(구성 파일), 마지막으로 대상에 적용되는 규칙을 확인하세요.

응답 시간, 변동, 지속 전송을 따로 기록하기

웹 페이지가 느리게 열리는 원인이 서버까지의 핸드셰이크 지연이라고 단정할 수 없습니다. 한 번 접속하는 동안 DNS(도메인 이름 시스템) 조회, TLS 핸드셰이크, 리디렉션, 여러 리소스 요청이 이어질 수 있습니다. 동영상 재생은 지속적인 처리량과 버퍼링 상태에 더 크게 좌우됩니다. 소량 데이터 탐지가 성공해도 대용량 전송 중에 혼잡이 발생하지 않는다는 보장은 없습니다.

응답 기록: 테스트 방식을 동일하게 유지하고 후보별 결과를 세 번 기록하세요. 시간 초과가 자주 발생하면 최저 밀리초 값만 비교하지 말고 연결 안정성부터 확인합니다.
대상 기록: 같은 페이지를 열고 첫 로딩과 다시 로딩할 때를 각각 확인하세요. 다시 로딩할 때는 캐시를 사용할 수 있으므로 이를 회선 속도가 빨라졌다는 증거로 볼 수 없습니다.
지속성 기록: 같은 콘텐츠에 짧은 시간 동안 계속 접속해 일시 정지, 재연결, 중단이 반복되는지 기록하세요. 순간적으로 표시되는 속도를 전체 시간의 평균으로 간주하지 마세요.
환경 기록: Wi-Fi 또는 셀룰러 네트워크, 테스트 시간대, 서버 이름, 라우팅 모드를 적어 두세요. 네트워크를 바꿨다면 별도의 결과 묶음으로 기록하고 이전 결과와 바로 섞어 비교하지 마세요.

자주 겪는 문제: 먼저 확인할 항목

지연 시간은 짧은데 웹 페이지가 열리지 않는 이유는 무엇인가요?

먼저 Home → Global Routing(전역 라우팅)에서 모드를 확인하고 웹 페이지 요청이 현재 서버를 거치는지 살펴보세요. 핸드셰이크 테스트는 정상이지만 대상에 접속할 수 없다면 DNS, 대상 웹사이트 응답, 인증 매개변수, 출구 상태를 차례로 확인하세요. 밀리초 값이 낮다는 이유만으로 이 항목들을 문제에서 제외하면 안 됩니다.

모든 서버에서 시간 초과가 발생하면 포트를 하나씩 바꿔야 하나요?

먼저 원래 설정을 유지한 채 기기의 기본 네트워크로 일반 웹 페이지에 접속할 수 있는지 확인한 다음 Connectivity Test(연결 테스트) 방식과 테스트 주소를 점검하세요. 같은 후보 서버를 사용해 Wi-Fi와 셀룰러 네트워크에서 각각 테스트합니다. 한쪽 네트워크에서만 실패한다면 해당 네트워크의 제한부터 확인하고 서비스 제공업체의 포트를 일괄 변경하지 마세요.

구독을 업데이트한 뒤 방금 선택한 서버가 보이지 않나요?

Home(홈)으로 돌아가 구독 그룹을 확인하고 서버 이름이 바뀌거나 서버가 삭제됐는지 살펴보세요. 업데이트 후 왼쪽 선택 원과 실제 연결된 항목을 다시 확인합니다. 업데이트 자체가 실패했다면 구독 링크가 여전히 유효한지 먼저 확인하세요. 오류 정보는 본인의 서비스 제공업체에 문의하고, 기록을 제출할 때는 링크에 포함된 접근 토큰을 가리세요.

연결을 끈 뒤 자동으로 다시 켜집니다. 테스트를 계속하려면 어떻게 해야 하나요?

Settings → On Demand(설정 → 필요 시 연결)를 열어 현재 자동 연결 조건을 확인하세요. 수동으로 비교 테스트하는 동안 해당 조건을 잠시 비활성화한 다음 Home으로 돌아가 연결 스위치를 조작할 수 있습니다. 테스트를 마치면 원래 설정을 복원하세요. 자동 재연결은 연결을 시작하는 동작이므로 서버 전환 실패로 오해하지 마세요.

마지막으로 인증 정보를 제외한 테스트 기록을 남기세요. 현재 네트워크, 선택한 서버 이름, 프로토콜 유형, 테스트 방식, 시간 초과 여부, 대상 접속 여부를 기록하면 됩니다. 서비스 제공업체에 문의할 때는 “지연 시간이 높다”는 설명만 하는 것보다 이런 조건을 알려 주는 편이 문제를 파악하는 데 도움이 됩니다. 구독 링크, 비밀번호, UUID, 키를 공개하지 마세요.