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

이 글 미리보기

Shadowrocket 연결 후의 지연 시간, 웹페이지 첫 로딩 시간, 지속 전송 속도는 서로 다른 지표입니다. 이미 이용 중인 서비스와 구독을 보유하고 설정을 가져왔지만 접속이 느려진 경우에 적합한 안내입니다. 먼저 테스트 조건을 고정한 뒤 노드, 경로, 프로토콜 설정, 로컬 네트워크를 차례로 확인하고 연결 기록으로 문제가 발생한 구간을 판단하세요.

1. 지연 시간, 첫 로딩 지연, 전송 속도 구분하기

Home의 Connectivity Test는 선택한 테스트 방식에 따른 연결 가능 여부와 응답 시간을 확인하는 기능이지, 경로의 대역폭을 증명하지는 않습니다. 테스트 주소나 방식, 실제 접속하는 웹사이트가 다르면 결과도 달라질 수 있습니다. 목록에서 지연 시간이 낮아도 동영상이 계속 원활하게 재생된다는 보장은 없으며, 대용량 파일 전송이 더 빠르다는 뜻도 아닙니다.

시작하기 전에 증상을 구체적으로 기록하세요. 모든 웹사이트가 느린지, 특정 도메인만 느린지, 처음 열 때 기다리는지, 로딩 중간에 멈추는지, 하루 종일 지속되는지 특정 시간대에만 나타나는지 확인합니다. 구독 업데이트, DNS 변경, 프로토콜 전환, 네트워크 변경을 한꺼번에 하지 마세요. 문제가 해결되더라도 어떤 조치가 효과가 있었는지 알 수 없습니다.

관찰된 증상	우선 확인할 항목	판단 시 유의점
처음 열 때는 느리지만 이후에는 정상	DNS, 연결 수립, TLS 핸드셰이크	캐시가 두 번째 결과에 영향을 줄 수 있음
페이지는 빠르게 뜨지만 대용량 파일은 느림	경로 처리량, 혼잡, 대상 서버의 속도 제한	낮은 지연 시간이 높은 대역폭을 뜻하지 않음
특정 웹사이트만 느림	해당 도메인에 적용된 규칙과 대상 서비스	이것만으로 노드 전체의 장애를 판단할 수 없음
모든 요청이 시간 초과됨	로컬 네트워크 연결, 노드 도달 가능성, 인증 설정	먼저 연결이 수립되는지 확인한 뒤 속도를 살펴보기

속도 단위도 맞춰야 합니다. 8 Mbps는 프로토콜 오버헤드를 제외하면 약 1 MB/s입니다. 한 페이지에는 Mbps, 다른 도구에는 MB/s로 표시된다면 숫자 크기를 그대로 비교할 수 없습니다. 이후 기록에는 단위, 테스트 시간, 대상을 함께 적으세요.

2. 테스트 기준을 고정하고 실제 경로 확인하기

Shadowrocket에서 Home은 연결 및 노드 선택, Config는 구성 파일, Settings는 앱 설정을 다룹니다. 속도 문제를 점검할 때는 먼저 현재 노드와 Global Routing을 확인한 뒤 적용 중인 구성을 살펴보세요. 시스템에 VPN 표시가 보인다는 것은 터널이 수립되었다는 뜻일 뿐, 모든 요청이 선택한 프록시 노드를 거친다는 의미는 아닙니다.

현재 상태 기록하기

Home에서 선택된 노드 이름과 현재 Global Routing 값을 기록하고, Config에서 사용 중인 구성 파일을 확인하세요. 필요한 원래 설정은 보관하되 기록에 비밀번호나 전체 구독 링크를 포함하지 마세요.
라우팅 모드 고정하기

Home → Global Routing으로 이동합니다. Proxy는 프록시 모드 비교에, Direct는 직접 연결 비교에 사용하고, Config는 구성에 따른 라우팅을 적용합니다. Scene을 사용 중이라면 해당 장면의 실제 정책을 먼저 확인하세요. 서로 다른 모드에서 얻은 결과를 같은 조건의 결과처럼 비교하지 마세요.
자동 연결 확인하기

Settings → On Demand에서 기존 조건을 확인하세요. 테스트 중 연결을 수동으로 끊어야 한다면 On Demand를 잠시 끄고 원래 값을 기록하세요. 설정된 조건에 따라 시스템이 다시 연결해 직접 연결 비교를 방해하는 일을 막을 수 있습니다.
같은 테스트 반복하기

Home에서 Connectivity Test를 실행하고 테스트 방식을 바꾸지 않은 채 결과를 세 차례 기록하세요. 그런 다음 같은 대상에 접속해 첫 로딩과 지속 전송을 각각 확인합니다. 대용량 작업을 여러 개 동시에 실행하지 마세요.
기존 설정 복원하기

