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

이 글의 핵심

지연 시간이 낮다고 전송 속도까지 정상인 것은 아닙니다. 먼저 테스트 대상을 고정하고, 처음 열 때만 느린지, 전송 내내 느린지, 간헐적으로 끊기는지 구분하세요. 그런 다음 로컬 네트워크, 사용 중인 노드, 노드까지의 경로, 프로토콜 설정, 규칙 적용 여부를 차례로 확인합니다. 이 글은 이미 이용 중인 서비스와 구독이 있는 사용자를 위한 안내입니다. 한 번에 한 가지 조건만 바꾸고 결과를 기록한 뒤 변경 사항을 유지할지 결정하세요.

먼저 구분하기: 지연 시간, 처리량, 첫 응답 시간

Shadowrocket의 연결 테스트는 특정 테스트 방식에서의 도달 가능성이나 응답 시간을 보여 줍니다. 지속적인 데이터 전송 테스트를 대신할 수는 없습니다. 연결은 빠르게 성립해도 이후 데이터 전송은 혼잡, 패킷 손실, 서버 부하, 대상 사이트의 제한 등에 영향을 받을 수 있습니다. 테스트 방식이 다르면 지연 시간도 직접 비교하기 어렵습니다.

평소 문제없이 이용하는 웹사이트 하나와 접근 권한이 있는 크기가 고정된 파일 하나를 선택하세요. 웹페이지는 첫 응답을, 파일은 지속적인 처리량을 확인하는 데 사용합니다. 서로 다른 사이트에서 얻은 결과를 같은 경로의 비교값으로 간주하지 말고, 여러 전송 작업을 동시에 실행하지 마세요.

관찰되는 증상	우선 확인할 항목	확인 방법
처음 열 때는 느리지만, 열린 뒤에는 정상	DNS, 연결 성립, 대상 서버 응답	같은 페이지를 처음 열 때와 다시 열 때 비교
파일 전송이 계속 느림	경로, 노드 부하, 대상 서버의 속도 제한	같은 파일을 30초 동안 연속으로 관찰
전송 속도가 오르내리거나 중간에 멈춤	패킷 손실, 무선 신호, 네트워크 혼잡	노드를 고정하고 Wi-Fi와 셀룰러 네트워크 비교
특정 사이트만 느림	사이트 자체 문제, 규칙, 대상 방향 경로	같은 노드로 다른 독립 사이트에 접속

단위에 유의하세요. Mbps는 초당 메가비트, MB/s는 초당 메가바이트입니다. 단위만 환산하면 8 Mbps = 1 MB/s입니다. 실제 전송에는 프로토콜 오버헤드도 포함됩니다. 예를 들어 “지연 시간 80 ms, 파일 전송 속도 0.5 MB/s”와 같이 기록할 수 있지만, 이 조합만으로 노드가 정상인지 판단할 수는 없습니다. 여기 제시한 숫자는 기록 방법을 설명하기 위한 예시이며 실측 결과가 아닙니다.

첫 번째 단계: 조건을 고정하고 iPhone의 로컬 네트워크 확인

먼저 Shadowrocket을 사용하지 않을 때도 속도가 느린지 확인하세요. 프록시 없이 접속할 수 있는 동일한 대상을 선택해 연결을 끊은 뒤 기준 속도를 측정합니다. 이 단계에서는 로컬 네트워크로 직접 접속하므로 직접 접속하기에 적절한 대상만 선택하세요. 기준 속도도 느리다면 먼저 Wi-Fi, 셀룰러 신호 또는 네트워크 자체를 점검하세요.

현재 상태 기록

Home에서 선택한 노드를 기록하고, Home → Global Routing에서 현재 설정을 기록합니다. Wi-Fi 또는 셀룰러 네트워크, 테스트 대상, 시간도 함께 적어 두세요. 먼저 설정을 지우지는 마세요.
자동 연결 일시 중지

Settings → On Demand로 이동해 기존 설정을 기록한 뒤 On Demand를 잠시 끄고, Home으로 돌아가 연결 스위치를 끄세요. 프록시 연결이 다시 바로 성립하지 않는지 확인해야 프록시 접속을 직접 연결 기준으로 잘못 판단하지 않습니다.
로컬 기준 속도 확인

기기에서 대용량 데이터를 사용하는 다른 작업을 일시 중지하고 라우터 가까이에서 고정된 대상에 접속하세요. Wi-Fi에 웹 인증이 필요하다면 먼저 인증을 완료하세요. 신호 막대가 많아도 외부 연결 구간의 혼잡이 없다는 뜻은 아닙니다.
접속 네트워크 변경

Shadowrocket 연결을 복원하고 노드는 그대로 둔 채 Wi-Fi와 셀룰러 네트워크에서 같은 대상을 각각 테스트하세요. 각 조건에서 세 번 반복합니다. 셀룰러 테스트는 모바일 데이터를 사용하므로 요금제에 맞게 사용량을 조절하세요.
기존 설정 복원

