Shadowrocket 속도 느림 해결 방법: 노드·경로·프로토콜·로컬 네트워크 점검

이 글의 핵심 내용

이 글은 Shadowrocket에서 연결은 되지만 웹페이지 로딩이 느리거나, 동영상이 버퍼링되거나, 다운로드 속도가 불안정한 경우에 적용할 수 있습니다. 사용 중인 서비스와 구독을 기준으로 테스트 대상을 고정하고 라우팅을 확인한 뒤 노드, 경로, 프로토콜, 로컬 네트워크 순으로 비교합니다. 한 번에 조건 하나만 바꿔 재현 가능한 증상과 해결 방향을 파악하세요. 지연 시간 테스트 한 번만으로 모든 설정을 바꾸는 것은 피해야 합니다.

1. 먼저 속도가 느린 구간을 구분하세요

연결 스위치가 켜져 있어도 모든 요청이 프록시를 거치는 것은 아니며, 프록시 출구의 대역폭이 충분하다는 뜻도 아닙니다. 웹페이지 첫 화면 로딩 지연, 동영상 재생 중 반복되는 버퍼링, 계속 낮은 다운로드 속도는 각각 DNS, 연결 수립, 지속 전송 속도와 관련될 수 있습니다. 먼저 구체적인 증상을 기록해야 이후 비교가 의미 있습니다.

앱 요청 규칙 매칭 노드 연결 경로 전송 대상 응답

이 흐름은 점검할 위치를 보여 주며, 모든 프로토콜의 내부 처리 순서가 동일하다는 뜻은 아닙니다. DNS는 규칙 판정과 대상 주소 확인에 관여할 수 있고, 캐시 때문에 첫 방문과 재방문의 소요 시간도 달라질 수 있습니다. 특정 웹사이트의 응답이 느리다고 해서 프록시 경로 전체가 느리다고 단정하지 마세요.

접근 권한이 있고 콘텐츠가 비교적 안정적인 웹페이지나 다운로드 대상을 하나 선택하세요. 모든 비교에서 동일한 대상을 사용하고, 서로 다른 웹사이트의 속도 측정 결과를 비교하지 마세요.
현재 시각, 로컬 네트워크 유형, 노드 이름, 프로토콜, Global Routing 상태와 증상을 기록하세요. 기록에는 노드 이름 대신 A, B와 같은 표기를 사용할 수 있습니다.
시스템 업데이트, 클라우드 드라이브 동기화와 기타 대용량 작업을 일시 중지하고 같은 작업을 연속 세 번 수행하세요. 첫 화면이 뜨기까지 걸린 시간, 전송 속도, 연결 중단 여부를 각각 기록합니다.
첫 실행과 반복 방문을 구분하세요. 첫 번째 주소 확인과 핸드셰이크는 느리지만 두 번째 방문은 눈에 띄게 빨라지는 경우와 지속 전송 속도가 계속 낮은 경우는 서로 다른 문제입니다.

4개 계층

노드, 경로, 프로토콜, 로컬 네트워크를 나눠 점검

3회

각 비교 테스트의 반복 횟수입니다. 이 글에서 권장하는 작업 기준입니다.

÷ 8

추가 오버헤드를 제외한 Mbps와 MB/s의 이론적 환산 관계

예를 들어 80 Mbps는 이론상 약 10 MB/s입니다. 이는 단위 환산 예시일 뿐, Shadowrocket의 실제 측정 속도나 성능을 보장하는 값이 아닙니다. 지연 시간은 응답을 기다리는 시간이고 다운로드 속도는 단위 시간당 전송되는 데이터 양이므로 서로 직접 환산할 수 없습니다.

2. 먼저 라우팅과 연결 상태를 확인하세요

Home에서 현재 선택된 노드와 연결 스위치를 확인한 뒤 Global Routing을 살펴보세요. Proxy는 프록시 대상 트래픽을 프록시 정책으로 보내고, Direct는 직접 연결하며, Config는 설정의 규칙에 따라 트래픽을 나눕니다. Scene은 시나리오 설정에 따라 동작합니다. 문제를 점검할 때는 대상 요청이 실제로 어떤 경로를 거치는지 확인해야 합니다. 상태 표시줄 아이콘만으로 판단하지 마세요.