비교 테스트를 한 차례 마칠 때마다 임시 변경 사항을 되돌리세요. 모든 테스트가 끝나면 원래 Global Routing, 구성 파일, On Demand 상태를 복원해 진단용 Proxy나 Direct 설정이 계속 남지 않도록 하세요.

3. 노드와 경로 점검하기: 한 번에 변수 하나만 변경

노드는 연결 종단점이며, 경로는 현재 네트워크에서 해당 종단점과 대상 서비스까지 이어지는 실제 전송 경로입니다. 노드 이름에 표시된 지역 정보만으로는 경로 전체나 현재 부하를 알 수 없습니다. 같은 노드도 가정용 인터넷과 셀룰러 네트워크에서 성능이 다른 경우가 많으며, 접속 네트워크, 경로 혼잡, UDP 사용 가능 여부가 원인일 수 있습니다.

기존 노드끼리만 비교: 같은 Wi‑Fi, 같은 Global Routing, 같은 대상을 유지하고 기존 노드 A를 기존 노드 B로 바꾸세요. 나머지 조건은 그대로 둔 채 연결 결과와 지속 전송 성능을 각각 기록합니다.
시간대도 고려: 저녁에만 느려진다면 다른 시간대에도 같은 테스트를 한 번 이상 반복하세요. 한 번의 결과만으로는 일시적인 혼잡과 지속적인 장애를 구분할 수 없습니다.
대상별 차이 확인: 같은 노드에서 다른 대상은 정상인데 특정 서비스만 느리다면 해당 대상의 규칙과 서비스 상태를 확인하세요. 노드 전체를 사용할 수 없다고 바로 판단하지 마세요.
구독 변경 여부 확인: Home에서 본인 구독을 아래로 당겨 새로고침한 뒤 현재 선택 항목을 다시 확인하세요. 구독 내용에 따라 주소, 포트 또는 항목이 바뀔 수 있으므로 이전 기록을 그대로 적용할 수 없습니다.

아래는 기록 형식의 예시이며, 이 사이트에서 측정한 데이터가 아닙니다. 같은 시간대에 같은 대상을 테스트했을 때 Wi‑Fi에서 노드 A의 응답 시간은 세 차례 80 ms / 85 ms / 82 ms였지만 전송 속도는 0.5 MB/s였습니다. 노드 B는 응답 시간이 120 ms / 125 ms / 122 ms였지만 전송 속도는 3 MB/s였습니다. 이처럼 응답 시간과 지속 처리량은 따로 판단해야 하며, 지연 시간이 가장 짧은 순서로만 정렬해서는 안 됩니다.

Wi‑Fi에서는 기존 노드가 모두 느리고 셀룰러 네트워크에서는 정상이라면 로컬 네트워크를 우선 점검하세요. 특정 노드 하나만 두 네트워크에서 모두 실패한다면 해당 종단점과 설정을 먼저 확인합니다. 이용 중인 서비스 제공자에게 문의할 때는 단순히 “느리다”고 하기보다 발생 시간, 접속 네트워크, 식별 정보를 가린 노드 정보, 오류 문구를 전달하면 원인 파악에 도움이 됩니다.

4. 프로토콜 설정 확인하기: 연결부터 정상화한 뒤 최적화 검토

Type을 임의로 바꿔 속도를 높이려 하지 마세요. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 서버 설정을 서로 공유할 수 없습니다. 서버가 실제로 지원하고 필요한 설정을 모두 제공한 프로토콜만 사용할 수 있습니다. 기존 항목의 프로토콜 이름을 다른 것으로 바꾸면 대개 연결이 끊깁니다.

프로토콜	중점 확인 항목	자주 하는 오해
Shadowsocks	주소, 포트, 암호화 방식, 비밀번호	인증 정보 불일치를 경로 속도 문제로 오해
VMess / VLESS	UUID, 전송 방식, TLS, Host, Path	전송 설정이나 경로가 맞지 않아 연결 수립 실패
Trojan	비밀번호, 포트, TLS, SNI	SNI 오류를 일반적인 시간 초과로 오해
Hysteria2	인증, TLS, SNI, UDP 도달 가능성	접속 네트워크에서 UDP를 제한해도 반복 재시도로 해결되지 않음
WireGuard	키, Endpoint, 주소, Allowed IPs, MTU	핸드셰이크는 확인되지만 라우팅이나 대용량 전송에 문제가 있음

