Shadowrocket 노드 지연 시간 테스트 보는 법: 지역·프로토콜별 기존 노드 선택

1. 지연 시간 수치가 측정하는 것

지연 시간은 보통 ms(밀리초)로 표시되지만, 수치의 의미는 테스트 방식에 따라 다릅니다. 서버에 TCP 연결 테스트를 하면 해당 주소와 포트에 연결하는 데 걸린 시간이 주로 측정됩니다. 프록시를 통해 HTTP 또는 HTTPS 테스트 대상에 접속하면 프록시 협상, 대상 서버 연결, 응답 대기 시간까지 포함됩니다. 두 방식은 측정하는 경로가 다르므로 결과를 같은 지표로 보고 순위를 매길 수 없습니다.

먼저 앱에서 현재 사용하는 테스트 방식과 테스트 대상을 확인한 뒤 노드를 비교하세요. 테스트가 서버 포트 연결만 확인한다면 수치가 낮아도 해당 구간의 응답이 빠르다는 뜻일 뿐, 대상 웹사이트에 접속할 수 있다는 보장은 없습니다. 프록시를 거쳐 지정된 대상에 접속하는 테스트도 해당 시점의 해당 대상만 보여줄 뿐, 모든 웹사이트와 시간대의 결과를 대표하지는 않습니다.

시간 초과가 발생했다고 해서 노드가 반드시 작동하지 않는 것은 아닙니다. 테스트 대상에 연결할 수 없거나, 이름 해석에 실패하거나, 서버 포트가 제한되거나, 프로토콜 핸드셰이크가 실패하면 테스트가 완료되지 않을 수 있습니다. ‘포트 연결 가능 여부’, ‘프록시 연결 여부’, ‘대상에서 콘텐츠를 받아오는지’를 각각 확인해 하나의 오류 표시로 모든 문제를 단정하지 마세요.

2. 조건을 고정한 뒤 기존 구독 테스트하기

비교하기 전에 구독을 업데이트하고 현재 네트워크를 기록하세요. 업데이트로 주소, 포트 또는 노드 목록이 바뀔 수 있습니다. 일부 결과는 업데이트 전, 나머지는 업데이트 후에 측정했다면 같은 설정을 비교한 것이 아닙니다. 구독 링크는 접속 자격 정보이므로 스크린샷이나 공개 메모, 문의 글에 포함하지 마세요.

1. 구독 확인

   Home(홈)에서 본인의 구독 그룹을 찾습니다. 처음 가져오는 경우 Home → “+” → Type(유형) → Subscribe(구독)에서 이미 보유한 링크를 입력하고 저장하세요. 이미 가져온 항목은 다시 추가할 필요가 없습니다.

2. 업데이트 완료

   Home에서 기존 구독을 업데이트하고 목록이 새로 고쳐졌는지 확인합니다. 업데이트에 실패하면 먼저 링크 접속이나 인증 정보를 점검하세요. 이전 목록의 테스트 결과를 최신 상태로 간주하지 마세요.

3. 환경 고정

   같은 Wi-Fi 또는 셀룰러 네트워크를 사용하고, 진행 중인 대용량 전송을 일시 중지하세요. Settings(설정) → On Demand(요청 시 연결)에서 자동 연결 조건을 확인해 테스트 중 네트워크 전환으로 연결 상태가 바뀌지 않도록 합니다.

4. 반복 측정

   Home에서 후보 노드의 지연 시간을 테스트하되 테스트 방식과 대상을 동일하게 유지하세요. 각 항목을 잠시 간격을 두고 세 번 측정해 시간 초과 여부를 기록합니다. 여러 노드의 결과는 1차 선별에 활용하고, 남은 후보 몇 개는 개별적으로 다시 테스트하세요.

5. 실제 접속 확인

   후보 노드를 선택해 연결하고 Global Routing(전역 라우팅) 모드를 확인한 다음 같은 대상 페이지를 엽니다. 첫 화면 표시, 연속 탐색, 장시간 요청이 각각 원활한지 확인하세요.