결과를 기록한 뒤 필요한 Global Routing 및 On Demand 설정을 복원하세요. 특정 접속 네트워크에서만 느리다면 해당 네트워크를 우선 점검하고, 노드 프로토콜과 DNS를 동시에 변경하지 마세요.

Wi-Fi와 셀룰러 네트워크를 바꾸면 통신사 외부 연결 경로도 달라집니다. 따라서 이 비교로 확인할 수 있는 것은 ‘로컬 접속망과 그 이후의 경로’이며, 결과만으로 라우터 고장을 단정할 수는 없습니다. 라우터 가까이에서 속도가 눈에 띄게 개선되고 다른 조건이 동일했다면 무선 커버리지나 간섭을 우선 점검할 만합니다.

두 번째 단계: 노드 엔드포인트와 노드까지의 경로 구분

노드는 연결의 서버 엔드포인트이고, 경로는 기기에서 해당 엔드포인트까지, 그리고 엔드포인트에서 대상까지 이어지는 데이터 경로입니다. 노드 지연 시간이 낮다는 것은 특정 탐색 요청에 빠르게 응답했다는 뜻일 뿐입니다. 서버의 사용 가능한 대역폭이나 현재 부하, 서버에서 대상 사이트까지의 속도를 보여 주지는 않습니다. 지리적으로 가깝다고 실제 경로가 짧은 것도 아닙니다.

같은 네트워크에서 기존 노드 변경: Home에서 보유한 구독에 포함된 다른 노드를 선택하고 테스트 대상과 Global Routing은 그대로 두세요. 특정 노드만 계속 느리다면 해당 엔드포인트와 대상까지의 경로를 우선 확인하세요.
같은 노드에서 네트워크 변경: 노드를 유지한 채 Wi-Fi에서는 느리고 셀룰러에서는 정상이라면 접속 네트워크 또는 노드까지의 경로가 다를 수 있습니다. 노드 전반의 성능 문제라고 바로 단정할 수는 없습니다.
같은 노드에서 시간대 변경: 조건을 최대한 맞춰 혼잡 시간대와 한산한 시간대의 결과를 각각 기록하세요. 특정 시간대에만 속도가 떨어진다면 혼잡 가능성을 확인해 볼 수 있습니다. 한 번의 테스트만으로 서비스 제공자의 속도 제한을 단정할 수는 없습니다.
같은 노드에서 대상 변경: 여러 대상 중 하나만 느리다면 해당 대상의 응답 상태, 적용된 규칙, 노드에서 그 대상으로 가는 경로를 확인하세요. 모든 설정을 곧바로 바꾸지는 마세요.

구독 업데이트는 서비스 제공자가 게시한 노드 정보를 다시 가져오는 기능이며 대역폭을 자동으로 늘려 주지는 않습니다. 서비스 제공자가 엔드포인트 정보 변경을 확인해 준 경우에만 Home에서 해당 구독을 업데이트하고, 선택한 노드가 예상한 항목인지 확인하세요. 업데이트 성공과 속도 개선은 별개의 문제입니다. 업데이트 후에는 엔드포인트도 다시 기록해 노드 변경을 다른 설정의 효과로 오해하지 않도록 하세요.

세 번째 단계: 프로토콜 설정 확인, 포트를 무작정 변경하지 않기

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 및 전송 방식이 서로 다르므로 클라이언트 매개변수가 본인의 서버 설정과 일치해야 합니다. 같은 노드에서 자유롭게 바꿔 쓰는 속도 옵션이 아닙니다. 서버가 한 가지 프로토콜만 제공한다면 클라이언트의 Type만 변경해도 보통 연결이 실패합니다.

로컬 접속노드 연결프로토콜 핸드셰이크데이터 전송대상 응답

Home에서 현재 노드의 편집 화면을 열고 서비스 제공자가 안내한 주소, 포트, 인증 정보와 해당 프로토콜에서 실제로 사용하는 TLS, Server Name, 전송 경로 등의 매개변수를 확인하세요. 현재 노드에 해당하는 항목만 확인하고, 속도를 높이려고 맞지 않는 옵션을 추가로 켜지 마세요.

