Shadowrocket 노드 선택 방법: 지연 시간 테스트·지역·프로토콜 유형과 수치의 한계

1. 지연 시간·전송량·사용 가능 여부 구분하기

지연 시간은 보통 ms 단위로 표시되며, 지정된 경로에서 테스트 요청을 처리하는 데 걸린 시간을 나타냅니다. 전송량은 단위 시간 동안 실제로 전달된 데이터의 양입니다. 작은 요청이 빠르게 응답했다고 해서 연속 다운로드에도 충분한 대역폭이 유지된다는 뜻은 아닙니다. 동영상 재생은 대상 사이트, 캐시 위치, 출구 혼잡도, 일정 시간 동안의 연결 안정성에도 영향을 받습니다.

테스트 방식마다 확인하는 연결 구간이 다릅니다. TCP 연결 테스트는 주로 대상 포트에 연결을 설정하는 시간을 측정하며, 프록시 인증이나 대상 웹사이트 접속까지 완료하지 않을 수 있습니다. 프록시를 통해 HTTP 요청을 보내는 테스트는 더 많은 구간을 확인하지만, 그 결과도 해당 테스트 주소에만 적용됩니다. 결과를 비교하기 전에 테스트 방식과 대상을 확인하고, 서로 다른 방식으로 얻은 수치를 한 순위에 놓지 마세요.

2. Home에서 반복 가능한 방식으로 후보 추리기

먼저 구독이 정상적으로 가져와져 Home에 기존 노드 목록이 표시되는지 확인하세요. 서비스 제공자가 설정 변경을 안내했다면 비교를 시작하기 전에 해당 구독을 업데이트하세요. 이전 설정을 사용하면서 프로토콜 성능을 판단하지 마세요. 구독 주소에는 접속 정보가 포함되어 있으므로 스크린샷을 찍거나 결과를 기록할 때 전체 링크, 비밀번호, token을 가리세요.

1. 네트워크 고정하기

   같은 Wi-Fi 또는 셀룰러 네트워크를 유지하고 대용량 다운로드와 시스템 업데이트를 일시 중지하세요. Settings → On Demand를 열어 현재 상태를 기록하세요. 테스트 중 연결이 자동으로 전환될 수 있다면 잠시 끄고, 테스트가 끝난 뒤 원래대로 복구하세요.

2. 설정값 확인하기

   Home에서 후보 노드의 편집 화면을 열고 Type, 서버 주소, 포트가 기존 서비스 제공자가 안내한 정보와 일치하는지 확인하세요. 더 낮은 수치를 얻으려고 포트, TLS 또는 인증 항목을 임의로 바꾸지 마세요.

3. 테스트 반복하기

   Home에서 Connectivity Test를 사용해 후보 노드를 같은 방식으로 연속 세 차례 테스트하고, 각 회차 사이에 잠시 간격을 두세요. 최소값만 적지 말고 성공 횟수, 일반적인 소요 시간, 눈에 띄는 시간 초과도 기록하세요.

4. 실제 사용 확인하기

   Home → Global Routing에서 잠시 Proxy를 선택하고 후보 노드 하나를 선택해 연결을 활성화하세요. 같은 브라우저에서 같은 대상 페이지를 여세요. 노드를 바꾼 뒤에는 기존 세션을 재사용하지 않도록 새 연결을 만든 다음 테스트하세요.

5. 설정 복구하기

   비교가 끝나면 Home → Global Routing을 기존 Config 또는 다른 원래 설정으로 되돌리고 On Demand도 복구하세요. 대상 페이지에 다시 접속해 평소 규칙에서 예상한 정책이 적용되는지 확인하세요.

Proxy는 분기 규칙의 차이를 잠시 배제해 확인하는 데 적합하지만, 모든 시스템 트래픽이 반드시 같은 경로를 따른다는 뜻은 아닙니다. 브라우저 캐시, 기존 장기 연결, 설정의 제외 항목도 결과에 영향을 줄 수 있습니다. 한 번에 조건 하나만 바꿔야 노드 변경의 효과와 단순 새로고침 후 복구된 상황을 구분할 수 있습니다. 테스트에도 트래픽이 발생하므로 기존 서비스의 이용 제한을 준수하세요.

3. 지역 표시는 후보를 찾는 참고 정보일 뿐 전체 경로를 뜻하지 않습니다

노드 이름에 표시된 지역은 대개 서비스 제공자가 붙인 태그로, 출구 지역을 설명할 수도 있고 단순한 회선 이름일 수도 있습니다. 접속 주소, 실제 출구, 대상 웹사이트에서 확인되는 IP의 위치가 서로 다를 수 있습니다. 지리적으로 가까운지는 참고 사항일 뿐이며, 통신사 간 연결, 우회 경로, 출구 부하가 직선거리보다 더 큰 영향을 줄 수 있습니다.

