Shadowrocket 속도 느릴 때 해결 방법: 노드·회선·프로토콜·로컬 네트워크 점검

이 글의 핵심

이 글은 자체 서비스와 구독을 보유하고 있으며 연결은 되지만 접속이 느린 사용자를 위한 안내입니다. 먼저 앱과 테스트 조건을 확인한 뒤 노드, 회선, 프로토콜, 로컬 네트워크를 차례로 점검하며 한 번에 한 가지 조건만 바꿔 비교합니다. 마지막으로 규칙과 연결 기록을 확인해 지연 시간, 전송 속도, 웹페이지 최초 로딩 시간을 서로 다른 지표로 구분합니다.

1. 기준선 설정: 어떤 종류의 속도 저하인지 구분하기

Shadowrocket은 App Store에서 구입하는 Apple 플랫폼용 유료 앱으로, 한 번 구매하면 이용할 수 있습니다. 정품 여부를 확인할 때는 공식 아이콘, 개발자 Shadow Launch Technology Limited, 앱 ID 932747118을 함께 확인하세요. 호환 기기와 시스템 요구 사항은 App Store 페이지 표기를 기준으로 합니다. 앱 구매와 사용자가 별도로 보유한 연결 서비스는 서로 다른 항목이며, 앱을 구입해도 회선 대역폭이 달라지지는 않습니다.

점검을 시작하기 전에 Config에서 현재 설정을 복사해 저장하고, Home에서 선택한 노드와 Global Routing의 현재 모드를 기록하세요. 웹페이지가 처음 열릴 때 느린 현상은 DNS, 연결 설정, 대상 사이트의 응답 속도와 관련될 수 있습니다. 전송 내내 느리다면 처리량 문제일 가능성이 크고, 속도가 들쭉날쭉하다면 혼잡, 무선 간섭, 연결 재설정 여부를 살펴봐야 합니다. 처음부터 노드와 프로토콜을 바꾸고 DNS까지 수정하지 마세요.

4개 계층

노드 상태, 회선 품질, 프로토콜 설정, 로컬 네트워크

4가지 모드

Global Routing：Proxy / Direct / Config / Scene

3회

각 조건에서 최소 세 번 테스트해 한 번의 결과에 의존하지 마세요.

평소 사용하는 웹페이지 하나와 정상적으로 접근할 수 있는 대용량 파일 하나를 정해 첫 로딩과 연속 전송을 각각 확인하세요.
기기, 대상, 노드, 테스트 시간을 동일하게 유지하고 다른 기기의 대용량 작업은 일시 중지하세요. 한 번에 하나씩 테스트합니다.
테스트 시간, 네트워크 유형, 연결 성공 여부, 첫 로딩 시간, 안정화된 후의 전송 속도를 기록하세요. 기록은 실제 기기에서 측정한 값을 사용하고 노드 이름에 적힌 홍보 수치는 기준으로 삼지 마세요.
단위에 유의하세요. MB/s와 Mbps는 다르며 1 MB/s는 8 Mbps입니다. 비교하기 전에 단위를 통일하세요.

2. 노드 상태: 연결이 제대로 설정되는지 먼저 확인하기

Home에서 현재 사용하는 노드를 선택한 뒤 Connectivity Test를 실행하세요. 테스트 성공은 해당 테스트 방식으로 지정된 대상에 한 차례 연결을 확인했다는 뜻입니다. 모든 웹사이트에 접속할 수 있거나 지속적인 전송 대역폭이 충분하다는 의미는 아닙니다. 테스트 방식이 다르면 결과 수치를 직접 비교하기 어렵고, 한 번의 낮은 지연 시간만으로 빠른 속도를 보장할 수도 없습니다.

현재 노드에서 테스트가 반복해 실패하면 주소, 포트, 계정 인증 정보, 서비스 유효 상태부터 확인하세요. 그런 다음 기존 설정에 있는 다른 사용 가능한 노드를 선택해 비교합니다. 구독을 성공적으로 가져왔다는 것은 앱이 내용을 받아 파싱했다는 뜻일 뿐, 모든 연결이 정상이라는 의미는 아닙니다. 업데이트가 필요하다면 Home에서 해당 구독을 업데이트한 뒤 노드 설정이 실제로 바뀌었는지 확인하세요. 기존에 사용 가능한 항목은 삭제하지 마세요.

오류: `Connection refused`

