Shadowrocket 노드 선택 방법: 지연 시간·지역·프로토콜 확인하기

이 글의 핵심 내용

Shadowrocket에서 노드를 선택할 때는 먼저 연결 가능 여부를 확인하고, 같은 네트워크와 테스트 방법으로 결과를 비교한 다음 실제 이용할 페이지에서 검증하세요. 이미 서비스 제공업체와 구독을 이용 중인 경우를 전제로, 지연 시간·지역·프로토콜·규칙이 각각 어떤 영향을 주는지 설명하고 테스트 수치가 낮은 것과 현재 작업을 문제없이 완료하는 것을 구분하는 방법을 안내합니다.

테스트 조건을 통일한 뒤 노드 선택하기

목록에서 가장 낮은 밀리초 수치만 보고 결론 내리지 마세요. 한 번의 테스트는 그때의 연결 과정만 보여 줄 뿐, 웹페이지 접속이나 장시간 다운로드, 앱 로그인을 대신할 수 없습니다. 먼저 연결 네트워크와 테스트 방법을 고정한 뒤 기존 구독에서 후보 2~3개를 골라 비교하세요. 모든 항목을 자주 바꾸는 것보다 원인을 파악하기 쉽습니다.

구독 확인

Home에서 구독과 노드가 불러와졌는지 확인하세요. 다시 추가해야 한다면 Home → + → Type → Subscribe로 이동해 서비스 제공업체에서 받은 구독 링크를 입력하고 저장한 다음 구독을 업데이트하세요. 구독 URL을 서버 주소로 입력하지 마세요.
네트워크 고정

현재 사용하는 Wi-Fi 또는 셀룰러 네트워크를 선택하고 다른 기기에서 대용량 작업을 일시 중지하세요. 비교하는 동안 연결 네트워크, 테스트 대상, 노드를 동시에 바꾸지 마세요. 어떤 변경이 차이를 만들었는지 알기 어렵습니다.
라우팅 확인

Home → Global Routing을 열어 현재 설정을 기록하세요. 선택한 프록시 연결을 임시로 확인하려면 Proxy를 사용할 수 있고, 평소 규칙이 어떻게 작동하는지는 Config에서 다시 확인하세요. 문제를 점검하는 동안에는 Settings → On Demand를 먼저 살펴 자동 연결 조건이 수동 조작에 영향을 주지 않도록 하세요.
반복 테스트

Home에서 Connectivity Test를 사용하고 동일한 테스트 방법으로 같은 후보를 세 번 연속 측정해 기록하세요. 후보를 선택하고 연결을 활성화한 다음 같은 대상 페이지를 열어 실제 요청이 완료되는지 확인하세요.
설정 복원

비교가 끝나면 원래 사용하던 Global Routing 및 On Demand 설정으로 되돌리세요. 평소 Config를 사용한다면 Config로 돌아가 선택한 구성 파일의 규칙을 확인하고, 임시 점검용 설정을 계속 사용하지 마세요.

지연 시간 테스트가 측정하는 연결 구간

지연 시간은 보통 ms 단위로 표시되며, 그 의미는 테스트 방법에 따라 달라집니다. TCP 연결 테스트는 서버 주소와 포트에 연결할 수 있는지 확인합니다. 프록시를 거쳐 테스트 URL에 접속하는 방식은 프록시 핸드셰이크, DNS, TLS, 대상 서버의 응답까지 측정할 수 있습니다. 두 방법은 측정 범위가 다르므로 수치를 그대로 늘어놓고 비교할 수 없습니다. 먼저 현재 Connectivity Test가 어떤 방법을 사용하는지 확인한 뒤 결과를 해석하세요.

연결 계층 테스트

측정 대상: 서버 주소와 구성에 지정된 포트
주요 측정 항목: 연결 가능 여부와 이번 연결에 걸린 시간
확인할 수 없는 항목: 프록시 인증 성공 여부, 대상 웹페이지 접속 가능 여부
포트 예시: 443은 구성에 사용할 수 있는 값일 뿐, 특정 프로토콜을 뜻하지 않습니다.

