Shadowrocket 느린 속도 단계별 점검: 노드·회선·프로토콜·로컬 네트워크

먼저 테스트 조건을 고정해 측정 결과의 혼선을 줄이기

속도 점검에서 가장 흔한 실수는 Wi‑Fi, 노드, 프로토콜과 측정 대상을 동시에 바꾸는 것입니다. 결과가 빨라져도 무엇이 영향을 주었는지 알 수 없습니다. 기기, 네트워크, 측정 대상과 시간을 고정하고 매번 변수 하나만 바꾸며 최소 세 번 반복하세요.

먼저 Shadowrocket 연결을 사용하지 않을 때의 로컬 네트워크 상태를 기록합니다. 웹페이지 최초 표시 시간, 다운로드 속도와 기본 지연 시간을 포함하세요. 이후 같은 Wi‑Fi와 같은 측정 대상을 유지한 채 Shadowrocket을 켜고 결과를 기록합니다. 로컬 기준 자체가 크게 흔들린다면 클라이언트 설정을 바로 바꾸기보다 라우터, 신호 또는 접속 네트워크를 먼저 점검해야 합니다.

1. 로컬 기준 기록

   Shadowrocket 연결 스위치를 끄고 같은 Wi‑Fi에서 세 번 연속 테스트하세요. 지연 시간, 다운로드 속도와 웹페이지 최초 표시 시간을 기록하고 최고값만 남기지 마세요.

2. 노드 하나로 고정

   Home으로 돌아가 사용자가 보유한 서비스의 노드 하나를 선택하세요. 테스트 중에는 구독을 새로 고치거나 노드가 자동으로 전환되지 않도록 합니다.

3. Config 사용

   Home → Global Routing에서 Config를 선택해 현재 구성 파일의 규칙에 따라 요청을 처리하세요. 점검 중에는 구성 이름도 함께 기록해 규칙 변화와 회선 변화를 혼동하지 않도록 합니다.

4. 세 차례 반복 테스트

   연결을 켠 뒤 같은 대상을 세 차례 연속 테스트하고 각 회차 사이에 약 30초를 두세요. 결과가 18 Mbps, 76 Mbps, 24 Mbps라면 안정적인 속도 제한보다 변동으로 판단하는 것이 우선입니다.

5. 한 번에 한 항목만 변경

   노드를 바꾼 뒤 다시 테스트하세요. 노드 차이를 확인한 다음 프로토콜이나 전송 설정을 비교합니다. 같은 회차에 DNS, MTU, Global Routing과 노드를 동시에 변경하지 마세요.

1단계: 로컬 네트워크와 기기 연결 확인

앱에서 요청이 발생하면 먼저 기기의 현재 네트워크를 거친 다음 시스템이 만든 VPN 터널로 들어갑니다. 약한 Wi‑Fi 신호, 바쁜 라우터, 접속 네트워크 전환 또는 로컬 네트워크의 패킷 손실은 트래픽이 원격 노드에 도달하기 전에 지연을 일으킬 수 있습니다. 이때 프로토콜을 바꾸는 것만으로는 원인을 해결하기 어렵습니다.

iPhone 또는 iPad에서는 먼저 무선 라우터 가까이에서 테스트한 뒤, 이미 안정적인 것으로 확인된 다른 Wi‑Fi로 전환해 다시 측정할 수 있습니다. 조건이 허용되면 셀룰러 네트워크와도 비교하세요. 두 테스트는 반드시 같은 노드와 같은 대상을 사용해야 합니다. 특정 Wi‑Fi에서 모든 노드가 느리고 다른 네트워크에서는 정상이라면 문제는 로컬 접속 계층에 있을 가능성이 큽니다.

“처음 연결할 때는 빠르지만 몇 분 뒤 점점 느려지는” 현상도 살펴보세요. 무선 신호 간섭, 라우터 부하 변화 또는 기기가 서로 다른 액세스 포인트 사이를 전환하는 상황이 원인일 수 있습니다. 먼저 화면을 켠 상태로 짧은 테스트를 완료한 다음 5~10분간 지속 전송을 진행해 짧은 연결과 긴 연결의 차이를 비교하세요.

• 모든 노드가 동시에 느려짐: Wi‑Fi 신호, 라우터 부하와 현재 접속 네트워크를 우선 확인하세요.
• 노드 하나만 느려짐: 로컬 네트워크가 첫 번째 의심 대상은 아닙니다. 노드와 회선을 계속 확인하세요.
• 웹페이지 최초 표시만 느리고 이후 정상: DNS, 연결 수립과 TLS handshake 단계를 중점적으로 확인하세요.
• 작은 파일은 정상이고 큰 파일 전송만 점점 느려짐: 회선 처리량, 패킷 손실, MTU와 혼잡 제어를 중점적으로 확인하세요.
• 네트워크를 바꾸자 즉시 회복됨: 기존 Shadowrocket 설정은 유지하고 원래 네트워크 환경부터 점검하세요.

2단계: Ping과 시간대별 테스트로 노드와 회선 확인