원인: 연결 요청이 거부된 경우입니다. 대상 포트에서 서비스가 대기 중이지 않거나 중간 장비가 연결을 차단할 때 흔히 발생합니다. 해결: 자체 서비스 설정에서 주소와 포트를 확인한 뒤 서비스 관리 담당자에게 포트가 정상적으로 열려 있는지 점검해 달라고 요청하세요. 속도 테스트 대상을 바꾸는 것만으로는 포트 거부 문제를 해결할 수 없습니다.

오류: `Operation timed out`

원인: 정해진 시간 안에 네트워크 작업이 완료되지 않은 상태입니다. 네트워크에 접근할 수 없거나, 패킷 손실이 발생했거나, 서비스가 응답하지 않는 경우일 수 있습니다. 해결: 같은 노드를 유지한 채 Wi-Fi와 Cellular를 바꿔 비교한 다음, 기존에 보유한 다른 노드로 다시 테스트해 로컬 네트워크와 원격 서비스 중 어느 쪽의 문제인지 차례로 확인하세요.

위 오류 문구는 네트워크 진단에서 흔히 볼 수 있으며, 로그 출처에 따라 표시 내용이 달라질 수 있습니다. 오류를 기록할 때는 발생 시간, 대상, 작업 단계를 함께 남기세요. “VPN에 연결됨”은 시스템 터널이 설정되었다는 의미일 뿐, 프록시 서버와 대상 사이트 간 통신까지 정상이라는 뜻은 아닙니다.

3. 회선 품질: 지연 시간·패킷 손실·전송 속도를 나눠 살펴보기

노드의 진입 주소가 같아도 시간대에 따라 실제 경로와 부하가 달라질 수 있습니다. 저녁 시간대의 혼잡, 무선 패킷 손실, 원격 출구 서버의 부하, 대상 사이트의 속도 제한 때문에 연결 테스트는 정상이면서 파일 전송은 느릴 수 있습니다. 같은 대상을 반복 테스트한 결과를 함께 살펴보고 가장 좋았던 한 번의 결과만 남기지 마세요.

관찰되는 증상	우선 의심할 원인	다음 비교 방법
첫 로딩은 느리지만 전송이 시작되면 안정적	DNS, 연결 설정 또는 대상 사이트 응답	첫 접속과 재접속의 차이를 기록한 뒤 연결 기록을 확인하세요.
여러 대상에서 전송 속도가 계속 느림	공용 회선 또는 노드 출구 병목	네트워크는 그대로 두고 기존의 다른 노드로 같은 작업을 반복하세요.
특정 대상 하나만 느림	대상 사이트, 콘텐츠 전송 네트워크 또는 특정 경로	먼저 해당 도메인에 실제로 적용된 정책을 확인하고 전체 설정은 바로 수정하지 마세요.
특정 시간대에 유독 느림	시간대별 혼잡 또는 부하	조건을 동일하게 유지하고 두 시간대에 각각 기록한 뒤 서비스 관리 담당자와 비교하세요.

네트워크 진단 도구로 패킷 손실을 확인할 때는 탐지 방식을 함께 명시하세요. 일부 서버는 ICMP 응답을 제한하므로 ICMP 테스트에서 확인한 패킷 손실이 실제 서비스 데이터의 손실과 같다고 볼 수 없습니다. 실제 연결 시간 초과, 전송 중단, 재시도 현상도 함께 확인해야 하며, 손실률 하나만으로 회선 상태를 단정해서는 안 됩니다.

정리: 느린 구간을 먼저 찾고 연결 설정을 조정하세요

같은 네트워크에서 특정 대상만 느리다면 해당 대상의 규칙과 경로부터 확인하세요. 여러 대상이 모두 느리고 기존의 다른 노드로 바꾼 뒤 정상으로 돌아왔다면 로컬 DNS를 계속 수정하기보다 원래 노드와 회선의 비교 기록을 우선 전달하세요.

4. 프로토콜 설정: 이름으로 속도를 짐작하지 말고 서버 요구 사항 확인하기

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 설정과 전송 방식이 서로 다릅니다. 프로토콜을 바꾸려면 해당 프로토콜에 맞는 서버 설정이 필요합니다. 같은 주소의 유형만 다른 프로토콜로 바꾼다고 정상적으로 작동하는 것은 아닙니다. 서버 포트는 자체 서비스 설정에 따라 결정됩니다. 포트가 443이더라도 프로토콜, TLS, 인증 설정이 올바르다는 뜻은 아닙니다.