포트는 구독 설정을 따르세요. 테스트를 위해 임의로 443으로 변경하지 마세요.

요청 계층 테스트

측정 대상: 프록시를 거쳐 테스트 대상에 보내는 요청
주요 측정 항목: 관련 핸드셰이크와 대상 서버의 응답 완료 여부
확인할 수 없는 항목: 지속적인 다운로드 속도나 다른 웹사이트의 접속 결과
비교 조건: 동일한 대상, 동일한 방법, 동일한 연결 네트워크

테스트 대상 자체에 문제가 있으면 여러 노드가 동시에 시간 초과로 표시될 수도 있습니다.

예를 들어 세 번 측정한 결과가 68, 72, 70 ms이고 다른 후보의 결과가 45, 310, 시간 초과라고 가정해 보겠습니다. 첫 번째 후보는 이 기록에서 변동 폭이 더 작고, 두 번째 후보는 한 번만 더 낮은 수치를 보였습니다. 이는 측정값을 해석하는 예시일 뿐, 실제 회선 측정이나 추천이 아닙니다. 세 번의 결과도 짧은 시간 동안 얻은 표본입니다. 평소 문제가 저녁에 발생한다면 같은 시간대에 다시 확인하세요.

낮은 지연 시간: 일반적으로 짧은 요청의 응답에 유리하지만 MB/s로 환산할 수는 없습니다.
시간 초과: 제한 시간 내에 이번 테스트가 완료되지 않았다는 뜻이며, 서버를 영구적으로 사용할 수 없다고 입증하는 것은 아닙니다.
변동: 무선 신호, 연결 네트워크의 혼잡, 서버 부하 또는 대상 서비스 상태 등이 원인일 수 있습니다. 항목별로 확인하세요.

지역 이름과 실제 출구를 구분해 판단하기

노드 이름에 표시된 지역은 서비스 제공업체가 붙인 라벨이지, 클라이언트가 독립적으로 확인한 지리 정보가 아닙니다. 라벨은 진입 지점, 출구 또는 상품 그룹을 나타낼 수 있습니다. 실제 출구는 연결 후 대상 서비스가 확인하는 IP 주소를 기준으로 판단하세요. IP 지리 정보 데이터베이스가 최신이 아닐 수도 있으므로, 지역 라벨 하나만으로 모든 웹사이트가 같은 지역으로 판단한다고 볼 수 없습니다.

대상 작업에 맞는 지역 판단 기준

일반적인 웹 탐색과 요청 응답

같은 대상 페이지를 사용해 열기와 새로고침 결과를 기록하세요.
지역이 가까운지만 보지 말고 요청을 반복해도 성공하는지 비교하세요.
다운로드는 지속적인 전송 속도를 따로 확인하세요. 첫 응답 시간으로 처리량을 판단하지 마세요.

대상 서비스에 지역 제한이 있는 경우

먼저 대상 서비스 자체의 이용 조건과 지역 요구 사항을 확인하세요.
대상 트래픽이 선택한 프록시 출구를 실제로 통과하는지 확인하세요.
IP 라벨만 보지 말고 계정 지역, 위치 권한, 캐시도 함께 확인하세요.

지역은 후보를 추리는 기준으로 활용하고, 목표 작업의 성공 여부는 동일한 설정에서 확인해야 합니다.

지리적으로 가깝다고 실제 네트워크 경로가 짧은 것은 아닙니다. 트래픽은 통신사 간 연결, 진입 지점의 중계, 출구 경로를 거칠 수 있으며 DNS가 반환하는 대상 주소도 최종 경로에 영향을 줍니다. 두 노드의 지역 이름이 같아도 같은 페이지를 여는 결과에 큰 차이가 있다면, 이름만으로 원인을 단정하지 말고 테스트 조건과 오류 현상을 기록하세요.

프로토콜은 이름으로 순위를 매기지 말고 호환 설정부터 확인하기

