· 문제 해결 · 약 12분

Shadowrocket 속도 느림 해결 방법: Wi-Fi·셀룰러 네트워크, 프로토콜, 경로 및 노드 점검

속도 저하 원인을 로컬 Wi-Fi·셀룰러 네트워크, 프로토콜·전송 설정, 경로 품질, 노드 부하로 나눠 확인하세요. Shadowrocket의 Connectivity Test를 활용해 병목 구간을 찾아보세요.

이 글의 핵심

Shadowrocket 연결 속도는 요청이 지나가는 전체 경로에 따라 달라집니다. Connectivity Test의 지연 시간이 짧다고 다운로드 속도가 빠른 것은 아닙니다. 이미 이용 중인 서비스와 구독이 있고 연결은 되지만 접속이 느려진 사용자를 위해 로컬 네트워크, 라우팅·프로토콜, 경로 품질, 노드 부하를 차례로 비교합니다. 한 번에 조건 하나만 바꾸고 결과를 기록한 뒤 설정을 유지할지 원래대로 돌릴지 결정하세요. 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다.

1. 지연 시간, 처리량, 연결 실패 구분하기

‘속도가 느리다’는 현상은 크게 세 가지입니다. 웹페이지를 열 때 오래 기다리는 경우, 파일 다운로드 속도가 계속 낮은 경우, 연결 상태가 불안정한 경우입니다. 첫 번째는 DNS 조회, 연결 설정 또는 원격 서버 응답과 관련될 수 있고, 두 번째는 지속 처리량 문제에 가깝습니다. 세 번째라면 패킷 손실, 네트워크 전환, 연결 끊김을 확인해야 합니다. 프로토콜을 바로 바꾸기보다 먼저 어떤 현상인지 구체적으로 파악하세요.

로컬 네트워크 라우팅 판단 프로토콜 연결 원격 출구 대상 사이트

이 흐름은 진단을 위한 논리적 구분이며, 패킷이 항상 이 순서로 처리된다는 뜻은 아닙니다. DNS 조회는 여러 단계에서 이뤄질 수 있습니다. Home의 Connectivity Test는 테스트 대상에 연결할 수 있는지 확인하고 해당 테스트 방식의 소요 시간을 참고하는 기능입니다. 파일 다운로드 테스트를 대신하거나 모든 사이트와 전송 방식이 정상임을 보장하지는 않습니다.

단위에 유의하세요. 8 Mbps는 약 1 MB/s입니다. 비트와 바이트의 환산값이며 프로토콜 오버헤드는 포함하지 않습니다. 속도 측정 페이지의 Mbps와 다운로드 화면의 MB/s를 그대로 비교하면 정상적인 차이를 속도 저하로 오해할 수 있습니다.

2. 로컬 Wi-Fi와 셀룰러 네트워크 기준값 측정하기

먼저 기기에서 인터넷까지 기본 연결이 정상인지 확인한 다음 프록시 경로를 살펴보세요. 현재 네트워크에서 직접 접속할 수 있는 사이트를 기준 대상으로 선택하세요. 원래 프록시가 필요한 사이트를 직접 연결 비교에 사용하지 마세요. 테스트 중에는 다른 기기의 대용량 전송을 중단하고 여러 속도 측정 작업을 동시에 실행하지 마세요.

  1. 현재 설정 기록

    Home에서 현재 선택된 노드와 Global Routing 모드를 기록하고, Config에서 사용 중인 구성 파일을 확인하세요. 이후 조건을 하나씩만 바꾸면 같은 기준으로 되돌아가 비교할 수 있습니다.

  2. 자동 연결 일시 중지

    Settings → On Demand를 확인하세요. 자동 연결 조건이 설정되어 있다면 먼저 기록한 뒤 해당 스위치를 잠시 끄세요. 그런 다음 Home으로 돌아가 연결 스위치를 끄고 테스트 중 연결이 다시 설정되지 않는지 확인하세요.

  3. 직접 연결 측정

    Wi-Fi에서 기준 대상에 접속해 페이지가 열리는 시간, 지속 다운로드 속도, 연결 중단 여부를 기록하세요. 세 번 연속 측정하고 가장 빠른 결과 하나만 고르지 말고 세 결과를 모두 남기세요.

  4. 네트워크 전환

    Wi-Fi를 끄고 기기가 셀룰러 네트워크를 사용 중인지 확인한 뒤 같은 대상에 같은 방식으로 다시 접속하세요. 데이터 사용량에 유의하고 네트워크를 전환하는 동시에 시간을 측정하지 마세요.

  5. 연결 복원

    Home으로 돌아가 원래 노드를 선택하고 연결을 켜세요. 먼저 Connectivity Test를 실행한 다음 같은 대상에 접속해 테스트하세요. 모든 비교가 끝나면 On Demand 설정을 원래대로 복원하세요.

