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

핵심 내용

Shadowrocket 속도가 느리다면 먼저 테스트 대상과 Global Routing을 고정한 뒤, 사용 중인 노드의 연결 상태를 확인하고 경로, 프로토콜 설정, Wi‑Fi와 셀룰러 네트워크를 비교하세요. 기존 서비스와 구독을 이용 중이며 연결은 되지만 응답이 느리거나 전송이 불안정한 경우에 적합합니다. 한 번 측정한 지연 시간만으로 모든 설정을 바꾸기보다 재현 가능한 비교 기록을 남기세요.

시작하기 전에: 테스트 조건을 고정하고 지연 시간과 처리량 구분하기

먼저 알아둘 점은 Connectivity Test 결과가 다운로드 속도와 같지 않다는 것입니다. 지연 시간은 테스트 요청이 완료되는 데 걸린 시간을 나타내며, 지속적인 전송 속도에는 가용 대역폭, 패킷 손실, 혼잡, 대상 서버의 속도 제한 등이 영향을 줍니다. 테스트 응답이 빠른 노드도 대용량 파일 전송은 느릴 수 있고, 특정 웹페이지가 늦게 열린다고 해서 연결 전체가 느리다고 단정할 수는 없습니다.

Home에서 현재 선택된 노드와 Global Routing을 기록하세요. 기존에 Config를 사용했다면 비교 기준으로 설정을 유지하고, 규칙의 영향을 분리해야 할 때만 잠시 Proxy로 전환하세요. 테스트 요청이 선택한 노드를 실제로 통과하는지도 확인해야 합니다. Scene은 장면 선택과 관련되므로 이번 비교에서는 변경하지 마세요. Direct는 프록시 경로의 속도를 나타내는 기준으로 사용할 수 없습니다.

평소 이용하는 동일한 대상을 정하고 첫 접속, 재접속, 지속 전송을 각각 확인하세요. 서로 다른 사이트를 같은 대상으로 간주해 비교하지 마세요.
다른 기기에서 대용량 전송 작업을 일시 중지하고 테스트 시간, 네트워크 유형, 노드 이름, Global Routing, 시간 초과 여부를 기록하세요.
각 조건에서 3회 반복해 결과 또는 중앙값을 기록하세요. 가장 빠른 결과만 남기지 마세요.
한 번에 변수 하나만 변경하고, 변경 후 연결을 새로 설정해 테스트하세요. 테스트가 끝나면 기존 Global Routing 설정을 복원하세요.

4개 계층

노드, 경로, 프로토콜, 로컬 네트워크 순으로 문제를 좁히세요

3회

조건별 권장 반복 테스트 횟수

1개

비교할 때마다 변수 하나만 변경

첫 번째 계층: 노드를 사용할 수 있는지, 테스트 응답만 정상인지 확인

Home에서 현재 노드의 Connectivity Test를 실행한 다음 실제 요청으로 확인하세요. 테스트 성공은 해당 테스트 조건에서 연결할 수 있다는 뜻일 뿐입니다. 실패하면 서버에 연결할 수 없는 경우, 인증 오류, 테스트 대상에 접근할 수 없는 경우를 구분해야 합니다. 노드 진단을 대신해 구독을 계속 새로고침하지 마세요. 목록을 갱신해도 원격 서버의 부하나 경로 혼잡은 해결되지 않습니다.

노드 주소, 포트, 프로토콜, 인증 항목이 기존에 받은 정보와 일치하는지 확인하세요. 포트는 서비스 제공자가 안내한 실제 값을 사용해야 합니다. 흔히 쓰이는 443이 보이더라도 다른 포트를 임의로 바꾸면 안 됩니다.
같은 네트워크와 Global Routing을 유지한 채 기존 목록의 다른 노드를 선택해 동일한 요청을 반복하세요. 변수를 줄이려면 우선 같은 프로토콜을 사용하는 항목을 선택하세요.
특정 노드 하나만 계속 실패한다면 테스트 시간과 오류를 기록하세요. 모든 노드가 느리다면 공통 경로, 로컬 네트워크, 테스트 대상을 추가로 확인하세요.
노드 정보가 변경됐을 가능성이 있다면 기존 Subscribe 업데이트 기능을 한 번 실행한 뒤 현재 선택된 항목을 확인하세요. 구독 업데이트가 성공했다고 노드 연결까지 확인된 것은 아닙니다.