프로토콜은 클라이언트와 서버가 연결을 설정하고 데이터를 전달하는 방식을 정하며, 속도를 직접 결정하지는 않습니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 필요한 설정이 서로 다르므로 Type만 바꿔 서로 변환할 수 없습니다. 구독에 필요한 설정이 모두 포함되어 있다면 우선 원래 설정 그대로 사용하세요. 설정이 빠져 있다면 서비스 제공업체에 정확한 값을 확인하세요.

프로토콜	확인할 구성 항목	점검할 사항
Shadowsocks	서버, 포트, 암호화 방식, 비밀번호	암호화 방식과 비밀번호가 서버 설정과 일치해야 합니다.
VMess / VLESS	사용자 식별자, 전송 방식 및 관련 보안 매개변수	실제 설정에 따라 TLS, Server Name, 경로 등의 항목을 확인하세요. 서로 다른 두 프로토콜의 인증 설정을 혼용하면 안 됩니다.
Trojan	비밀번호, 포트 및 TLS 관련 설정	Server Name과 인증서 검증 조건을 확인하세요. 검증을 끄는 것으로 문제를 해결하려 하지 마세요.
Hysteria2	인증 정보, TLS 및 서비스 제공업체가 안내한 기타 설정	QUIC 기반이므로 현재 네트워크에서 UDP에 연결할 수 있는지 확인해야 합니다.
WireGuard	키, 상대 주소, 포트 및 터널 관련 설정	UDP를 사용하므로 핸드셰이크와 라우팅 설정이 모두 접속 결과에 영향을 줄 수 있습니다.

TCP 포트에 연결할 수 있다고 해서 UDP 기반 프로토콜이 정상 작동한다고 볼 수는 없습니다. 마찬가지로 특정 Wi-Fi에서 한 프로토콜이 실패하더라도 셀룰러 네트워크에서 같은 결과가 나온다고 단정할 수 없습니다. 비교할 때는 구독에 올바르게 설정된 항목을 사용하고 연결 네트워크와 후보 중 한 번에 하나만 바꾸세요. 프로토콜 이름이 같은 두 노드라도 출구, 서버 부하, 전송 설정에 따라 결과가 다를 수 있습니다.

수치가 정상인데 웹페이지가 열리지 않는다면 규칙과 연결 경로부터 확인하기

선택한 노드가 대상 페이지의 트래픽을 반드시 처리하는 것은 아닙니다. Global Routing에서 Proxy는 프록시 경로를 임시로 비교할 때, Direct는 직접 연결을 비교할 때 사용할 수 있으며 Config는 선택한 구성에 따라 처리합니다. Scene은 구성된 시나리오 조건에 따라 동작을 선택하므로 다른 고정 프록시 스위치처럼 단순하게 볼 수 없습니다. 정책 그룹을 사용한다면 대상 규칙이 그룹 안의 다른 노드를 가리킬 수도 있으므로 실제 매칭 결과를 확인하세요.

Config의 규칙은 위에서 아래 순서로 매칭됩니다. 다음은 구문 설명을 위한 예시일 뿐, 모든 네트워크에 적용할 수 있는 완성된 구성은 아닙니다. example.com은 예시 도메인이며 구독이나 테스트 서비스가 아닙니다. 문서용 예약 주소 192.0.2.0/24도 실제 서비스 접속 주소가 아닙니다.

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX는 지정한 도메인 접미사를 매칭합니다. 이 예시에서는 해당 도메인과 하위 도메인에 PROXY를 적용합니다.
IP-CIDR는 대상 IP 대역을 매칭합니다. no-resolve는 이 규칙의 매칭을 위해 별도로 도메인 조회를 실행하지 않는다는 뜻입니다.
GEOIP는 노드 이름이 아니라 대상 IP의 지역 데이터베이스를 기준으로 매칭합니다.
FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리하므로 마지막 대체 규칙 위치에 두어야 합니다.