Shadowsocks: 암호화 방식, 비밀번호, 필요한 플러그인 설정을 확인하세요. 인증 정보가 일치하지 않으면 우선 연결이 되지 않을 수 있으며, 이를 속도 최적화 설정으로 볼 수는 없습니다.
VMess / VLESS: 사용자 식별자와 전송 설정을 확인하세요. WebSocket을 사용하는 경우 경로와 관련 Host 설정도 확인하고, TLS를 사용한다면 서버 이름을 점검하세요.
Trojan: 비밀번호, TLS 서버 이름, 인증서 유효성을 확인하세요. 인증서 검증을 끄는 것을 일반적인 속도 개선 방법으로 사용하지 마세요.
Hysteria2: QUIC 기반 전송을 사용하므로 현재 네트워크에서 해당 UDP 통신을 허용해야 합니다. TCP 테스트가 성공했다고 해서 이 연결 조건까지 충족되는 것은 아닙니다.
WireGuard: 키, Endpoint, 주소, 라우팅 범위를 확인하세요. 경로 MTU 문제가 있다는 명확한 근거가 있을 때만 설정 관리 담당자의 안내에 따라 MTU를 조정하세요.

설정을 변경하기 전에 기존 값을 기록하고 한 번에 한 항목만 수정한 뒤 기준 테스트를 반복하세요. 동시 연결 수를 무작정 늘리거나 실제 회선 용량보다 훨씬 큰 대역폭 값을 입력하고 MTU를 계속 바꾸지 마세요. 대기열, 패킷 손실, 연결 문제를 새로 일으킬 수 있습니다. 구독 업데이트가 노드 설정을 덮어쓸 수 있으므로 수정한 값이 유지되는지도 먼저 확인하세요.

5. 로컬 네트워크: 같은 노드로 Wi-Fi와 Cellular 비교하기

노드, 설정, 대상을 그대로 두고 로컬 네트워크만 바꾸면 무선 환경과 원격 서비스 중 어느 쪽에 원인이 있는지 직접 비교할 수 있습니다. Wi-Fi 신호 막대만으로는 간섭, 백홀 혼잡, 라우터 부하를 모두 알 수 없습니다. 셀룰러 네트워크도 위치, 커버리지, 시간대에 따라 달라집니다. 셀룰러로 테스트하기 전에 데이터 요금제를 확인하고 동일한 크기의 테스트 작업을 사용하세요.

Wi-Fi에서 같은 테스트를 세 번 진행하고 다른 기기의 업로드, 동영상 재생, 시스템 동기화가 함께 실행 중이었는지 기록하세요.
Wi-Fi를 끄고 Cellular로 전환된 것을 확인한 뒤 연결이 안정될 때까지 기다렸다가 테스트하세요. 네트워크 전환 중 잠시 발생한 재연결을 지속적인 속도 저하로 기록하지 않도록 합니다.
Wi-Fi에서만 느리다면 라우터 가까이에서 다시 테스트하고 다른 기기가 업로드 대역폭을 모두 사용 중인지 확인하세요. 가능하다면 서로 다른 무선 주파수 대역도 비교하세요.
두 네트워크에서 모두 느리다면 같은 노드와 규칙을 사용 중인지 확인한 뒤 노드와 회선 계층으로 돌아가 원인을 찾으세요.

6. 규칙 확인: 트래픽이 예상한 경로를 통과하는지 점검하기

Global Routing에서 Proxy는 현재 프록시 정책을 통해 트래픽을 보내고, Direct는 직접 연결하며, Config는 현재 설정의 규칙에 따라 처리하고, Scene은 설정된 장면에 따라 처리합니다. 점검할 때는 Home의 연결 스위치만 보지 말고 현재 모드를 기록하세요. Config에서 파일을 선택했더라도 실제로 Config 모드로 작동 중인지 확인해야 합니다.

앱 요청시스템 터널규칙 매칭정책에 따른 연결대상 응답

아래는 규칙 적용 순서를 이해하기 위한 최소 예시이며, 일반적인 속도 향상 설정이 아닙니다. example.com은 예시 도메인이고 192.0.2.0/24는 문서용 예시 네트워크 대역이므로 실제 서비스 대상에 그대로 사용하면 안 됩니다. 기존 설정에 적용하기 전에 어떤 대상에 DIRECT를 사용할지, 어떤 대상에 PROXY를 사용할지 먼저 정하세요.

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