포트는 속도 향상 스위치가 아닙니다: 443은 HTTPS에서 흔히 사용하는 포트입니다. 노드 포트를 443으로 바꿔도 서버가 해당 포트를 자동으로 수신 대기하거나 TLS가 자동으로 활성화되지는 않습니다.
하위 전송 계층 확인: Hysteria2는 UDP 기반 QUIC을 사용하고 WireGuard도 UDP를 사용합니다. 현재 네트워크에서 UDP가 제한되면 핸드셰이크에 실패하거나 연결이 계속 끊길 수 있습니다. 본인의 서비스 제공자가 이미 제공하는 다른 사용 가능한 설정과 비교해 보세요.
인증서 검증 유지: 인증서 검증은 연결 대상이 올바른지 확인하는 절차입니다. 검증 오류가 발생하면 시스템 시간, Server Name, 서버 인증서를 확인하세요. 검증을 건너뛰는 것을 속도 향상 방법으로 사용해서는 안 됩니다.
MTU를 무작정 조정하지 마세요: 작은 요청은 정상인데 대용량 전송이 반복해서 멈춘다면 경로 MTU 문제일 수도 있지만, 패킷 손실이나 대상의 속도 제한일 수도 있습니다. 우선 증상을 기록하세요. 서버 측 근거가 있는 경우에만 관련 매개변수를 조정하고 기존 값도 보관하세요.

프로토콜을 비교하려면 본인의 서비스 제공자가 이미 제공하고 필요한 매개변수가 모두 갖춰진 연결끼리만 비교하세요. 엔드포인트 지역, 대상, 네트워크, 시간을 최대한 동일하게 유지해야 합니다. 특정 항목이 더 빨라도 그 결과는 해당 테스트 조건에만 적용되며, 모든 네트워크에서 특정 프로토콜이 더 빠르다는 뜻은 아닙니다.

네 번째 단계: Global Routing과 실제 규칙 적용 여부 확인

속도를 점검하기 전에 요청이 예상한 경로를 거치는지 확인해야 합니다. Home → Global Routing에서 Proxy는 프록시 처리 대상으로 설정된 트래픽을 프록시로 전달하고, Direct는 직접 연결 경로를 사용하며, Config는 현재 설정에 따라 처리합니다. Scene을 사용한다면 현재 장면에 적용된 설정과 정책을 먼저 확인하세요. 장면을 바꾸면 두 테스트의 조건이 달라질 수 있습니다.

같은 대상을 Proxy와 Config로 잠시 비교한 뒤 기존 설정을 복원할 수 있습니다. Proxy에서는 정상인데 Config에서 느리다면 대상에 어떤 규칙이 적용됐는지, 어떤 정책을 사용하는지, 정책이 최종적으로 어떤 노드를 선택했는지 우선 확인하세요. Proxy라고 해서 모든 도메인의 DNS 조회 방식까지 반드시 같아지는 것은 아니므로 DNS 설정도 함께 살펴봐야 합니다.

[Rule]
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은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 규칙은 순서대로 확인하며 사용자 지정 정책 이름은 전체 설정에 해당 정의가 있어야 합니다.

Config에서 해당 설정이 목록에 저장되어 있기만 한 것이 아니라 실제로 현재 사용 중인지 확인하세요.
대상 요청의 연결 기록을 확인해 적용된 규칙, 정책, 최종 출구를 살펴보세요. Home에서 선택한 노드만 보고 모든 요청의 경로를 추측하지 마세요.
처음 페이지를 열 때만 느리다면 DNS 조회가 시간 초과되거나 반복 재시도되는지 확인하세요. DNS는 이름을 주소로 변환하는 단계에 영향을 주며, 일반적으로 연결이 성립된 뒤의 지속적인 처리량 저하 전체를 설명하지는 못합니다.
DNS 주소를 한 번에 여러 개 바꾸지 마세요. 기존 값을 보관하고 한 항목만 바꾼 뒤 같은 대상의 첫 응답과 이후 전송 속도가 각각 개선되는지 확인하세요.

오류 기록: 연결 실패와 저속 문제를 따로 처리

문제가 반복적인 연결 실패라면 먼저 연결을 정상화한 뒤 속도를 측정하세요. 아래는 네트워크 로그에 나타날 수 있는 오류 예시입니다. 실제 문구는 연결 단계와 하위 계층에서 반환된 정보에 따라 달라지므로 매번 똑같이 표시되지는 않습니다. 오류를 기록할 때는 발생 시간, 네트워크, 노드도 함께 적어 두세요.

오류: i/o timeout

원인과 해결: 네트워크 읽기 또는 쓰기 단계에서 대기 시간이 초과된 상태입니다. 패킷 손실, 경로 연결 불가, 원격 서버 무응답 등이 원인일 수 있습니다. 먼저 DNS 조회, 연결, 전송 중 어느 단계에서 발생했는지 확인한 뒤 노드를 고정하고 접속 네트워크를 바꿔 비교하세요. 시간 초과만으로 설정을 초기화하지 마세요.

오류: connection refused

원인과 해결: 대상 엔드포인트나 경로상의 장치가 연결 요청을 명시적으로 거부한 상태입니다. 해당 포트에서 서비스가 실행되지 않을 때 흔히 발생합니다. 현재 노드 주소와 포트를 확인하고 본인의 서비스 제공자에게 엔드포인트를 사용할 수 있는지 문의하세요.