아래는 연결 로그에서 흔히 볼 수 있는 오류 문구입니다. 실제 문구는 프로토콜과 하위 연결 방식에 따라 달라질 수 있습니다. 오류는 원인을 단정하는 근거가 아니라 문제를 좁히기 위한 단서입니다. 도메인 확인, 연결 수립, 전송 중 어느 단계에서 발생했는지도 함께 살펴보세요.

오류: `connection refused`

원인: 대상 포트에서 수신 대기 중인 서비스가 없거나 중간 장비가 연결을 거부했을 수 있습니다.

해결: 먼저 기존 노드의 주소와 포트를 확인한 뒤, 발생 시간을 서비스 제공자에게 전달해 서버 상태를 문의하세요.

오류: `i/o timeout`

원인: 제한 시간 안에 연결 또는 읽기·쓰기가 완료되지 않았습니다. 패킷 손실, 혼잡, 원격 서버 무응답 등이 원인일 수 있습니다.

해결: 같은 노드를 유지한 채 네트워크를 바꿔 다시 테스트하고, 기존의 다른 노드와 비교하세요. 원인을 곧바로 프로토콜 탓으로 돌리지 마세요.

오류: `no such host`

원인: 현재 이름 확인 과정에서 필요한 호스트 이름을 확인하지 못했습니다.

해결: 호스트 이름의 철자와 DNS 설정을 확인하고, 노드 도메인과 접속 대상 도메인 중 어느 쪽에서 문제가 발생했는지 구분하세요.

두 번째 계층: 경로 혼잡과 규칙 분기 구분하기

노드는 연결의 원격 진입점이며, 경로에는 로컬 접속, 통신사 네트워크 경로, 노드 출구, 출구에서 대상 사이트까지의 경로가 포함됩니다. 이름이 다른 두 노드도 경로 일부를 공유할 수 있습니다. 따라서 노드를 바꿨는데도 느리다는 사실만으로 경로 문제를 배제할 수는 없습니다. 반대로 한 대상의 테스트가 정상이라고 해서 모든 대상이 정상이라고 볼 수도 없습니다.

비교 조건	관찰된 현상	다음 단계
같은 노드와 네트워크, 다른 시간대	혼잡 시간대에는 지속 전송이 뚜렷하게 느려지고 다른 시간대에는 회복됨	여러 시간대의 결과를 기록해 반복되는 혼잡 패턴이 있는지 확인
같은 노드와 네트워크, 다른 대상	특정 사이트만 느리고 다른 대상은 정상	해당 대상에 적용되는 규칙, 이름 확인, 원격 응답 점검
같은 노드와 대상에서 Config와 Proxy 비교	Proxy에서는 정상인데 Config에서는 느리거나 실패함	Config에서 현재 설정과 실제로 적용된 규칙 확인
같은 노드와 대상에서 Wi‑Fi와 셀룰러 네트워크 비교	한 가지 접속 방식에서만 느림	로컬 네트워크와 접속 경로 점검

Config는 현재 설정의 규칙에 따라 요청 경로를 결정합니다. Proxy는 프록시 모드와 비교할 때 사용할 수 있지만, 실제 요청 기록을 확인해야 합니다. 규칙은 순서대로 일치 여부를 확인하므로 앞선 규칙이 뒤쪽 규칙의 적용을 막을 수 있습니다. 아래는 문법 관계를 보여 주는 예시일 뿐, 기존 설정을 그대로 대체할 수 있는 완전한 파일이 아니며 모든 대상에 적합한 정책을 뜻하지도 않습니다.

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

DOMAIN-SUFFIX는 도메인 접미사로 일치 항목을 찾고, IP-CIDR은 IP 대역을 기준으로 일치 항목을 찾습니다. GEOIP는 IP 지리 정보에 따라 일치 여부를 판단하며, FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 요청이 실제로 DIRECT를 사용했다면 프록시 노드의 지연 시간을 계속 측정해도 해당 요청이 느린 이유를 설명할 수 없습니다. 먼저 적용된 규칙을 확인하세요.

결론: 요청 경로를 확인한 뒤 경로 성능을 비교하세요

같은 대상이 Proxy에서는 정상인데 Config에서는 계속 느리다면 먼저 현재 설정의 적용 규칙과 DNS 결과를 확인하세요. 두 요청이 같은 경로를 사용한다는 점을 확인한 뒤 노드 또는 경로 차이를 판단하세요.

