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

노드 출처와 테스트 조건 확인하기

Shadowrocket의 노드는 서버 주소, 포트, 프로토콜, 인증 정보 등이 포함된 연결 설정입니다. 구독을 이용하면 설정을 한곳에서 가져오고 업데이트로 변경 사항을 동기화할 수 있습니다. 노드 이름은 식별용이며 서버 위치, 출구 IP 또는 현재 부하를 증명하지 않습니다. 이름이 같더라도 설정을 업데이트한 뒤에는 내용이 달라졌을 수 있습니다.

비교를 시작하기 전에 Home에서 기존 구독이 불러와졌고 비교할 노드가 목록에 있는지 확인하세요. 서비스 제공자가 설정 변경을 안내한 경우에만 해당 구독을 업데이트하고 결과를 확인합니다. 테스트 도중 업데이트하면 전후 측정에 서로 다른 서버 설정이 적용될 수 있으므로 피하세요.

1. 설정 확인

   Home에서 기존 노드를 확인하세요. 처음 가져오는 경우 Home 오른쪽 위의 «+» → Type → Subscribe를 선택하고 본인의 구독 주소를 입력한 뒤 저장합니다. 가져온 후 목록에 노드가 실제로 표시되는지 확인하세요.

2. 네트워크 조건 고정

   Wi-Fi 또는 셀룰러 네트워크 중 하나만 사용하고 대용량 전송은 일시 중지하세요. Settings → On Demand에서 현재 상태를 기록해 테스트 중 네트워크 조건 변화로 연결 상태가 자동 전환되지 않도록 합니다.

3. 같은 방식으로 테스트

   Home → Connectivity Test에서 현재 테스트 방식을 확인하세요. 모든 후보에 같은 방식을 사용하고, 화면에서 테스트 대상을 설정할 수 있다면 대상도 동일하게 유지합니다.

4. 여러 번 측정해 기록

   후보를 몇 개만 골라 하나씩 테스트하고, 각 후보의 결과와 테스트 시간을 최소 세 번 기록하세요. 시간 초과도 기록에 포함하고 한 번 나온 최저값만 적지 마세요.

노드 테스트는 해당 노드로 업무 트래픽을 전환했다는 뜻이 아닙니다. 테스트 후 Home에서 후보를 선택하고 연결 상태를 확인하세요. 기존에 연결된 장시간 연결은 새 경로로 즉시 바뀌지 않을 수 있습니다. 실제로 확인하려면 대상 앱을 다시 열거나 새 요청을 보내세요.

지연 시간으로 알 수 있는 것과 알 수 없는 것

지연 시간은 보통 ms로 표시되며, 값이 작을수록 해당 테스트에서 대기한 시간이 짧다는 뜻입니다. 다만 테스트 방식에 따라 확인하는 구간이 다릅니다. TCP 핸드셰이크는 서버 포트까지 연결이 설정되는지 주로 확인하고, 프록시를 통해 테스트 대상에 접속하는 방식은 프로토콜 핸드셰이크, 대상의 응답, 관련 이름 확인 과정에도 영향을 받습니다. 두 방식의 값을 그대로 비교해 순위를 매길 수는 없습니다.

예를 들어 가상의 결과가 한 그룹은 42, 190, 시간 초과이고 다른 그룹은 86, 89, 91이라고 해 보겠습니다. 첫 그룹의 단일 최저값은 더 낮지만, 이 세 번의 기록에서는 두 번째 그룹이 더 일정합니다. 이는 기록 방식을 설명하기 위한 가정일 뿐 실제 회선 측정값이 아니며 장기적인 품질을 보여 주지도 않습니다.

지연 시간은 전송 속도와 다릅니다. 짧은 테스트 요청은 빠르게 끝나도 지속 전송은 대역폭, 혼잡, 패킷 손실, 서버 처리 능력의 영향을 받습니다. 반대로 지연 시간이 조금 더 긴 경로가 꾸준히 더 안정적으로 로딩될 수도 있습니다. ms를 다운로드 속도로 여기거나 짧은 테스트 한 번으로 동영상이 계속 재생될지 판단하지 마세요.

지역별 선별: 거리보다 실제 목적지 확인

지역은 후보를 추리는 기준이 될 수 있지만 지리적 거리가 네트워크 경로의 길이와 같지는 않습니다. 기기에서 진입 서버까지, 서비스 내부의 전달 구간, 출구에서 대상 사이트까지는 각각 다른 단계입니다. 노드 이름의 지역은 기기가 처음 연결하는 서버 위치가 아니라 출구 위치를 가리킬 수도 있습니다.

대상 서비스는 계정 지역, 기기 위치, 결제 정보, 기존 세션도 함께 참조할 수 있습니다. 노드를 바꾸면 네트워크 조건 일부만 달라질 뿐 서비스 이용 가능 범위까지 바뀐다고 보장할 수는 없습니다. 페이지에 기존 상태가 계속 표시되면 요청이 새 노드를 실제로 통과했는지 먼저 확인한 뒤 대상 서비스의 정책을 살펴보세요. 판단이 흐려지지 않도록 노드를 반복해서 전환하지 마세요.