연결을 끈 상태에서도 Wi-Fi가 느리고 셀룰러 네트워크는 정상이라면 무선 신호, 라우터 업로드 대역폭 사용량, 로컬 네트워크 품질을 먼저 확인하세요. 두 네트워크 모두 직접 연결은 정상인데 같은 노드를 켰을 때 한쪽만 느려진다면 접속 네트워크에서 해당 노드까지의 경로 차이를 더 살펴볼 필요가 있습니다. 이것만으로 노드 부하가 원인이라고 단정할 수는 없습니다.

3. Global Routing과 실제 적용된 규칙 확인하기

연결 후 속도가 느리다고 해서 트래픽이 선택한 노드를 실제로 통과한다고 단정할 수는 없습니다. Home → Global Routing에서 라우팅 모드를 정하며, Config의 규칙은 해당 모드에서만 트래픽 분기에 적용됩니다. 현재 모드를 먼저 확인한 다음 규칙을 살펴보세요. 현재 적용되지 않는 구성을 수정하지 않도록 주의하세요.

모드확인 목적주의 사항
Proxy프록시 경로를 비교하고 트래픽 분기 규칙의 영향을 줄입니다.짧은 시간만 테스트하고 완료 후 원래 모드로 복원하세요.
Direct직접 연결했을 때의 접속 결과를 확인합니다.시스템의 VPN 연결을 끄는 것과 같지 않으며, 연결을 끊은 기준 테스트를 대신할 수 없습니다.
Config현재 구성의 규칙에 따라 정책을 결정합니다.현재 구성, 규칙 적용 순서, 최종 정책을 확인하세요.
Scene설정된 Scene에 따라 관련 라우팅 동작을 결정합니다.네트워크가 바뀌면서 테스트 조건이 달라지지 않도록 실제로 실행된 Scene을 먼저 확인하세요.

아래는 규칙 문법을 보여 주는 예시일 뿐, 기존 구성을 덮어쓰라는 뜻이 아닙니다. DOMAIN-SUFFIX는 도메인과 하위 도메인을 매칭하고, IP-CIDR은 IPv4 대역을 매칭합니다. GEOIP는 IP 주소의 지역 데이터베이스를 기준으로 판단하며, FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 규칙은 순서대로 적용되므로 범위가 넓은 규칙을 앞에 두면 뒤쪽의 세부 규칙이 적용되지 않을 수 있습니다.

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

4. 프로토콜 매개변수를 먼저 확인하고 임의로 바꾸지 않기

Home에서 기존 노드의 편집 화면을 열고 Type, 서버 주소, 포트, 인증 정보를 확인하세요. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard의 매개변수는 서로 바꿔 쓸 수 없습니다. 프로토콜은 원격 설정과 일치해야 하며, 속도를 비교하려고 Type만 바꾸면 안 됩니다.

예를 들어 기존 설정에 포트 443이 지정되어 있다면 원격 서버가 실제로 어떤 전송 방식을 사용하는지 먼저 확인하세요. TCP 443에 연결할 수 있다고 해서 UDP 443도 연결 가능한 것은 아닙니다. 포트 번호가 같아도 프로토콜이 같다는 뜻은 아닙니다. Hysteria2는 QUIC 기반으로 UDP를 사용하며 WireGuard도 UDP를 사용하므로, 네트워크에서 UDP가 제한되면 연결이나 지속 전송에 영향을 받을 수 있습니다.

