Shadowrocket 노드 선택 방법: 지연 시간 테스트, 지역 및 프로토콜 비교

1. 지연 시간은 응답 속도를 나타내며 대역폭 한도를 뜻하지 않습니다

지연 시간 테스트는 탐색 요청을 보낸 뒤 응답을 받을 때까지 걸린 시간을 측정하며, 보통 ms 단위로 표시합니다. 테스트 방법마다 측정 경로가 다릅니다. TCP 핸드셰이크 테스트는 서버 주소와 포트가 제때 응답하는지 확인하고, 프록시를 거쳐 테스트 대상에 접속하는 방식은 프록시 협상, 대상 주소 확인, 대상 서버의 응답 속도에도 영향을 받습니다. 먼저 테스트 방식을 확인한 다음 수치를 비교하세요. 서로 다른 방식의 결과를 같은 순위표에 놓고 비교하면 안 됩니다.

Home에서 Connectivity Test를 사용할 때는 모든 후보에 같은 테스트 방식과 대상을 적용하세요. 현재 화면에서 테스트 방식을 선택할 수 있다면 동일하게 유지합니다. 목록에 표시되는 결과는 한 번의 탐색 기록일 뿐 이후 모든 요청을 보장하지 않습니다. 시간 초과도 이번 탐색이 제한 시간 안에 끝나지 않았다는 뜻일 뿐이므로, 한 번의 시간 초과만으로 구독이 만료됐다고 판단하지 마세요.

지연 시간이 짧으면 소규모 요청에 빠르게 응답할 가능성이 있습니다. 하지만 지속적인 다운로드 속도는 사용 가능한 대역폭, 패킷 손실, 혼잡, 서버 부하, 대상 사이트의 속도 제한에도 좌우됩니다. 예를 들어 후보의 응답은 빠르지만 공유 출구가 혼잡하면 웹페이지 첫 화면은 빨리 나타나도 대용량 파일 전송은 낮은 속도에 오래 머물 수 있습니다. 반대로 응답은 조금 느려도 전송이 안정적으로 이어지는 후보가 동영상 버퍼링이나 파일 전송에 더 적합할 수 있습니다.

2. 테스트 조건을 통일한 다음 Home에서 후보를 선택하세요

현재 작동하는 구성을 유지하고, 지연 시간을 비교하는 동안 구독 업데이트와 규칙 변경, 네트워크 전환을 한꺼번에 하지 마세요. Home에서는 서버와 연결을 선택하고, Config에서는 구성 파일을 관리하며, Settings에는 관련 설정이 있습니다. 각 항목을 구분해야 사용 경험의 변화가 노드 선택 때문인지, 라우팅이나 자동 연결 조건 때문인지 파악할 수 있습니다.

1. 구독 확인

   Home에서 기존 구독 그룹과 서버 항목을 확인하세요. 아직 추가하지 않았다면 Home → 오른쪽 위의 “+” → Type → Subscribe로 이동해 서비스 제공업체에서 받은 구독 링크를 입력하고 저장합니다. 먼저 한 번 업데이트한 다음 테스트가 끝날 때까지 그룹을 반복해서 새로 고치지 마세요.

2. 네트워크 고정

   같은 Wi-Fi에 연결한 상태로 첫 테스트를 진행하고, 다른 기기의 대량 전송은 잠시 중지하세요. Settings → On Demand에서 기존 트리거 조건을 확인합니다. 이 조건이 수동 연결 해제와 재연결을 방해한다면 기존 설정을 기록한 뒤 테스트 중에는 일시 중지하고, 테스트가 끝나면 복원하세요.

3. 라우팅 통일

   Home → Global Routing에서 기존 상태를 기록하세요. 짧게 통제된 비교를 할 때는 Config의 직접 연결 규칙이 미치는 영향을 줄이도록 Proxy를 선택할 수 있습니다. 테스트가 끝나면 원래 상태로 복원하세요. Direct 상태에서 직접 연결된 대상의 속도를 선택한 노드의 성능으로 판단하지 마세요.