Config: Config에서 현재 사용 중인 설정을 열고 규칙 순서와 적용되는 정책을 확인하세요. 노드를 선택했더라도 해당 도메인이 반드시 그 노드를 사용하는 것은 아닙니다.
Proxy: 짧은 비교 테스트에서 대상이 프록시 경로를 사용할 때 개선되는지 확인할 수 있습니다. 테스트가 끝나면 다른 앱의 접속 경로가 바뀌지 않도록 기존 Global Routing 설정으로 되돌리세요.
Direct: 로컬 네트워크에서 대상에 직접 연결했을 때의 상태를 비교하는 데 사용합니다. 대상에 직접 연결할 수 없다면 실패했다는 사실만으로 로컬 인터넷 속도가 낮다고 볼 수 없습니다.
Scene: 먼저 현재 적용 중인 시나리오 조건과 라우팅 동작을 확인하세요. 변수를 줄이려면 비교 테스트 동안 명확한 Config 또는 Proxy 상태를 임시로 사용할 수 있습니다.

다음은 규칙 구문 예시이며 기존 설정을 그대로 대체할 수 있는 완성 파일이 아닙니다. 여기서 example.com은 예시 도메인이고, PROXY는 실제로 사용할 수 있는 프록시 정책과 연결되어 있어야 합니다. 규칙은 일반적으로 순서대로 매칭되며, FINAL은 마지막에 두어 기본 처리에 사용합니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

DOMAIN-SUFFIX는 도메인 접미사로, IP-CIDR은 IP 주소 대역으로, GEOIP는 IP 지리 정보 데이터로 매칭합니다. 대상이 실수로 DIRECT에 매칭된다면 프로토콜을 바꾸기보다 먼저 규칙을 수정하세요. Proxy는 정상인데 Config에서만 느리다면 규칙, DNS, 정책 선택을 우선 확인합니다. 라우팅에 관한 자세한 내용은 프록시 모드를 참고하세요.

3. 노드 계층: 사용 가능 여부와 부하 징후 확인

노드는 현재 설정에 등록된 특정 서버 진입점을 뜻합니다. 노드의 지연 시간이 낮다는 것은 특정 조건에서 테스트 요청의 왕복 시간이 짧았다는 의미일 뿐입니다. 서버 출구의 혼잡, 계정 속도 제한, 대상 웹사이트의 출구 제한 여부는 측정되지 않습니다. 같은 노드에서 짧은 요청은 성공하지만 장시간 다운로드가 느려진다면 부하나 속도 제한 때문일 수도 있습니다.

Home에서 올바른 노드가 선택됐는지 확인하고 주소, 포트, 프로토콜 유형이 서비스 제공업체의 안내와 일치하는지 점검하세요. 포트를 일괄적으로 443으로 바꾸지 마세요. 서버가 실제로 해당 포트에서 연결을 받는 경우에만 사용할 수 있습니다.
이미 여러 노드를 사용 중이라면 로컬 네트워크, Global Routing, 테스트 대상을 동일하게 유지하고 노드 A와 B만 바꿔 세 차례 결과를 기록하세요.
사용 중인 구독의 트래픽과 유효 기간 정보를 확인하세요. Home에서 구독을 업데이트한 다음 노드 매개변수가 달라졌는지 살펴보세요. 구독과 노드는 서비스 제공업체를 통해 이용합니다.
특정 진입점 하나에서만 문제가 계속될 때는 노드 표기, 장애 시각, 오류 내용을 서비스 제공업체에 전달하세요. 여러 진입점이 출구나 중계 경로를 공유한다면 완전히 독립적인 비교 대상으로 간주하지 마세요.

결론: 먼저 문제가 있는 지점을 찾고 설정을 조정하세요

같은 네트워크와 대상을 사용했을 때 노드 A에서만 문제가 지속되고 노드 B는 정상이라면, 먼저 A의 오류 기록을 저장하고 서비스 상태를 확인하세요. 이때 DNS, MTU 또는 모든 프로토콜 매개변수를 한꺼번에 바꾸면 이미 확보한 비교 조건이 무너집니다.