세 번 측정한다고 통계적으로 보장되는 것은 아니지만, 한 번만 측정할 때보다 일시적인 변동을 알아보기 쉽습니다. 예를 들어 한 항목이 48 / 51 / 49 ms, 다른 항목이 25 / 시간 초과 / 180 ms라면 첫 번째 항목을 다음 단계에서 확인해 볼 만합니다. 이 수치는 결과를 해석하는 예시일 뿐, 실제 노드 측정값이나 적정 기준이 아닙니다.

3. 지역별로 고르기: 노드 이름은 참고 정보

지역은 먼저 실제 사용 목적에 맞춰 선택하세요. 이용하려는 콘텐츠가 특정 지역의 출구를 요구한다면 출구 지역을 확인한 뒤 같은 지역 후보끼리 비교합니다. 지역 제한이 없다면 안정성과 실제 접속 결과를 우선으로 살펴보세요. 노드 이름의 지역명, 국기 또는 약어는 구독 정보에 포함된 표기일 뿐, 서버 위치나 최종 출구 위치를 단독으로 증명하지 않습니다.

같은 지역의 두 노드도 서로 다른 진입 지점, 중계 경로 또는 출구를 사용할 수 있습니다. 반대로 이름에 서로 다른 지역이 적힌 노드도 경로 일부를 공유할 수 있습니다. 따라서 ‘가까우면 무조건 빠르다’거나 ‘같은 지역이면 성능도 같다’고 가정해선 안 됩니다. 지역명만 적지 말고 구체적인 노드, 사용 네트워크, 테스트 시간도 기록하세요.

4. 프로토콜별로 고르기: 연결 조건 먼저 확인

Shadowrocket에 이미 등록된 노드는 Shadowsocks, VMess, VLESS, Trojan, Hysteria2 또는 WireGuard를 사용할 수 있습니다. 프로토콜 이름은 연결 방식을 나타낼 뿐 지연 시간이나 대역폭 순위를 알려주지는 않습니다. 같은 프로토콜도 서버, 포트, 네트워크 경로에 따라 성능이 크게 달라질 수 있습니다. 특정 프로토콜 이름을 선호한다는 이유로 기존 구독 설정을 임의로 바꾸지 마세요.

Hysteria2는 QUIC 기반으로 작동합니다. 현재 네트워크에서 UDP를 제한한다면 이름만 다른 같은 지역의 유사 노드로 바꿔도 문제가 해결되지 않을 수 있습니다. WireGuard도 UDP를 사용하지만 핸드셰이크와 터널 방식이 다르므로 TCP 연결 시간만으로 연결 상태를 해석할 수 없습니다. VMess나 VLESS 역시 Type만 비교해서는 충분하지 않으며 전송 방식과 서버 설정도 고려해야 합니다.

• 같은 지역에서 프로토콜을 비교할 때는 테스트 시간대와 대상이 비슷한 후보를 골라 환경 변화의 영향을 줄이세요.
• 프로토콜 연결에 실패하면 먼저 구독 업데이트, 주소, 포트, 인증 매개변수를 확인하세요. 검증 조건을 낮춰 연결을 한 번 성공시키려 하지 마세요.
• 특정 연결 방식이 Wi-Fi에서만 실패하고 셀룰러에서는 정상이라면 해당 네트워크의 전송 제한을 먼저 확인하세요.
• 구독 노드의 포트, TLS 또는 전송 매개변수를 여러 개 한꺼번에 직접 수정하지 마세요. 이러한 설정은 서버 측 지원이 필요합니다.

5. 지연 시간은 짧은데 페이지가 열리지 않을 때: Global Routing과 규칙 확인

지연 시간 테스트가 통과해도 웹 요청이 방금 테스트한 노드를 사용한다는 뜻은 아닙니다. Home → Global Routing의 Proxy(프록시), Direct(직접 연결), Config(구성), Scene(시나리오)이 라우팅 방식을 결정합니다. 평소에는 기존 Config에 따라 트래픽을 분할하고, 문제를 확인할 때는 요청이 실제로 어떤 경로를 사용하는지 파악해야 합니다.