DOMAIN-SUFFIX는 지정된 도메인 접미사와 그 하위 도메인을 매칭합니다. 앞에 있는 도메인 규칙이 이미 적용되면 일반적으로 뒤의 규칙은 해당 요청의 정책을 결정하지 않습니다.
IP-CIDR은 주소 네트워크 대역을 기준으로 매칭합니다. no-resolve는 이 규칙 때문에 도메인을 직접 조회하지 않도록 하는 옵션이며 앱 전체의 DNS를 끄는 설정은 아닙니다.
GEOIP는 IP 주소의 지역 정보를 담은 데이터베이스를 사용하므로 특정 도메인과 실제 연결 대상 확인을 대신할 수 없습니다.
FINAL은 앞선 규칙이 하나도 일치하지 않을 때 적용되는 기본 규칙이므로 규칙 목록의 맨 끝에 둡니다. FINAL만 수정해도 이미 일치한 앞선 규칙에는 영향을 주지 않습니다.

연결 기록을 열고 방금 테스트한 대상을 찾아 도메인, 적용된 규칙, 최종 정책을 확인하세요. 잠시 Proxy로 바꿔 비교했을 때 정상으로 돌아왔지만 Config에서는 여전히 느리다면 규칙, 정책 선택, DNS 관련 설정을 우선 확인하세요. 이 결과는 원인 범위를 좁히는 데 도움이 될 뿐 설정 전체를 교체해야 한다는 증거는 아닙니다. 비교가 끝나면 Global Routing을 기존 모드로 복원하세요.

7. 자주 묻는 질문과 문제 해결 기록 전달

지연 시간은 매우 낮은데 동영상은 왜 끊기나요?

지연 시간 테스트와 동영상의 지속적인 전송은 부하 조건이 다릅니다. 동영상 화질을 고정하고 버퍼링이 계속되는지 확인한 뒤 다른 대상과 비교하세요. 해당 동영상 도메인이 실제로 DIRECT와 PROXY 중 어느 경로를 사용하는지도 확인해야 합니다. 노드 테스트 결과를 실제 서비스 테스트 대신 사용하지 마세요.

구독을 업데이트한 뒤 느려졌는데 노드를 전부 삭제해야 하나요?

먼저 기존 설정과 사용 가능한 항목을 보존하고 업데이트 후 주소, 포트, 프로토콜, 현재 선택된 노드를 확인하세요. 노드가 바뀌었는지 확인한 다음 같은 대상으로 다시 테스트합니다. 항목을 삭제하면 비교 조건만 잃게 되며 원격 회선의 혼잡도 해결되지 않습니다.

Wi-Fi에서 셀룰러로 바꿀 때마다 잠시 기다려야 하는데 속도 문제인가요?

먼저 네트워크 전환에 따른 재연결과 안정된 상태의 전송을 구분하세요. Settings → On Demand의 작동 조건을 확인하고 연결이 안정된 뒤 시간을 측정합니다. 안정된 후 정상 속도로 돌아온다면 지속적인 전송 속도 문제와 구분해 재연결 현상을 기록하세요.

자체 서비스 관리 담당자에게 어떤 정보를 전달해야 하나요?

발생 시간과 시간대, 네트워크 유형, 노드 식별 정보, 대상, 오류 원문, 한 번에 한 조건씩 바꿔 비교한 결과를 전달하세요. 구독 token, 비밀번호, 개인 키, 전체 인증 링크는 가리고 필요한 진단 정보만 공유해 공개된 대화에서 인증 정보가 노출되지 않도록 하세요.

마무리할 때 테스트 전의 Config, Global Routing, On Demand 설정을 복원하고 자주 사용하는 대상에 다시 접속해 보세요. 어떤 조건을 바꿨는지, 증상이 반복해서 나타나는지, 원래 값으로 되돌린 뒤 다시 느려졌는지를 간단히 기록해 두세요. 한 번 찍은 속도 화면보다 반복해서 확인할 수 있는 차이가 문제 원인을 찾는 데 더 도움이 됩니다. 규칙 문법은 설정 전체 안내에서, 용어는 용어 설명에서 확인할 수 있습니다.