프로토콜별 선별: 먼저 호환 조건 확인

프로토콜 이름은 연결 방식을 나타내며 성능 등급을 뜻하지 않습니다. 같은 프로토콜도 서버와 네트워크 경로에 따라 결과가 달라질 수 있고, 같은 서버가 여러 프로토콜을 제공할 수도 있습니다. 비교할 때는 다른 변수를 최대한 통제하세요. 지역, 서버, 프로토콜을 한꺼번에 바꾼 뒤 나타난 차이를 모두 프로토콜 탓으로 돌릴 수는 없습니다.

포트 번호는 연결 설정의 일부일 뿐입니다. 예를 들어 설정에 443이 있다고 해서 노드의 프로토콜 종류, TLS 사용 여부, 현재 네트워크에서의 연결 가능 여부를 단독으로 확인할 수는 없습니다. 테스트를 통과하려고 기존 포트를 임의로 443으로 바꾸지 마세요. 서버가 해당 포트에서 일치하는 서비스를 실제로 제공해야 합니다.

지연 시간은 짧은데 접속이 안 될 때: Global Routing 확인

노드 테스트 성공은 해당 테스트가 완료되었다는 의미일 뿐입니다. 실제 접속은 Global Routing, 현재 설정된 규칙, DNS, 대상 서비스 상태의 영향도 받습니다. 실제 요청이 Direct로 처리되거나 특정 규칙이 다른 정책을 지정하면, 측정한 노드 지연 시간만으로 접속 결과를 설명할 수 없습니다.

Scene을 사용한다면 해당 장면의 설정과 실제 적용 상태도 먼저 확인하세요. 장면 전환을 노드 자체의 변경으로 착각하지 마세요. 비교할 때는 Global Routing 모드를 하나로 고정하고 테스트 후 복원할 설정을 기록하세요.

• DOMAIN-SUFFIX,example.com,PROXY: 예시 도메인 접미사가 일치하면 PROXY 정책을 사용합니다.
• IP-CIDR,192.168.0.0/16,DIRECT: 예시 사설 IP 주소 대역에는 DIRECT를 사용합니다.
• GEOIP,CN,DIRECT: GEOIP 판정 결과로 일치 여부를 확인하며, 노드 이름의 지역을 기준으로 판단하는 것과는 다릅니다.
• FINAL,PROXY: 앞선 규칙에 일치하지 않으면 PROXY를 사용합니다. 규칙은 순서대로 확인해야 합니다.

위 내용은 규칙을 설명하기 위한 예시이며 기존 설정을 교체하라는 뜻이 아닙니다. 특정 도메인만 실패한다면 먼저 해당 요청의 정책과 이름 확인 결과를 살펴보세요. 모든 후보가 같은 대상에서 실패한다면 모든 노드가 사용할 수 없다고 단정하기 전에 대상 서비스 자체도 확인해야 합니다.

테스트 결과를 정리해 기본 노드와 예비 노드 정하기

1차 선별 후 후보를 몇 개만 남기고 실제 사용 순서에 따라 확인하세요. 대상 페이지를 열고 다음 단계의 콘텐츠로 이동한 뒤 몇 분간 연속으로 사용해 봅니다. 동영상이나 파일 전송을 비교한다면 화질이나 파일 조건을 동일하게 유지하고 데이터 사용량에도 유의하세요. 캐시가 적용되면 두 번째 접속이 훨씬 빨라질 수 있으므로 두 번째 로딩만으로 노드가 개선됐다고 판단하지 마세요.

1. 기본 노드 선택: 자주 사용하는 네트워크와 시간대에 실제 대상에 끝까지 접속할 수 있고 반복 결과가 안정적인 후보를 우선하세요. 한 번 측정된 최저 ms만 좇지 마세요.
2. 예비 노드 보관: 기존 구독에서 같은 검증을 통과한 후보를 하나 더 남겨 두세요. 이름이 다르다고 실제 경로도 다르다는 뜻은 아닙니다. 서로 다른 경로인지 여부는 기존 서비스 정보를 기준으로 확인하세요.
3. 네트워크를 바꿔 다시 테스트: Wi-Fi에서의 순위를 셀룰러 네트워크에 그대로 적용할 수 없습니다. 네트워크를 바꾼 뒤 간단한 테스트와 실제 대상 접속을 다시 확인하세요.
4. 변경 후 재확인: 구독 업데이트, 설정 전환, 서비스 매개변수 변경 후에는 선택한 노드와 Global Routing 상태를 다시 확인하세요.

기록은 복잡할 필요가 없습니다. 네트워크 종류, 시간, 노드 이름, 프로토콜, 세 번의 지연 시간, 실제 대상이 끝까지 로딩됐는지만 적으면 됩니다. 특정 후보가 저녁에만 자주 실패한다면 그 조건을 기록하는 편이 ‘잘 됨’ 또는 ‘안 됨’이라고 적는 것보다 다음 판단에 도움이 됩니다.