4. 반복 탐색

   Home → Connectivity Test에서 모든 후보를 같은 방식으로 테스트하고, 잠시 간격을 두어 세 번 반복하세요. 성공 횟수와 변동 범위를 기록한 뒤 응답이 계속 확인되는 항목 두세 개만 남기면 됩니다. 구독 전체를 매번 테스트할 필요는 없습니다.

5. 실제 요청 확인

   Home에서 후보를 선택해 연결한 뒤 같은 웹사이트와 파일로 다시 테스트하세요. 전환 후에는 테스트 연결을 새로 설정합니다. 필요하다면 Shadowrocket을 다시 연결해 기존의 장시간 연결이 이전 경로를 계속 사용하지 않도록 하세요. 마지막으로 Config로 돌아가 평소 규칙을 적용했을 때의 사용 경험을 확인합니다.

3. 지역은 용도에 따라 고르고 실제 출구를 확인하세요

노드 이름에 표시된 지역은 보통 구독 제공업체가 지정합니다. 이 정보는 진입 지점, 출구 또는 회선의 용도를 나타낼 수 있으며, 기기에서 대상 웹사이트까지의 실제 경로를 뜻하지는 않습니다. 물리적으로 가까우면 일반적으로 전파 지연 시간을 줄이는 데 유리하지만, 네트워크 연결 관계와 우회 경로, 혼잡도에 따라 결과가 달라질 수 있습니다. 같은 지역에 있는 두 회선도 성능 차이가 클 수 있습니다.

웹사이트에는 보통 요청의 출구 주소가 표시되지만, 지역 판정에는 계정 정보, 기기 권한, 이전 세션, 주소 데이터베이스도 활용될 수 있습니다. 노드를 바꿔도 웹사이트의 지역 판정이 즉시 달라진다는 보장은 없습니다. 특정 웹사이트에서 지역이 잘못 인식된다면 먼저 해당 요청이 의도한 정책을 거쳤는지 확인한 뒤, 출구 주소 문제인지 웹사이트 자체의 판정 문제인지 구분하세요. 원인을 파악하지 못한 채 노드만 계속 바꾸지 마세요.

4. 프로토콜은 네트워크 조건에 맞춰 고르고 이름만 보고 속도를 비교하지 마세요

프로토콜은 클라이언트와 서버가 통신하는 방식을 정하지만, 프로토콜만으로 회선 품질이 결정되지는 않습니다. Shadowsocks, VMess, VLESS의 실제 성능은 전송 방식과 관련 설정에도 영향을 받습니다. Trojan은 TLS 연결에 자주 사용되며, Hysteria2는 QUIC 기반으로 UDP 경로에 의존하고, WireGuard는 UDP로 터널을 구성합니다. 서버와 지역, 부하 조건이 다른 테스트 결과를 프로토콜의 우열로 단정하지 마세요.

포트는 서버 설정과 일치해야 합니다. 예를 들어 구성이 TCP 443으로 지정돼 있다면 해당 포트로 테스트하세요. TLS에 흔히 사용된다는 이유만으로 임의의 값으로 바꾸면 안 됩니다. UDP 443과 TCP 443은 서로 다른 전송 엔드포인트이므로 한쪽이 연결된다고 다른 쪽도 연결된다는 뜻은 아닙니다. 테스트 수치를 낮추려고 포트를 무작위로 바꾸거나 인증서 검증을 끄거나 인증 정보를 변경하지 마세요.

같은 서비스 제공업체에서 받은 프로토콜별 항목이 진입 지점, 출구, 부하를 공유하지 않는다면 각각을 별개의 후보로 보고 전체 조건을 비교하세요. 전송 방식이 사용 경험에 미치는 영향을 비교하려면 서버, 대상, 시간, 네트워크를 최대한 동일하게 유지해야 합니다. 특정 프로토콜을 지원한다는 것은 연결할 수 있다는 뜻이지 해당 회선의 성능을 보장한다는 뜻은 아닙니다.

5. 일정한 기록 양식으로 지연 시간, 변동, 전송량을 구분하세요

한 번에 후보 두세 개만 비교하고, 먼저 연속으로 테스트한 다음 자주 사용하는 시간대에 다시 확인하세요. 아래 설정 카드는 직접 기록하기 위한 양식이며 Shadowrocket에 가져올 수 있는 구성 파일이 아닙니다. 여기에 적힌 시간과 테스트 횟수는 이 절차에서 조건을 통일하기 위한 것이며 제품의 제한을 뜻하지 않습니다.