Home의 노드 목록에서 지원되는 지연 시간 또는 Ping 테스트를 실행할 때 한 번의 결과만 보지 마세요. 단일 측정값 60 ms만으로 회선이 안정적이라고 할 수 없습니다. 58 ms, 62 ms, 61 ms처럼 연속 결과가 나오는 편이 35 ms, 240 ms, 90 ms보다 예측 가능성이 높습니다. 후자는 최저값은 더 낮지만 지터가 커 웹페이지나 동영상이 끊길 수 있습니다.

Ping은 원격 측의 응답 정책에도 영향을 받을 수 있으므로 시작 지표로만 사용해야 합니다. 지연 시간 테스트는 정상인데 실제 접속이 느리다면 실제 전송 테스트를 계속하고 Log에서 연결 수립, timeout과 재시도 시간 분포를 확인하세요. 원격에서 Ping에 응답하지 않는다고 해서 해당 서비스가 반드시 사용할 수 없는 것은 아닙니다.

회선의 시간대도 중요합니다. 아침, 저녁과 문제가 발생하는 특정 시간대에 같은 노드로 동일한 테스트를 진행하세요. 저녁에만 처리량이 떨어지고 로컬 기준과 다른 노드는 정상이라면 특정 회선 또는 원격 리소스의 시간대별 혼잡일 가능성이 높습니다.

3단계: Global Routing, 규칙과 DNS 확인

노드 자체는 정상인데 일부 웹사이트 또는 특정 앱만 느리다면 Global Routing을 확인하세요. Proxy는 현재 프록시 정책을 일괄 적용하고, Direct는 직접 연결하며, Config는 구성 파일의 규칙에 따라 처리하고, Scene은 설정된 장면에 따라 동작을 선택합니다. 일상 설정을 점검할 때는 Direct 또는 Proxy에 잘못 머물러 있지 않은지보다 먼저 현재 상태가 예상한 Config인지 확인하는 것이 좋습니다.

Config 모드에서는 요청이 위에서부터 규칙과 매칭됩니다. DOMAIN-SUFFIX는 도메인 접미사로, GEOIP는 대상 IP의 지리 데이터베이스 결과로, IP-CIDR은 주소 대역으로 매칭하며 FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 순서가 잘못되면 Direct여야 할 요청이 프록시로 들어가거나 프록시가 필요한 요청이 Direct에 먼저 매칭될 수 있습니다.

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

위 문법은 매칭 순서를 설명하기 위한 예이며 모든 구성에 적합하다는 뜻은 아닙니다. 첫 번째 규칙은 지정한 예시 도메인을 PROXY로 보내고, 두 번째는 로컬 네트워크 주소를 Direct로 처리하며, 세 번째는 GEOIP 결과에 따라 Direct로 처리하고, 마지막으로 FINAL이 나머지 요청을 받습니다. 실제 정책 이름은 현재 Config에 존재하는 정책과 일치해야 합니다.

“Ping은 정상인데 웹페이지가 오랫동안 빈 화면으로 남는” 현상이라면 DNS도 확인해야 합니다. 도메인 해석은 대상 연결을 수립하기 전에 이루어집니다. 해석 timeout, 연결할 수 없는 주소 반환 또는 네트워크별 캐시 결과 차이가 최초 표시 지연으로 나타날 수 있습니다. 여러 DNS 설정을 동시에 바꾸지 말고, 먼저 정상 작동이 확인된 설정으로 되돌린 뒤 하나씩 비교하세요.

• 먼저 Home에서 현재 노드와 Config 이름을 확인하세요.
• Global Routing이 실수로 Direct 또는 전체 Proxy에 머물러 있지 않은지 확인하세요.
• Config에서 FINAL만 보지 말고 대상 도메인에 가장 먼저 매칭된 규칙을 확인하세요.
• “도메인은 열리지 않지만 IP에는 연결되는” 현상이라면 DNS 해석 과정을 우선 확인하세요.
• 규칙을 수정한 뒤 새로 연결해 기존 연결의 캐시 결과를 새 규칙의 결과로 착각하지 않도록 하세요.

4단계: 프로토콜과 전송 설정 비교

Shadowrocket은 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard 등의 프로토콜을 지원합니다. 프로토콜 이름만으로 속도를 결정할 수는 없습니다. 실제 성능은 서버 설정, 암호화 방식, 전송 계층, 회선의 패킷 손실, CPU 부하와 설정 일치 여부에도 좌우됩니다. 같은 네트워크와 경로 조건이 비슷할 때에만 프로토콜 비교가 의미 있습니다.

변경하기 전에 사용자의 서비스 제공업체가 제공한 원본 설정을 저장하세요. 주소, 포트, 비밀번호, UUID, 공개 키, SNI, Transport, TLS와 경로는 한 세트로 일치해야 합니다. 주소와 포트만 복사하고 나머지 필드를 빠뜨리면 연결은 수립되지만 계속 재시도하거나 handshake가 실패하고 전송 효율이 비정상적으로 떨어질 수 있습니다.