포트는 기존 설정과 일치해야 합니다. 서버가 8443을 사용한다면 443이 흔한 포트라는 이유만으로 바꾸지 마세요. 포트 번호 자체가 속도 등급을 나타내지는 않습니다. TLS의 SNI와 인증서 검증도 서버 요구 사항에 맞춰 확인하고, 설정 오류를 감추려고 인증서 검증을 끄지 마세요.

Hysteria2와 WireGuard는 UDP에 의존합니다. 특정 Wi‑Fi에서 실패하지만 같은 항목이 셀룰러 네트워크에서는 정상이라면 프로토콜이 맞지 않는다고 단정하지 말고 먼저 네트워크 조건을 확인하세요. 모든 네트워크에 통하는 MTU “최적값”도 없습니다. 작은 요청은 되지만 대용량 전송이 멈추는 등 분명한 징후가 있을 때만 기존 설정 안내에 따라 변수 하나를 조정하고 원래 값을 보관하세요.

오류: connection refused

원인과 해결: 대상 서버나 중간 장비가 연결을 명시적으로 거부한 상태입니다. 포트에서 연결을 수신하지 않거나 접근 정책에 의해 차단되었을 수 있습니다. Address와 Port를 확인하고 이용 중인 서비스 제공자에게 종단점 상태를 문의하세요. DNS를 반복해서 바꿔도 포트 거부는 대개 해결되지 않습니다.

오류: i/o timeout

원인과 해결: 작업이 제한 시간 내에 완료되지 않았습니다. 연결 경로, 대상의 응답, UDP 도달 가능성이 원인일 수 있습니다. 오류가 발생한 연결 단계를 확인하고 같은 항목으로 Wi‑Fi와 셀룰러 네트워크를 비교하세요. timeout만 보고 비밀번호를 바꾸지 마세요.

오류: tls: handshake timeout

원인과 해결: TLS 핸드셰이크가 제시간에 완료되지 않았습니다. 네트워크 패킷 손실, 종단점 상태, 핸드셰이크 설정이 원인일 수 있습니다. 먼저 포트, TLS, SNI를 확인한 뒤 접속 네트워크별로 비교하세요. 인증서 검증을 끄는 것을 일반적인 해결책으로 삼지 마세요.

연결 기록에 다음과 같은 오류 문구가 나타날 수 있으며, 바깥쪽 안내 문구나 문맥은 다를 수 있습니다. 관련된 전체 행을 보관하고 연결 종단점 실패와 최종 대상 접속 실패를 구분하세요. 공유 전에 인증 정보, 구독 토큰, 불필요한 개인 접속 기록을 삭제하세요.

5. 로컬 네트워크, DNS, 규칙 적용 확인하기

로컬 네트워크는 변경을 최소화하는 것부터 점검하세요. 노드는 그대로 두고 같은 장소에서 Wi‑Fi와 셀룰러 네트워크를 비교한 다음, 같은 Wi‑Fi에 연결한 상태로 라우터 가까이 이동해 다시 테스트합니다. 공용 Wi‑Fi에서 웹페이지 인증이 필요하다면 먼저 네트워크에 로그인하세요. 약한 신호, 다른 기기의 업로드 사용, 라우터 혼잡 때문에 연결이 느려질 수 있으며 앱을 재설치해도 이런 문제는 해결되지 않습니다.

요청 시작규칙 매칭정책 선택아웃바운드 연결대상 응답

위 흐름은 문제 위치를 찾기 위한 단순화된 예시입니다. DNS 조회는 여러 단계에 관여할 수 있습니다. Global Routing이 Config라면 Config에서 현재 파일의 규칙 순서를 확인하고 연결 기록을 함께 살펴 실제로 적용된 정책을 확인하세요. 규칙은 일반적으로 위에서 아래로 검사하며, 먼저 일치하는 규칙이 이후 요청의 경로에 영향을 줍니다. 특정 웹사이트가 프록시를 거칠 것이라고 생각했지만 실제로는 Direct 규칙이 적용되는 경우가 흔한 테스트 오류입니다.