Proxy에서는 페이지가 정상적으로 열리고 Config에서는 실패한다면, 지연 시간에 따라 노드를 계속 바꾸기보다 Config에서 선택한 파일, 규칙 순서, 정책 지정부터 확인하세요. 반대로 여러 후보가 같은 도메인에서만 실패한다면 해당 대상의 DNS, TLS, 서비스 상태를 확인하세요. 요청 기록에서 대상 도메인, 매칭된 규칙, 오류 정보를 확인한 다음 문제 해결에서 증상에 맞는 점검 방법을 살펴보세요.

노드 선택에 관한 자주 묻는 질문 4가지

지연 시간이 30 ms인데 다운로드는 왜 느린가요?

30 ms는 선택한 테스트에서 한 번 응답하는 데 걸린 시간이지 대역폭이 아닙니다. 같은 파일, 같은 노드, 같은 네트워크 조건을 유지하고 지속적인 전송이 안정적인지 확인한 다음 기기 자체나 다른 기기가 대역폭을 사용 중인지 살펴보세요. 서로 다른 다운로드 사이트의 속도를 바로 비교하지 마세요.

모든 항목이 시간 초과로 표시되면 구독을 다시 추가해야 하나요?

먼저 기기 자체가 인터넷에 연결되는지 확인한 뒤 Home → Connectivity Test에서 테스트 방법과 대상을 살펴보세요. 프록시 요청 테스트라면 대상이 작동하지 않아 모든 항목이 시간 초과로 표시될 수도 있습니다. 구독 내용이 만료되었거나 설정값이 변경된 것을 확인한 뒤 구독을 업데이트하세요. 근거 없이 기존 구성을 삭제하지 마세요.

같은 노드가 Wi-Fi에서는 되는데 셀룰러에서는 안 되나요?

노드는 그대로 두고 연결 네트워크만 바꿔 비교한 뒤 프로토콜, 오류, 발생 시간을 기록하세요. Settings → On Demand가 네트워크 조건에 따라 연결 동작을 바꾸는지 확인하세요. Hysteria2나 WireGuard를 사용한다면 UDP 연결 가능 여부와 일반 TCP 연결 결과를 구분해 살펴보세요.

구독을 업데이트한 뒤 이전에 선택한 항목이 사라졌나요?

Home으로 돌아가 업데이트된 목록을 확인하고 서비스 제공업체가 이름이나 서버 설정을 변경했는지 살펴보세요. 남아 있는 항목을 다시 선택한 뒤 Config에서 참조하는 정책 그룹도 확인하세요. 이전 주소나 비밀번호를 새 항목에 복사해 문제를 해결하려 하지 마세요. 정확한 설정값은 서비스 제공업체에서 확인해야 합니다.

최소한의 기록을 남겨 기억에 의존한 반복 전환을 피하기

한 번 비교한 뒤에는 연결 네트워크, 시간, 프로토콜, 테스트 방법, 세 번의 지연 시간, 대상 요청 결과를 기록하면 충분합니다. 기록이나 문의용 스크린샷에 전체 구독 링크, 비밀번호, 사용자 식별자, 개인 키를 공개하지 마세요. 구독 URL의 token은 보통 접근 권한을 포함하므로 공유 전에 전체를 가리세요.

기록 예시: 가정용 Wi-Fi, 후보 A, Trojan, 동일한 요청 계층 테스트, 68 / 72 / 70 ms, 대상 페이지를 세 번 연속으로 여는 데 성공. 기록 형식을 보여 주기 위한 예시입니다.
조건을 유지해 비교: 문제가 생기면 같은 조건으로 다시 테스트한 다음 네트워크 또는 후보를 한 번에 하나씩 바꾸세요. 프로토콜 설정과 규칙을 동시에 변경하지 마세요.
전환 중단: 기존 항목으로 목표 작업을 안정적으로 완료할 수 있다면 한 번 측정한 지연 시간이 더 낮아지도록 반복해서 설정을 바꿀 필요는 없습니다.