5. 비교 결과로 경로 품질과 노드 부하 구분하기

경로 품질과 노드 부하 모두 저녁 시간대 속도 저하로 나타날 수 있으므로 시간대만으로 원인을 판단할 수 없습니다. 대상 사이트를 그대로 유지하고 먼저 노드를 고정한 채 접속 네트워크를 바꿔 보세요. 다음으로 접속 네트워크를 고정한 채 사용자가 이미 보유한 다른 노드와 비교하세요. 각 조건에서 세 번 이상 측정하고 측정 간격을 두어 동시에 실행한 테스트끼리 대역폭을 나눠 쓰지 않도록 하세요.

관찰 결과우선 의심할 원인다음 확인 항목
같은 노드가 Wi-Fi에서만 느림로컬 무선 환경 또는 해당 접속 네트워크에서 원격 서버까지의 경로입니다.라우터 가까이에서 다시 측정하고 셀룰러 네트워크 결과와 비교하세요.
두 네트워크 모두 같은 노드에서 느리지만 다른 기존 노드는 정상해당 노드의 진입 경로, 출구 또는 리소스 제한입니다.대상 사이트 두 곳에서 테스트하고 시간대별 결과를 비교하세요.
모든 노드에서 같은 사이트가 느림대상 사이트, 리소스 서버 또는 공통으로 거치는 경로입니다.노드를 그대로 두고 별도의 다른 대상에서 테스트하세요.
Connectivity Test는 정상이지만 지속 다운로드가 느림처리량 제한, 패킷 손실, 원격 속도 제한 또는 대상 서버의 응답 성능입니다.테스트 소요 시간만 비교하지 말고 지속 속도를 기록하세요.
시간 초과가 잦고 결과 편차가 큼무선 간섭, 혼잡, 패킷 손실 또는 원격 서버 불안정입니다.먼저 로컬 직접 연결 결과를 비교한 다음 노드 경로를 확인하세요.

지연 시간이 짧다는 것은 짧은 요청의 왕복 시간이나 연결 설정 시간이 짧다는 뜻일 뿐입니다. 대역폭, 패킷 손실률, 동시 연결 제한으로 대용량 파일 전송이 느려질 수 있습니다. 반대로 거리가 먼 노드의 지연 시간이 높아도 지속 다운로드 속도가 반드시 낮은 것은 아닙니다. 대상, 시간, 네트워크 조건을 통제하지 않은 속도 측정 화면 두 장만으로 특정 프로토콜이 더 빠르다고 증명할 수는 없습니다.

혼잡 시간대에만 속도가 뚜렷하게 떨어지고 로컬 직접 연결은 정상이라면 현상, 시간대, 접속 네트워크, 개인정보를 가린 테스트 결과를 이용 중인 서비스 제공업체에 전달해 확인하세요. 노드의 CPU, 출구 대역폭, 연결 수는 원격 지표이므로 클라이언트에서 확인한 지연 시간만으로 추정할 수 없습니다.

6. 오류가 발생하면 메시지 유형부터 확인하기

아래는 네트워크 연결 진단에서 표시될 수 있는 일반 오류 문자열입니다. 실제 표시 내용은 요청 기록을 기준으로 확인하세요. 테스트마다 같은 문구가 나타나는 것은 아닙니다. 오류는 실패가 발생한 단계를 설명할 뿐 원격 문제의 최종 원인을 확정하지 않습니다. 연결을 반복해서 껐다 켜기보다 오류 원문과 발생 시각을 기록하는 편이 진단에 유용합니다.

오류: i/o timeout

원인 및 해결: 지정된 시간 안에 관련 네트워크 읽기·쓰기가 완료되지 않은 상태입니다. 경로 단절, 패킷 손실, 원격 서버 무응답 등이 원인일 수 있습니다. 노드를 고정하고 Wi-Fi와 셀룰러 네트워크를 바꿔 비교한 뒤 원격 주소, 포트, 해당 전송 방식을 확인하세요. 시간 초과를 곧바로 대역폭 부족으로 판단하지 마세요.

오류: connection refused