4. 경로 계층: 시간대와 네트워크 경로 비교

경로는 기기에서 진입점까지, 진입점에서 출구까지, 출구에서 대상까지 데이터가 이동하는 구간입니다. 노드 이름에 표시된 지역만으로 전체 경로를 알 수 없으며, 지연 시간이 낮거나 대역폭이 높다고 단정할 수도 없습니다. 같은 진입점이 저녁에 느려지고 비혼잡 시간대에 회복된다면 공유 링크 혼잡과 관련이 있을 수 있지만, 이 현상만으로 어느 네트워크 구간이 원인인지 단정할 수는 없습니다.

비교 조건	구체적인 작업	범위를 좁힐 수 있는 문제
같은 노드, 다른 시간대	오전과 저녁에 각각 세 번씩 결과를 저장하고 대상과 로컬 네트워크는 동일하게 유지합니다.	특정 시간대에 반복적으로 혼잡이 발생하는지 확인합니다.
같은 노드, 다른 접속 네트워크	Wi-Fi와 셀룰러 네트워크를 전환한 뒤 연결을 다시 설정합니다.	로컬 접속 또는 통신사 경로의 차이를 확인합니다.
같은 네트워크, 다른 대상	노드는 그대로 두고 기존 테스트 대상 두 곳에 각각 접속합니다.	전반적인 전송 문제와 특정 대상의 응답 문제를 구분합니다.
같은 대상, 기존에 사용 중인 다른 진입점	프로토콜과 라우팅은 바꾸지 말고 노드만 전환합니다.	문제가 특정 진입점이나 공유 경로와 관련 있는지 확인합니다.

신뢰할 수 있는 패킷 손실 테스트 조건이 있다면 ICMP 탐지와 실제 서비스 트래픽을 구분하세요. 중간 라우터가 탐지 응답을 제한할 수 있으므로, 특정 홉에서 손실률이 높게 표시되더라도 최종 대상이 정상이라면 서비스 트래픽도 같은 비율로 손실된다고 볼 수 없습니다. 더 유의미한 징후는 최종 대상에 계속 접속하지 못하는지, 전송이 반복해서 멈추는지, 같은 조건에서 이 현상이 재현되는지입니다.

한 번의 테스트에서 노드 변경, DNS 변경, 프로토콜 변경, 라우터 재시작을 모두 하지 마세요. 비교 한 세트를 마칠 때마다 기준 설정으로 복구한 뒤 다음 항목을 바꾸세요. 그렇지 않으면 속도가 회복되어도 어떤 조치가 효과가 있었는지 알 수 없습니다.

5. 프로토콜 계층: 이름보다 전송 조건 확인

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 서버 매개변수와 전송 조건이 서로 다릅니다. 프로토콜을 바꾼다는 것은 기존 노드의 유형 항목을 다른 이름으로 수정하는 것이 아닙니다. 사용 중인 서버가 해당 설정을 명시적으로 제공할 때만 유효한 비교를 할 수 있습니다.

Shadowsocks: 서버 주소, 포트, 암호화 방식, 비밀번호를 확인하세요. 매개변수가 맞지 않는 문제를 암호화 방식 변경으로 해결할 수는 없습니다.
VMess / VLESS: 인증 정보뿐 아니라 전송 방식과 관련 필드도 확인하세요. WebSocket을 사용하는 경우 Path와 Host가 서버 요구사항과 일치해야 합니다.
Trojan: 비밀번호와 TLS 서버 이름 등의 매개변수를 확인하세요. TLS 핸드셰이크 실패를 인증서 검증 요구사항을 낮춰 해결하려 해서는 안 됩니다.
Hysteria2: QUIC 기반으로 UDP 경로를 사용합니다. 지연 시간이 높거나 패킷 손실이 발생하는 일부 환경에 더 적합할 수 있지만, 네트워크에서 UDP가 제한되면 정상적인 연결을 수립하지 못할 수 있습니다.
WireGuard: UDP 기반입니다. Endpoint, 키, 서버 설정을 확인하세요. 터널은 연결되지만 일부 대용량 요청이 멈출 때에만 경로 MTU를 추가로 점검하세요. 임의의 MTU 값을 보편적인 속도 향상 설정으로 취급하지 마세요.