[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 대역을 매칭하며, 예시의 no-resolve는 해당 규칙을 위해 도메인을 조회하지 않는다는 뜻입니다. GEOIP는 IP 지리 데이터베이스를 기준으로 판단하고, FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. PROXY에 해당하는 정책도 실제 구성에 유효하게 정의되어 있어야 합니다.

도메인으로만 접속에 문제가 있음: DNS 조회가 실패하는지, 조회 결과가 현재 네트워크 환경에 맞는지 확인하세요. IP 주소를 직접 입력해 HTTPS 웹사이트에 접속하는 방법은 신뢰할 만한 대안이 아닙니다. 인증서와 가상 호스트 설정에서 도메인이 필요할 수 있습니다.
Config에서는 느리지만 Proxy에서는 정상: 노드를 바로 바꾸기보다 대상에 적용되는 규칙, DNS 경로, 정책 선택을 비교하세요.
모든 네트워크 작업이 느림: 기기 자체 또는 같은 네트워크의 다른 기기에서 시스템 업데이트나 클라우드 동기화 등 전송 작업이 동시에 진행되는지 확인한 뒤 다시 테스트하세요.
특정 무선 장소에서만 느림: 신호와 간섭을 우선 점검하세요. 주파수 대역을 바꾼 뒤 개선 여부를 판단하려면 대상과 노드를 그대로 유지해야 합니다.

6. 비교 결과를 바탕으로 원인 범위 좁히기

점검을 마친 뒤에는 임시 설정을 잔뜩 남기는 대신 문제를 설명할 수 있는 조건 하나로 범위를 좁혀야 합니다. 예를 들어 “같은 노드와 대상에서 집 Wi‑Fi를 사용할 때만 UDP 연결이 시간 초과됨”이라고 기록하면 “설정을 많이 바꿨는데도 느림”보다 다음 조치에 도움이 됩니다. 구성이 손상됐다는 근거가 없다면 구독을 삭제하거나 모든 규칙을 다시 만들 필요는 없습니다.

테스트 결과가 수십 ms인데 동영상은 왜 끊기나요?

Connectivity Test의 응답 시간은 동영상 대상에 대한 지속 처리량을 나타내지 않습니다. Home에서 노드를 그대로 유지하고 Global Routing과 해당 대상에 적용되는 규칙을 확인한 뒤 지속적으로 로딩되는 상태를 살펴보세요. 특정 서비스만 끊긴다면 해당 서비스로 향하는 경로와 서버의 속도 제한을 추가로 확인하세요.

셀룰러 네트워크로 바꾸자마자 왜 정상으로 돌아오나요?

같은 구성이 다른 접속 환경에서는 적어도 작동한다는 뜻입니다. 노드와 프로토콜 설정은 그대로 두고 Wi‑Fi로 돌아가 웹 인증, 신호, 동시 전송, UDP 사용 조건을 확인하세요. 구성을 한꺼번에 바꾸지 마세요.

구독을 업데이트한 뒤 갑자기 느려졌는데 삭제하고 다시 가져와야 하나요?

먼저 Home에서 현재 선택된 항목을 확인한 뒤 업데이트된 주소, 포트, 프로토콜 설정과 Global Routing이 원래 모드인지 점검하세요. 기존 항목이 바뀌었다면 변경 내용을 먼저 확인합니다. 삭제 후 다시 가져오면 직접 입력한 메모를 잃을 수 있지만 종단점 문제는 해결되지 않을 수 있습니다.

연결을 끊어도 매번 자동으로 다시 연결됩니다. 직접 연결 테스트는 어떻게 하나요?

먼저 Settings → On Demand에서 조건을 확인하고 잠시 끈 다음 수동으로 연결을 해제하세요. 로컬 네트워크 비교를 마치면 원래 값을 복원합니다. 자동 재연결을 연결 해제 조작이 실패한 것으로 오해하지 마세요.

문제를 문의할 때 어떤 기록을 첨부해야 하나요?

발생 시간, Wi‑Fi 또는 셀룰러 네트워크 여부, Global Routing, 식별 정보를 가린 노드 정보, 프로토콜 유형, Connectivity Test 결과 세 건과 관련 오류 행을 제공하세요. 전체 구독 URL, 비밀번호, UUID, 개인 키는 공개 문의에 포함하지 마세요.

마지막으로 진단 중 변경한 라우팅 모드, On Demand 및 기타 설정을 복원한 뒤 원래 대상에 다시 접속해 테스트하세요. 문제가 사라졌다면 효과가 있었던 변경 사항과 비교 기록을 보관합니다. 문제가 계속되면 이미 확인을 마친 구간을 정리한 뒤 종단점, 경로 또는 로컬 네트워크를 이어서 점검하세요.

구매 및 이용 범위

Shadowrocket은 오픈 소스가 아닌 유료 앱으로, 1회 구매 후 App Store에서 받을 수 있으며 주로 iPhone과 iPad에서 사용합니다. 시스템 요구 사항, 호환성, 구매 가능 범위는 App Store 페이지를 기준으로 확인하세요. 앱 구매는 네트워크 서비스 요금제와 별개입니다. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다. 앱의 정품 여부를 다시 확인하려면 정품 확인 안내를, 이미 앱을 보유한 경우 기본 연결 방법은 튜토리얼을 확인하세요.

정품 확인 안내 보기 사용법 보기