예를 들어 후보 A의 탐색 결과가 42, 45, 310 ms이고 후보 B가 78, 81, 80 ms라고 가정해 보겠습니다. 판단 방식을 설명하기 위한 예시일 뿐 실제 회선 테스트 결과가 아닙니다. A의 최저 수치는 더 낮지만 이번 기록에서는 변동이 컸고, B는 더 일관적이었습니다. 이후 실제 요청으로 다시 확인해야 합니다. 세 번의 탐색만으로 하루 종일 안정적이라고 판단할 수 없으며, 응답 시간 차이를 다운로드 속도로 환산할 수도 없습니다.

• 웹 탐색: 처음 열 때와 다시 열 때, 이미지 로딩이 함께 느려지는지 확인하세요. 캐시가 차이를 가릴 수 있다는 점에 유의하세요.
• 동영상: 같은 화질에서 버퍼링과 끊김을 확인하세요. 플레이어가 화질을 자동으로 낮춘 뒤 원활해진 결과를 같은 조건의 비교로 간주하지 마세요.
• 파일 전송: 같은 파일과 출처를 사용하고 MB/s와 Mbps를 구분하세요. 십진 단위 기준으로 1 MB/s는 8 Mbps에 해당합니다.
• 실시간 상호작용: 지연 변동과 간헐적인 끊김을 확인하세요. 해당 서비스가 UDP를 사용한다면 UDP 경로도 직접 테스트해야 합니다.

6. 이상이 생기면 노드를 바꾸기 전에 경로부터 확인하세요

Proxy에서는 정상인데 Config로 돌아간 뒤 문제가 생긴다면 노드를 계속 바꾸기보다 규칙 경로부터 확인하세요. DOMAIN-SUFFIX는 도메인 접미사로, IP-CIDR은 주소 범위로, GEOIP는 IP 주소의 지역 분류로 매칭합니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 규칙 순서, DNS 결과, 정책 그룹 선택이 최종 출구에 영향을 줄 수 있습니다. Config에서 현재 활성화된 구성을 확인하고 요청 기록을 바탕으로 어떤 규칙이 적용됐는지 찾으세요.

7. 주 사용 경로와 대체 경로를 남기고 일정한 조건으로 다시 확인하세요

목표는 항상 가장 낮은 ms 수치를 얻는 것이 아니라, 실제 사용 환경에서 반복해 확인할 수 있는 경로를 확보하는 것입니다. 주 사용 후보는 자주 방문하는 웹사이트에 접속할 수 있고, 상호작용이 안정적이며, 지속 전송에 충분한 성능을 갖춰야 합니다. 대체 후보는 주 사용 후보와 경로가 다른 것이 좋습니다. 이름은 달라도 실제로 같은 출구를 공유한다면 유효한 대체 경로가 아닐 수 있습니다.

• 평소에는 기존 Global Routing 및 On Demand 설정을 복원해 테스트 중의 임시 상태를 계속 사용하지 않도록 하세요.
• 사용 경험이 계속 달라지거나 구독 항목 또는 네트워크 환경이 바뀌었을 때 다시 확인하세요. 지연 시간이 한 번 높아졌다고 바로 전환하지 마세요.
• 후보 이름, 프로토콜, 네트워크, 테스트 시간을 기록해 이전 결과와 비교할 수 있도록 보관하세요.
• 문제가 생기면 한 번에 하나의 변수만 바꾸세요. 먼저 네트워크를 확인하고, 다음으로 후보를 바꾼 뒤 프로토콜 설정과 규칙을 살펴보세요.

화면 위치와 조작 방법을 더 확인하려면 사용 설명서를 참고하세요. 용어가 낯설다면 용어 설명에서 확인할 수 있습니다. 먼저 실제 요청 경로를 확인한 뒤 지연 시간, 지역, 프로토콜을 살펴보면 목록 전체를 자주 새로 고치는 것보다 문제를 쉽게 찾을 수 있습니다.