예를 들어 서버 설정이 UDP 443이라면 TCP 443에 접속할 수 있다는 사실만으로 Hysteria2를 사용할 수 있다고 판단할 수 없습니다. 포트 번호가 같아도 전송 계층은 다릅니다. TCP를 사용하는 서비스와 UDP를 사용하는 서비스도 같은 네트워크에서 서로 다른 결과를 보일 수 있습니다.

오류: connection refused

원인 및 해결: 대상 포트에서 연결을 명시적으로 거부했습니다. 포트가 잘못됐거나 서비스가 실행되지 않았거나 중간 장비가 연결을 거부했을 수 있습니다. 먼저 서비스 제공업체가 안내한 주소와 포트를 확인한 뒤 서비스 상태를 점검하세요. 반복해서 속도를 측정해도 연결 거부 문제는 해결되지 않습니다.

오류: i/o timeout

원인 및 해결: 네트워크 작업이 제한 시간 안에 완료되지 않았습니다. 주소 확인, 연결, 데이터 읽기 단계에서 발생할 수 있습니다. 오류가 발생한 상황을 확인하고 같은 노드에서 로컬 접속 네트워크를 바꿔 범위를 좁히세요. 곧바로 비밀번호 오류라고 단정하지 마세요.

오류: TLS handshake timeout

원인 및 해결: TLS 핸드셰이크가 제한 시간 안에 완료되지 않았습니다. 경로, 서버 부하, 핸드셰이크 매개변수와 관련 있을 수 있습니다. 먼저 시스템 시간, TLS 서버 이름, 서버 설정을 확인한 뒤 다른 로컬 네트워크에서도 문제가 발생하는지 비교하세요.

위 오류는 네트워크 진단에서 나타날 수 있는 원문 예시입니다. 실제 로그에는 접두어, 대상 주소 또는 더 자세한 원인이 포함될 수 있습니다. 오류 문구는 실패한 단계를 파악하는 데 활용할 수 있으며, 모든 플랫폼의 Shadowrocket에서 동일한 메시지가 표시된다는 뜻은 아닙니다.

6. 로컬 네트워크: Wi-Fi, DNS, 자동 연결 점검

로컬 네트워크 문제는 모든 노드에 영향을 줄 수 있습니다. 먼저 같은 기기에서 Wi-Fi와 셀룰러 네트워크를 비교한 뒤 라우터 점검 여부를 판단하세요. 한 기기에서만 문제가 발생한다면 네트워크 전체를 초기화하기보다 해당 기기의 다른 VPN, 필터링 도구, 절전 설정, 백그라운드 다운로드를 확인하세요.

Wi-Fi 신호와 혼잡 확인: 라우터 가까이에서 테스트를 반복하고, 가능하면 서로 다른 주파수 대역도 비교하세요. 주파수가 높은 대역이 모든 거리에서 더 빠른 것은 아니므로 같은 위치에서 실제 연결 안정성을 비교해야 합니다.
DNS 상태 확인: 주로 웹페이지를 처음 열 때 오래 기다리지만 이후 다운로드는 정상이라면 DNS 설정과 주소 확인 실패 기록을 점검하세요. 먼저 기존 설정을 저장한 뒤 시스템 DNS 또는 이미 사용 중인 사용자 지정 DNS와 비교하세요. 여러 DNS 옵션을 동시에 바꾸지 마세요.
시간과 네트워크 로그인 확인: 시스템 날짜와 시간이 정확한지, 공용 Wi-Fi 로그인을 완료했는지 확인하세요. 네트워크 로그인이 끝나지 않으면 모든 노드에서 연결 시간이 초과되거나 TLS 연결이 실패할 수 있습니다.
자동 재연결 확인: Settings → On Demand에서 자동 연결 조건이 설정되어 있는지 확인하세요. 비교를 위해 수동으로 연결을 끊었는데도 즉시 다시 연결되는 일이 없도록 확인한 뒤, 테스트가 끝나면 원래 설정으로 복구하세요.
기준 상태 다시 설정: Wi-Fi와 셀룰러 네트워크를 전환한 뒤 다시 연결하고 세 차례 비교 테스트를 시작하세요. 이전 연결이 끊겼다가 복구되는 시간을 안정적인 속도에 포함하지 않도록 주의하세요.