원인 및 해결: 연결 요청이 명시적으로 거부된 상태입니다. 대상 포트에서 해당 서비스가 수신 대기 중이지 않거나 중간 장비가 연결을 차단한 경우가 흔합니다. 기존 구성의 주소와 포트를 확인하고 이용 중인 서비스 제공업체에 서버의 수신 상태를 문의하세요. 일반적으로 MTU를 조정해도 이 오류는 해결되지 않습니다.

오류: no such host

원인 및 해결: 현재 이름 조회 과정에서 필요한 도메인 레코드를 가져오지 못한 상태입니다. 도메인을 잘못 입력했거나 DNS 환경에 문제가 있을 수 있습니다. 서버 도메인의 철자를 확인하고 접속 네트워크를 바꿔 다시 테스트한 다음 현재 구성의 DNS 설정을 점검하세요. 확인되지 않은 IP 주소를 장기간 고정해서 사용하지 마세요.

오류는 없고 속도만 낮다면 존재하지 않는 오류 메시지를 찾기보다 지속 처리량을 비교하세요. 기록을 공유하기 전에 비밀번호, Private Key, 인증 token, 구독 주소를 가리세요. 프로토콜 유형, 개인정보를 가린 대상, 포트, 네트워크 유형, 시간만 남겨도 현상을 설명하는 데 대체로 충분합니다.

7. 자주 묻는 질문과 점검 마무리

지연 시간이 수십 ms에 불과한데 다운로드는 왜 느린가요?

Connectivity Test와 지속 다운로드는 측정하는 항목이 다릅니다. Home에서 같은 노드를 유지하고 대상 파일을 고정해 최소 30초 동안 속도를 확인하세요. Mbps와 MB/s를 혼동하지 않았는지도 살펴보세요. 다른 대상에서도 다시 측정해 특정 사이트의 속도 제한인지 경로 처리량 문제인지 구분하세요.

Proxy로 바꾸면 정상인데 Config에서는 왜 멈추나요?

먼저 Home → Global Routing에서 두 번의 테스트에 같은 모드가 적용됐는지 확인하세요. 그런 다음 Config에서 현재 구성의 DOMAIN-SUFFIX, IP-CIDR, GEOIP, FINAL 규칙 순서를 살펴보세요. 요청 기록에서 실제 적용된 정책을 확인하고 규칙을 전부 삭제하지 마세요.

네트워크를 전환한 뒤 멈추면 기기를 계속 재시작해야 하나요?

새 네트워크가 안정될 때까지 기다린 다음 Home에서 연결을 껐다가 다시 켜 새 경로로 연결을 설정하세요. Settings → On Demand가 예상하지 못한 자동 연결을 실행했는지도 확인하세요. 재현 조건이 명확해진 뒤에 네트워크 전환과 관련된 문제인지 판단하세요.

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

그렇다고 보장할 수 없습니다. 먼저 원격 서버가 해당 프로토콜을 지원하고 매개변수가 모두 올바른지 확인한 다음 현재 네트워크에서 필요한 UDP 트래픽을 전송할 수 있는지 살펴보세요. 진입 경로와 출구가 달라지면 추가 변수가 생기므로 대상, 접속 네트워크, 테스트 시간대를 최대한 동일하게 유지하세요. 프로토콜 이름만으로 속도를 판단해서는 안 됩니다.

점검을 마친 뒤 어떤 설정을 복원해야 하나요?

Global Routing, 현재 구성, On Demand 설정을 원래대로 복원하세요. 개선되지 않은 MTU 또는 DNS 변경은 되돌리세요. 마지막으로 평소 사용하는 앱에서 다시 테스트하고 효과가 있었던 변경 사항과 결과를 기록해 임시 테스트 설정이 남지 않도록 하세요.

점검은 ‘로컬 직접 연결은 정상이고 같은 노드는 특정 접속 네트워크에서만 지속 다운로드 속도가 느리다’처럼 재현하고 확인할 수 있는 결론을 내리는 데서 마무리해야 합니다. ‘클라이언트가 느리다’처럼 막연하게 판단하지 마세요. 결론을 기록하고 해당 단계만 확인해야 불필요한 설정 변경을 줄일 수 있습니다.

App Store 정품 확인