• Shadowsocks: 암호화 방식, 비밀번호와 포트를 확인하세요. 클라이언트와 서버 설정이 일치하지 않으면 일반적으로 데이터 교환을 정상적으로 완료할 수 없습니다.
• VMess 및 VLESS: UUID, Transport, TLS, Host, Path와 SNI를 확인하세요. WebSocket 경로 또는 Host가 잘못되면 handshake에 영향을 줍니다.
• Trojan: 비밀번호, TLS와 SNI를 중점적으로 확인하세요. 인증서 이름과 대상 이름이 일치하지 않으면 Log에서 TLS 관련 오류를 확인할 수 있습니다.
• Hysteria2: 패킷 손실이 큰 네트워크에서의 성능은 대역폭, 혼잡 제어와 서버 측 제한에 영향을 받습니다. 서버 설정과 분리해 대역폭 설정만 임의로 입력하지 마세요.
• WireGuard: 공개 키, 개인 키, Address, Endpoint와 Allowed IPs를 확인하세요. 작은 요청은 정상인데 큰 전송이 멈춘다면 서비스 제공업체가 허용한 범위에서 MTU를 비교할 수 있습니다. 예를 들어 1280, 1380, 1420을 차례로 테스트하되 매번 값 하나만 바꾸세요.

MTU는 작을수록 좋은 것이 아닙니다. 너무 크면 일부 경로에서 조각화되거나 폐기될 수 있고, 너무 작으면 패킷 하나에 담기는 유효 데이터가 줄어 추가 오버헤드가 늘어납니다. MTU를 테스트할 때는 같은 노드와 같은 전송 작업을 사용하고 매번 변경한 뒤 다시 연결하세요. 서비스 제공업체가 값을 명확히 지정했다면 해당 값을 우선 유지하세요.

On Demand는 네트워크 조건에 따라 연결을 자동으로 수립하는 기능이며 속도 측정 가속 스위치가 아닙니다. 점검 중 연결이 자동으로 끊기거나 전환된다면 Settings → On Demand에서 SSID, 도메인 또는 네트워크 상태를 기준으로 기존 규칙이 작동하는지 잠시 확인하세요. 원래 설정을 기록한 뒤 조정하고, 테스트가 끝나면 실제 사용 방식에 맞게 복원하세요.

5단계: Log로 연결의 어느 단계가 느린지 확인

Log의 가치는 막연히 “빠름” 또는 “느림”을 표시하는 데 있지 않고 요청이 거친 단계를 펼쳐 보여주는 데 있습니다. Settings → Log로 들어가 기존 기록을 지운 상태에서 문제를 한 번 재현한 다음 시간순으로 DNS, 연결, TLS, 규칙 매칭과 재시도 정보를 확인하세요. 한 번의 재현 기록만 남기면 많은 과거 기록 속에서 검색하는 것보다 위치를 찾기 쉽습니다.

같은 도메인이 짧은 시간에 반복해서 해석된 뒤에야 연결이 수립된다면 DNS를 확인하세요. TCP 수립 후 TLS handshake에서 오랫동안 멈춘다면 시스템 시간, SNI, TLS 설정과 원격 응답을 중점적으로 확인합니다. 연결은 빠르게 수립되지만 전송 중 timeout 또는 retry가 연속으로 발생한다면 패킷 손실, 혼잡 또는 원격 부하 문제에 가깝습니다.

Log를 읽을 때는 마지막 한 줄만 잘라 보지 말고 시간 관계를 확인해야 합니다. 예를 들어 DNS에 20 ms, 연결 수립에 70 ms가 걸렸지만 TLS 단계에서 수초를 기다렸다면 병목은 도메인 해석이 아닙니다. 반대로 연결 전에 DNS timeout이 반복되었다면 노드를 바꿔도 문제가 해결되지 않을 수 있습니다.

1. 기존 기록 정리

   Settings → Log를 열고 이번 테스트와 관계없는 과거 기록을 먼저 정리하세요.

2. 문제 한 번 재현

   대상 앱 또는 웹페이지로 돌아가 느려짐을 안정적으로 재현하는 동작을 한 번만 실행하세요.

3. 첫 요청 찾기

   도메인, 대상 주소 또는 시간으로 요청 시작점을 찾아 어떤 규칙과 정책에 매칭되었는지 확인하세요.

4. 대기 단계 확인

   DNS, 연결 수립, TLS와 데이터 전송 사이의 시간 간격을 비교해 가장 오래 멈춘 구간을 찾으세요.

5. 단일 변수로 재측정

   네트워크, 노드 또는 설정 하나만 바꾼 뒤 다시 재현하세요. 해당 오류가 사라지면 문제 범위를 좁힐 수 있습니다.

자주 발생하는 속도 문제의 빠른 판단

위 단계별 점검을 마치면 현상 조합으로 문제를 빠르게 분류할 수 있습니다. 분류의 목적은 즉시 공통 설정을 제시하는 것이 아니라 다음에 어디를 수정할지 결정하는 데 있습니다. 사용자가 보유한 서비스의 실제 노드 상태, 포트와 전송 설정은 본인의 서비스 제공업체 자료를 기준으로 하세요.