세 번째 계층: 프로토콜을 바꾸기보다 설정값을 먼저 확인하세요

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 전송 및 인증 방식이 서로 다르므로 노드의 프로토콜 이름만 바꾼다고 전환이 완료되는 것은 아닙니다. 각 연결에는 이를 지원하는 서버와 완전한 설정값이 필요합니다. 이미 보유했고 사용 가능 여부를 확인한 설정끼리만 비교하세요. 두 설정이 서로 다른 서버를 사용한다면 측정 차이를 전부 프로토콜 탓으로 돌릴 수 없습니다.

Shadowsocks: 암호화 방식과 비밀번호를 확인하세요. 플러그인을 사용하는 경우 서버에서 요구하는 플러그인과 매개변수도 확인해야 합니다.
VMess／VLESS: 사용자 식별 정보, 전송 방식, TLS 등의 설정을 확인하세요. WebSocket이나 gRPC를 사용하는 경우 경로 또는 서비스 이름도 서버 설정과 일치해야 합니다.
Trojan: 비밀번호와 TLS 서버 이름을 확인하세요. 인증서 검증에 실패하면 시간, 도메인, 인증서 체인을 점검하고, 속도를 높이기 위해 검증을 끄지 마세요.
Hysteria2: QUIC 기반이며 UDP 경로를 사용할 수 있어야 합니다. 현재 네트워크에서 UDP를 제한하면 핸드셰이크에 실패하거나 연결이 불안정할 수 있습니다. 모든 네트워크에서 더 빠르다고 단정할 수는 없습니다.
WireGuard: UDP를 사용하므로 키, 엔드포인트, 라우팅 관련 설정을 확인해야 합니다. 작은 요청은 정상인데 대용량 전송이 멈춘다면 MTU를 점검 항목에 포함할 수 있지만, 먼저 패킷 손실과 서버 문제를 배제하세요.

앱 요청 규칙 일치 프로토콜 핸드셰이크 원격 전달 대상 응답

이 과정은 “연결 스위치가 켜져 있음”과 “대상 콘텐츠가 안정적으로 전송됨”이 서로 다른 상태임을 보여 줍니다. 핸드셰이크에 문제가 있다면 먼저 인증, TLS, 하위 전송 방식을 확인하세요. 핸드셰이크가 끝난 뒤 전송이 느려진다면 패킷 손실, 혼잡, 원격 서버 부하, 대상 응답을 확인하세요. MTU, DNS, 프로토콜, 노드를 한꺼번에 바꾸면 문제가 해결되더라도 어떤 변경이 효과가 있었는지 알 수 없습니다.

네 번째 계층: Wi‑Fi, 셀룰러 네트워크, DNS 로컬 점검

같은 노드와 대상을 유지하면서 Wi‑Fi와 셀룰러 네트워크를 차례로 테스트하면 로컬 접속 환경의 차이를 직접 비교할 수 있습니다. 전환하기 전에 데이터 사용량을 확인하고, 전환 후에는 네트워크가 안정될 때까지 기다렸다가 연결을 새로 설정하세요. 두 네트워크의 결과가 다르면 접속 환경이나 경로에 차이가 있다는 뜻이지만, 라우터, 통신사, 노드 중 어느 한쪽이 원인이라고 단정할 수는 없습니다.

기본 접속 확인: Shadowrocket 연결을 잠시 끊고 원래 직접 접속할 수 있는 일반적인 페이지를 열어 보세요. 기본 접속도 느리다면 먼저 로컬 네트워크를 점검하세요. 원래 직접 접속할 수 없는 대상을 이 단계의 테스트에 사용하면 안 됩니다.
Wi‑Fi 환경 점검: 라우터 가까이에서 다시 테스트하고, 로컬 네트워크의 대용량 전송 작업을 일시 중지하세요. 공용 Wi‑Fi의 인증 페이지도 완료했는지 확인하세요. 신호 막대 수만으로 가용 대역폭을 알 수는 없습니다.
이름 확인과 전송 구분: 처음 페이지를 열 때 오래 기다리지만 이후 콘텐츠 전송은 정상이라면 DNS 요청이 시간 초과되거나 반복 재시도되는지 확인하세요. 이 현상만으로 모든 DNS 설정을 바로 바꾸지는 마세요.
자동 연결 간섭 확인: Settings → On Demand에서 기존 조건을 확인하고 네트워크 전환 시 재연결이 실행되는지 살펴보세요. 수동 테스트의 기준을 만들려면 원래 설정을 기록한 뒤 On Demand를 잠시 끄고 테스트한 다음 복원하세요.
IPv6 정보 기록: 특정 네트워크에서만 문제가 발생한다면 DNS 결과에 IPv6 주소가 포함되는지, 관련 연결이 실패하는지 기록하세요. 비교 결과 없이 IPv6 비활성화를 일반적인 해결책으로 삼지 마세요.