오류: no such host

원인과 해결: 현재 이름 조회 과정에서 필요한 호스트 주소를 얻지 못한 상태입니다. 도메인 오타, DNS 레코드, DNS 리졸버 문제가 원인일 수 있습니다. 오류에 표시된 도메인이 노드의 것인지 대상 사이트의 것인지 먼저 확인한 뒤 해당 도메인과 DNS 설정을 점검하세요.

기록을 전달하기 전에 구독 링크, token, 비밀번호, 개인 키와 그 밖의 인증 정보를 가리세요. 프로토콜 이름, 오류 문구, 네트워크 유형, 발생 단계, 비교 결과는 남겨도 됩니다. 이런 정보가 지연 시간 숫자만 담긴 스크린샷보다 문제를 파악하는 데 더 도움이 되는 경우가 많습니다.

자주 묻는 질문: 점검 결과를 판단하는 방법

지연 시간이 매우 낮은데 동영상은 왜 버퍼링되나요?

지연 시간은 탐색 요청만 반영합니다. 동영상 재생에는 지속적인 대역폭, 패킷 손실률, 콘텐츠 서버 상태도 영향을 줍니다. 같은 노드를 유지하고 다른 동영상 하나와 고정된 파일 하나를 각각 테스트하세요. 특정 콘텐츠만 느리다면 해당 콘텐츠 제공처와 적용 규칙을 먼저 확인하고, 낮은 지연 시간이 대역폭을 보장한다고 여기지 마세요.

노드를 바꾸자마자 빨라졌다면 원래 노드에 문제가 있다고 확정할 수 있나요?

두 연결의 전반적인 조건이 달랐다는 뜻이지만, 노드 부하와 경로, 대상 방향 출구가 모두 달라졌을 수 있습니다. 원래 노드로 돌아가 대상과 네트워크를 동일하게 유지한 채 다시 테스트하세요. 차이가 반복해서 나타날 때에만 기록을 본인의 서비스 제공자에게 전달해 확인하는 것이 좋습니다.

연결을 끊어도 다시 자동 연결됩니다. 기준 속도는 어떻게 측정하나요?

먼저 Settings → On Demand에서 현재 설정을 기록하고 자동 연결을 잠시 끈 다음 Home으로 돌아가 연결을 끊으세요. 기기에 다른 관리형 연결 규칙이 있다면 해당 상태도 먼저 확인해야 합니다. 기준 테스트가 끝나면 기존 설정을 복원해 이후의 일반적인 연결 동작에 영향을 주지 않도록 하세요.

사용 중인 노드가 모두 느린데 클라이언트를 다시 구매해야 하나요?

클라이언트 구매와 경로 대역폭은 별개의 문제입니다. 먼저 로컬 기준 속도를 측정하고 다른 접속 네트워크와 비교한 뒤, 공통으로 사용하는 설정과 대상을 확인하세요. 클라이언트 일회성 구매 ≠ 경로 요금제입니다. 다시 구매해도 경로, 엔드포인트, 설정 점검을 대신할 수 없습니다.

마무리: 재현 가능한 비교 기록 남기기

점검이 끝나면 반복 테스트로 효과가 확인된 변경 사항만 유지하고, 임시로 바꿨던 설정과 스위치는 원래대로 복원하세요. 효과를 확인할 수 없는 변경은 되돌려야 변수가 누적되어 다음 문제를 비교하기 어려워지는 일을 막을 수 있습니다. 아래 형식으로 기록하되 인증 정보는 작성하지 않아도 됩니다.

테스트 대상: 같은 웹페이지 또는 고정된 파일
테스트 조건: 같은 iPhone, 다른 대용량 작업은 일시 중지
접속 네트워크: Wi-Fi / 셀룰러 네트워크
선택한 연결: 본인의 노드 라벨, 인증 정보 제외
Global Routing：Config / Proxy / Direct / Scene
실제 적용: 규칙, 정책, 최종 출구
관찰 시간: 회당 30초, 각 조건에서 3회 반복
기록 항목: 첫 응답, 지속 속도, 연결 끊김 여부
단일 변경: 이번 회차에서 바꾼 조건 한 가지
복원 확인: 설정, 상태, On Demand

신뢰할 수 있는 결론은 “같은 노드가 셀룰러에서는 정상이지만 현재 Wi-Fi에서는 계속 멈춘다”처럼 적용 범위를 밝혀야 합니다. “소프트웨어가 느리다”라고만 적어서는 안 됩니다. 전자는 다음 점검 방향을 분명히 보여 주지만, 후자는 로컬 네트워크, 경로, 프로토콜, 대상 서비스를 한데 섞어 재현하기 어렵습니다.