결론: 반복 재설치보다 네트워크 간 비교를 먼저 하세요

같은 기기, 노드, 대상에서 셀룰러 네트워크는 정상인데 Wi-Fi에서만 문제가 계속된다면 Wi-Fi 접속과 상위 경로를 우선 확인하세요. 라우터나 앱 설정을 변경하기 전에 두 네트워크의 차이를 보여 주는 기록을 보관하세요.

7. 자주 묻는 질문과 서비스 문의 기록

지연 시간이 수십 밀리초에 불과한데 동영상이 끊기는 이유는 무엇인가요?

지연 시간 테스트는 지속 대역폭 테스트와 다릅니다. 동영상과 화질을 하나로 고정하고 같은 노드에서 계속 재생해 본 뒤, 이미 사용 중인 다른 노드로 바꿔 비교하세요. 짧은 요청은 안정적이지만 장시간 전송이 반복해서 멈춘다면 전송량 변화와 발생 시간대를 중점적으로 기록하세요.

Hysteria2로 바꾸면 반드시 더 빨라지나요?

그렇지 않습니다. 먼저 서버가 Hysteria2 매개변수를 제공하는지, 로컬 네트워크에서 해당 UDP 경로를 사용할 수 있는지 확인한 뒤 동일한 대상과 시간대에 비교하세요. UDP 프로토콜만 실패하고 기존 TCP 전송 설정은 정상이라면 UDP 경로를 먼저 점검하세요. 대역폭 매개변수를 계속 늘리지는 마세요.

구독을 업데이트했는데도 느립니다. 계속 새로고침해야 하나요?

구독 업데이트는 설정을 동기화하는 기능이며 서버 대역폭을 직접 늘려 주지는 않습니다. 한 번 업데이트한 뒤 노드 주소, 포트, 프로토콜이 바뀌었는지 확인하고 동일한 대상을 테스트하세요. 매개변수에 변화가 없고 연결이 가능하다면 노드 부하, 경로, 로컬 네트워크를 점검하세요.

Config에서만 느리고 Proxy는 정상이라면 어디를 수정해야 하나요?

먼저 Config에서 대상에 적용되는 규칙과 정책을 확인하세요. 특히 앞부분의 DOMAIN-SUFFIX, GEOIP와 마지막의 FINAL을 살펴본 뒤 도메인 주소 확인이 규칙 매칭에 영향을 주는지 확인합니다. 모든 규칙을 바로 삭제하지 말고 백업한 다음 명확하게 잘못된 항목 하나만 수정하세요.

서비스 제공업체에 문의할 때는 모든 노드가 느리다고만 설명하는 것보다 최소한의 재현 조건을 전달하는 편이 도움이 됩니다. 구독 링크, 계정 키, 비밀번호는 공개 기록에 포함하지 마세요. 스크린샷이나 로그를 공유하기 전에 해당 정보를 가리세요.

발생 조건: 날짜, 정확한 시각과 시간대, Wi-Fi 또는 셀룰러 네트워크 여부, 특정 시간대에만 문제가 발생하는지 여부를 기록합니다.
설정 범위: 노드 표기, 프로토콜, Global Routing 상태, 사용 중인 설정을 기록합니다. 전체 구독 링크나 키는 제출하지 마세요.
재현 단계: 어떤 유형의 대상에 접속했는지, 얼마나 기다렸는지, 어느 단계에서 멈췄는지와 반복 작업 세 차례의 기록을 첨부합니다.
비교 결과: 노드를 바꾸면 개선되는지, 로컬 네트워크를 바꾸면 개선되는지, Direct 비교가 가능한 조건인지, 정확한 오류 원문을 기록합니다.

점검이 끝나면 임시로 변경한 Global Routing과 On Demand 설정을 복구하고, 문제를 안정적으로 재현할 수 있는 기록은 보관하세요. 원인을 찾지 못했다면 문제 해결 가이드에 따라 연결과 설정을 추가로 확인할 수 있습니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다. 관련 설정은 서비스 제공업체를 통해 이용하세요.