DNS 변경은 이름이 확인되는 방식과 이후 사용할 수 있는 주소에 영향을 주며, 경로 대역폭을 직접 늘리지는 않습니다. 다운로드 연결이 이미 수립된 상태에서 계속 느리다면 DNS를 반복해서 바꿔도 대역폭 병목이 어디인지 파악하기 어렵습니다. 반대로 요청이 이름 확인 단계에서 멈춘다면 프로토콜 매개변수보다 확인 결과와 요청 경로를 먼저 살펴보세요.

자주 묻는 질문: 지연 시간이 낮은데 느린 경우, 구독 업데이트, 저녁 시간대 속도 저하

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

지연 시간 테스트와 지속 전송 측정은 서로 다른 항목을 확인합니다. 같은 노드와 대상을 유지해 지속 전송을 반복 측정하고, 전송 시작 후 몇 초가 지나 속도가 떨어지는지 기록하세요. 그런 다음 다른 대상과 비교해 경로 혼잡과 대상 서버의 속도 제한을 구분하세요.

Subscribe를 업데이트하면 기존 노드가 빨라지나요?

업데이트는 기존 구독에서 변경된 주소나 설정을 동기화할 수 있지만 현재 경로의 대역폭을 늘려 주지는 않습니다. 노드 정보가 만료됐거나 변경됐다고 의심될 때만 업데이트하세요. 이후 Home에서 실제 선택된 노드를 확인하고 다시 테스트해야 합니다.

왜 저녁에만 느리고 낮에는 정상인가요?

같은 노드, 네트워크, 대상을 유지해 여러 시간대의 결과를 기록하고 가정 내 대용량 네트워크 작업도 배제하세요. 차이가 반복된다면 시간대, 실패 비율, 동일 조건의 비교 결과를 서비스 제공자에게 전달하세요. 한 번의 테스트만으로 원인을 단정하지 마세요.

모든 노드가 느린데 Shadowrocket 설정 문제인가요?

반드시 그렇지는 않습니다. Wi‑Fi, 접속 경로, DNS, 규칙, 테스트 대상도 공통 원인일 수 있습니다. 먼저 Wi‑Fi와 셀룰러 네트워크를 비교하고, 다음으로 Config와 Proxy를 비교하세요. 어떤 변수에 따라 문제가 달라지는지 확인한 뒤 관련 설정만 점검하세요.

결과 정리: 재현 가능한 기록으로 점검 마무리하기

네 계층을 점검하는 목적은 문제 범위를 좁히는 것이지 모든 옵션을 처음부터 다시 설정하는 것이 아닙니다. 비교를 마친 뒤 기존 Global Routing과 On Demand 설정을 복원하세요. 근거가 확인되지 않은 변경 사항도 원래대로 돌려놓으세요. 서비스 제공자의 도움이 필요하다면 필요한 현상과 연결 정보만 전달하고, 전체 구독 링크, 비밀번호, 개인 키, 인증 토큰은 공개하지 마세요.

환경: iPhone 또는 iPad, Wi‑Fi 또는 셀룰러 네트워크, 발생 시간과 지속 시간.
연결: 선택한 노드의 식별용 이름, 프로토콜, Global Routing, 같은 대상을 사용해 재테스트했는지 여부.
결과: 3회 테스트의 원본 기록, 실제 접속 현상, 오류 문구, 다른 네트워크 또는 기존의 다른 노드와 비교한 결과.
수행한 작업: 변경한 설정과 복원 여부를 항목별로 기록해 다음 점검을 확인된 상태에서 시작할 수 있도록 하세요.

결론: ‘느림’을 재현 가능한 조건으로 기록하세요

“같은 노드에서 Wi‑Fi로 세 번 연속 시간 초과가 발생했고, 셀룰러 네트워크로 전환한 뒤에는 세 번 모두 성공”이라고 기록하면 단순히 “속도가 느림”이라고 쓰는 것보다 다음 점검 지점을 찾는 데 도움이 됩니다. 이 결과는 접속 경로를 확인해야 한다는 단서이지만 추가 검증의 여지는 남아 있습니다.