Scene은 상황에 따른 라우팅에 사용됩니다. 실제 동작은 기존 Scene 설정에 따라 달라지므로 이름만 보고 현재 경로를 판단할 수 없습니다. 테스트 전에 Scene이 활성화되어 있다면 해당 설정을 확인하거나, 원래 설정을 기록한 뒤 문제 확인에 적합한 모드로 전환하세요.

• Config(구성)에서 현재 활성화된 구성을 확인하세요. 비활성 파일만 살펴보지 마세요.
• DOMAIN-SUFFIX는 도메인 접미사로, GEOIP는 IP 지리 정보로, IP-CIDR은 IP 대역으로 일치 항목을 찾습니다.
• FINAL은 앞선 규칙이 하나도 일치하지 않을 때 적용되는 최종 경로입니다. 규칙 순서와 규칙이 참조하는 정책이 결과에 영향을 줍니다.
• 연결 기록에서 대상, 일치한 규칙, 라우팅 결과를 확인하세요. 대상이 DIRECT로 분류됐다면 해당 페이지 결과로 프록시 노드를 평가할 수 없습니다.

6. 실제 요청으로 ‘빠른 응답’과 ‘안정적인 전송’ 구분하기

지연 시간이 짧으면 작은 요청을 자주 주고받을 때 유리할 수 있지만, 지속적인 전송은 사용 가능한 대역폭, 패킷 손실, 혼잡, 대상 서버 부하에도 영향을 받습니다. 핸드셰이크는 빠르지만 콘텐츠를 전송하는 동안 계속 멈추는 노드가 있을 수 있습니다. 반대로 첫 응답은 조금 느려도 이후 요청을 안정적으로 처리하는 노드도 있습니다. 실제 용도에 맞춰 각각 확인하고 두 특성을 하나의 수치로 합치지 마세요.

브라우저 캐시와 연결 재사용도 체감에 영향을 줍니다. 같은 페이지를 두 번째 열 때 더 빠른 것은 노드 성능이 나아진 것이 아니라 캐시가 사용된 결과일 수 있습니다. 비교할 때는 가능한 한 같은 콘텐츠와 비슷한 요청 조건을 사용하세요. 동영상을 재생하거나 대량 파일을 동기화하면서 지연 시간 변화를 근거로 노드 성능을 판단하지 마세요. 테스트 자체도 네트워크 트래픽을 발생시키므로 기존 서비스의 트래픽 제한도 고려해야 합니다.

7. 재현 가능한 선택 결과 기록하기

최종적으로 남길 것은 영구적인 순위가 아니라 ‘특정 네트워크와 용도에서 검증한 선택’입니다. 구독 업데이트, 서버 변경, 로컬 네트워크 변화로 이전 결과가 더는 유효하지 않을 수 있습니다. 모든 노드를 자주 테스트할 필요는 없습니다. 문제가 생기거나 네트워크를 바꾸거나 구독이 변경된 뒤 자주 쓰는 후보 몇 개만 다시 확인하세요.

1. 조건 기록: Wi-Fi 또는 셀룰러, 테스트 방식, 대상, 테스트 시간을 적고 구독 인증 정보는 공개하지 마세요.
2. 후보 기록: 노드 이름, 지역 표기, Type, 업데이트 상태를 남겨 이름이 비슷한 항목을 혼동하지 않도록 합니다.
3. 결과 기록: 지연 시간, 시간 초과 횟수, 실제 요청 결과를 각각 적고 가장 낮은 수치만 발췌하지 마세요.
4. 라우팅 기록: Global Routing 모드와 실제 적용된 정책을 적어 다음에도 같은 조건으로 확인할 수 있게 합니다.
5. 예비 선택 보관: 기존에 보유한 항목 중 테스트를 마친 대체 노드를 남겨 두고, 전환한 뒤에는 접속 결과를 다시 확인하세요.