대상 서비스가 특정 출구 지역을 요구한다면 성능을 비교하기 전에 기존 연결의 실제 출구가 조건에 맞는지 확인하세요. 지역이 조건에 맞더라도 대상 웹사이트 접속이 보장되는 것은 아닙니다. 계정 지역, 사이트 정책, IP 판별 결과가 응답에 영향을 줄 수 있습니다. 접속 제한, 로그인 실패, CAPTCHA 증가를 지연 시간 탓으로 바로 돌리지 마세요.

4. 프로토콜은 먼저 설정 호환성을 확인한 뒤 네트워크 성능을 비교하세요

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard의 속도를 이름만으로 순위를 매길 수는 없습니다. 실제 오버헤드는 전송 방식, 암호화, TLS, 서버 구현, 네트워크 환경에 따라 달라집니다. 기존 서비스에서 명확히 지원하는 프로토콜을 선택하고 필요한 항목을 빠짐없이 유지하세요. Type을 다른 이름으로 바꿔도 기존 서버가 자동으로 호환되지는 않습니다.

어떤 프로토콜이 집에서는 정상인데 다른 네트워크에서 계속 시간 초과된다면, 먼저 네트워크 차이와 기존 서버 상태를 확인한 뒤 이미 설정된 다른 호환 후보를 고려하세요. 오류를 없애려고 인증서 검증을 바로 끄지 마세요. 인증서 문제는 서버 이름, 기기 시간, 서버 인증서를 확인해 해결해야 하며 검증 기준을 낮춰 덮어서는 안 됩니다.

5. 실제 서비스로 ‘지연 시간은 짧지만 사용하기 불편한’ 상황 확인하기

웹 페이지 로딩은 한 번의 왕복 통신으로 끝나지 않습니다. 보통 DNS, 연결 설정, TLS 협상, 여러 리소스 요청이 이어집니다. 테스트 주소에 접속된다고 해서 웹 페이지가 참조하는 모든 도메인이 정상이라는 보장은 없습니다. 동영상은 지속 전송량과 변동 폭에 더 큰 영향을 받습니다. 재생은 빨리 시작되지만 계속 버퍼링되는 경우와 첫 요청부터 시간 초과되는 경우는 서로 다른 문제이므로 따로 기록하세요.

• 웹 페이지: 같은 페이지에서 본문이 처음 표시될 때까지 걸리는 시간과 이미지·스크립트가 모두 로드되는지 비교하세요. 캐시가 결과를 바꿀 수 있으므로 새 비공개 브라우징 세션을 활용해 비교할 수 있지만, 다른 조건도 동일하게 유지해야 합니다.
• 동영상: 같은 콘텐츠와 화질로 몇 분간 재생하면서 시작 시간, 재생 위치를 이동한 뒤 다시 재생될 때까지 걸리는 시간, 버퍼링 상태를 기록하세요. 자동 화질은 대역폭 부족을 가릴 수 있으므로 재생 가능 여부만으로 판단하지 마세요.
• 다운로드: 같은 출처에서 지속적으로 전송되는 속도를 비교하고, 시작 직후 몇 초간의 최고치를 장기 속도로 간주하지 마세요. 서버 속도 제한이나 출처 사이트의 부하도 병목이 될 수 있습니다.
• 안정성: 여러 차례 테스트에서 성공과 시간 초과가 어떻게 분포하는지 기록하세요. 가끔 빠르지만 자주 실패하는 후보를 최저 지연 시간 한 번만으로 우선순위에 두지 마세요.

분기 규칙을 점검할 때 Home → Global Routing의 Direct는 직접 연결 설정을 뜻합니다. 이를 선택한 상태에서는 선택한 프록시의 실제 사용 성능을 확인할 수 없습니다. Config는 현재 설정을 따르고 Scene은 선택한 시나리오를 따릅니다. Config에서는 현재 사용 중인 Config도 확인해야 합니다. 앞쪽의 DOMAIN-SUFFIX, GEOIP 또는 IP-CIDR 규칙이 먼저 일치했을 수 있으며, FINAL은 앞선 규칙이 일치하지 않을 때만 적용됩니다. 속도 차이를 해석하기 전에 실제로 적용된 정책부터 확인하세요.

6. 자주 묻는 질문과 최종 후보 선정 기준

평소 사용할 후보 하나와 검증된 예비 후보 하나를 남기고, 각각 사용할 네트워크, 테스트 방식, 실제 서비스 성능을 기록하면 됩니다. 선택 순서는 설정이 정확하고 연결을 설정할 수 있는지, 대상 서비스가 작동하는지, 지속 전송이 안정적인지 확인한 뒤 지연 시간 수치를 비교하는 것입니다. 네트워크 조건이나 구독 내용이 바뀌면 다시 확인하세요. 더 낮은 ms 수치 한 번을 얻으려고 전체 설정을 자주 바꿀 필요는 없습니다.

이 글에서는 노드나 구독을 제공·판매·추천하지 않습니다. 모든 비교는 사용자가 이미 보유한 연결 서비스를 대상으로 합니다. 처음 설정한다면 빠른 시작 안내에서 가져오기, 연결, Global Routing의 기본 관계를 확인한 뒤 위 절차에 따라 후보를 추리세요.