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

이 글의 핵심

Shadowrocket에 연결한 뒤 속도가 느리다면 먼저 테스트 조건을 고정하고 로컬 네트워크, 프로토콜 설정, 전송 경로, 노드 서버를 차례로 비교해 보세요. 이 글은 iPhone / iPad 사용 경로를 중심으로, 이미 이용 중인 서비스와 구독이 있고 연결은 되지만 웹페이지 로딩이나 다운로드가 유난히 느린 경우에 적합합니다. 읽고 나면 지연 시간, 대역폭, 연결 실패를 구분하고 반복 가능한 점검 기록을 정리할 수 있습니다.

먼저 테스트 조건을 고정하세요: 지연 시간이 낮아도 다운로드가 빠른 것은 아닙니다

먼저 ‘페이지가 열리기까지 오래 걸리는 경우’와 ‘전송이 시작된 뒤 속도가 느린 경우’를 구분하세요. 전자는 DNS, 연결 설정, TLS 핸드셰이크와 관련이 있을 수 있고, 후자는 가용 대역폭, 패킷 손실, 속도 제한, 대상 사이트의 상태가 원인일 가능성이 큽니다. Home의 연결 또는 지연 시간 테스트는 해당 시점의 특정 탐색 결과만 보여 줍니다. 지속적인 다운로드를 대신할 수 없으며, 모든 앱이 같은 출구를 거친다는 뜻도 아닙니다.

요청 하나가 여러 구간을 거칩니다. 특정 노드의 지연 시간이 낮게 표시되더라도 대상 웹사이트가 그 서버와 가깝다는 뜻은 아닙니다. 원격 출구에서 웹사이트까지의 경로가 혼잡할 수도 있습니다. 점검할 때는 같은 웹사이트나 같은 파일을 사용하고, 서로 다른 속도 측정 서비스의 결과를 그대로 비교하지 마세요.

로컬 네트워크 연결규칙 판정프로토콜 연결회선 전송서버 출구

대상 고정: 접근 권한이 있는 동일한 HTTPS 페이지나 파일을 사용하세요. 파일 테스트는 수십 MB 정도면 충분하며, 모바일 데이터 사용량에 유의하세요.
시간 고정: 테스트마다 약 30초간 관찰하고 3회 반복하세요. 첫 화면이 표시될 때까지 걸린 시간, 안정적인 전송 속도, 중단 여부를 기록하고 순간 최고 속도만 보지 마세요.
단위 통일: 8 Mbps는 약 1 MB/s이며, 프로토콜 오버헤드는 제외한 값입니다. Mbps와 MB/s를 같은 단위로 취급하지 마세요.
변수 고정: 매 회차마다 네트워크, 노드, 라우팅 모드 중 하나만 바꾸세요. 테스트 중에는 클라우드 백업, 시스템 업데이트, 다른 대용량 전송을 일시 중지하세요.

첫 번째 단계: Wi-Fi와 모바일 데이터 비교

같은 노드가 Wi-Fi에서는 느리고 모바일 데이터에서는 정상이라면, 프로토콜을 바로 바꾸기보다 Wi-Fi 연결과 그 상위 경로부터 확인하세요. 셀룰러 연결을 지원하지 않는 iPad라면 본인 휴대전화의 핫스팟으로 비교할 수 있습니다. 핫스팟에도 속도 제한이 있을 수 있으므로 또 다른 연결 경로로만 활용하고 절대적인 기준으로 삼지는 마세요.

현재 설정 보존

Home에서 현재 노드와 Global Routing을 기록하고, Config에서 사용 중인 설정을 복사해 보관하세요. Settings → On Demand의 현재 상태도 적어 두세요. 활성화되어 있다면 통제된 테스트 중 잠시 끌 수 있습니다. 자동 재연결로 인해 ‘연결이 끊긴 상태’라는 판단이 흐려지지 않도록 하고, 테스트가 끝나면 원래대로 복구하세요.
로컬 기준 상태 확인

먼저 Shadowrocket 연결을 끊고 실제로 연결이 중단되었는지 확인한 뒤, 원래 직접 연결할 수 있는 HTTPS 페이지를 열어 보세요. 해당 페이지도 오래 기다리거나 연결이 반복해서 끊긴다면 Wi-Fi 신호, 라우터 부하, 광대역 연결부터 점검하세요.
연결 경로 전환

Shadowrocket에 다시 연결하고 같은 노드와 대상을 유지한 채 Wi-Fi와 모바일 데이터에서 각각 테스트를 반복하세요. iPhone에서는 시스템 Settings → Wi-Fi에서 Wi-Fi를 끄고 상태 표시줄의 연결 상태가 바뀐 것을 확인한 다음 다음 테스트를 진행할 수 있습니다.
문제 범위 좁히기

Wi-Fi에서만 문제가 생기면 라우터 가까이에서 다시 테스트하고, 사용할 수 있는 5 GHz와 2.4 GHz 네트워크를 각각 확인하세요. 특정 연결에서만 접속할 수 없다면 통신사와 네트워크 유형을 기록해 두고, 프로토콜 단계에서 UDP 연결 가능성을 점검하세요.

두 번째 단계: 프로토콜 매개변수와 실제 라우팅 확인

Home에서 현재 노드의 편집 화면을 열고 서비스 제공업체가 제공한 원래 매개변수와 대조하세요. 프로토콜 유형, 서버 주소, 포트, 인증 정보, 설정에서 요구하는 TLS, SNI, 전송 옵션을 하나씩 확인합니다. 속도를 높이겠다며 포트를 임의로 바꾸거나 인증서 검증을 끄지 마세요. 예를 들어 서비스에서 TCP 443을 사용한다고 명시했다면 해당 포트를 확인해야 합니다. 다른 설정에서 UDP 443을 사용한다고 해서 두 설정의 포트를 서로 바꾸면 안 됩니다.

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 방식이 서로 다릅니다. Type만 바꾼다고 서버가 새 프로토콜을 받아들이는 것은 아닙니다. Hysteria2는 QUIC 기반이므로 UDP가 필요하며, WireGuard도 UDP를 사용합니다. 특정 Wi-Fi에서 UDP를 강하게 제한하면 연결 시간이 초과되거나 불안정할 수 있습니다. 다른 프로토콜이 어떤 하위 전송 방식을 사용하는지는 기존 설정을 기준으로 확인하고, 프로토콜 이름만 보고 판단하지 마세요.

점검 항목	확인 방법	판단 기준
Global Routing	Home에서 현재 모드를 확인하세요. Config는 설정 규칙에 따라 트래픽을 분기하고, Proxy는 프록시 경로를 임시로 비교할 때, Direct는 직접 연결할 때 사용합니다.	같은 대상이 Proxy에서는 정상이고 Config에서는 문제가 생긴다면 규칙과 정책 선택부터 확인하세요. 테스트가 끝나면 원래 모드로 복구합니다.
규칙 일치 여부	Config에서 관련 DOMAIN-SUFFIX, GEOIP, IP-CIDR, FINAL 규칙과 해당 정책이 있는지 확인하세요.	일반 규칙은 순서에 따라 매칭 결과가 달라집니다. 너무 앞에 있는 포괄적인 규칙이 대상을 의도하지 않은 경로로 보낼 수 있습니다.
DNS 및 TLS	도메인 조회 실패, 인증서 오류, 연결 시간 초과를 구분해 기록하세요. 시스템 시간과 서비스에서 요구하는 SNI도 확인합니다.	도메인으로만 접속되지 않는다고 해서 대역폭이 부족한 것은 아닙니다. 인증서와 가상 호스트가 다를 수 있으므로 HTTPS에서는 도메인 대신 IP 주소만 입력해 판단하지 마세요.
UDP 연결 가능성	두 연결 네트워크에서 같은 Hysteria2 또는 WireGuard 설정으로 테스트하세요.	특정 네트워크에서만 실패한다면 해당 연결 경로를 조사해야 합니다. 연결 시간 초과만으로 통신사 차단이라고 단정할 수는 없습니다.

처음 열 때만 느리고 같은 페이지를 다시 열면 눈에 띄게 빨라진다면 DNS, 연결 재사용, 캐시를 중점적으로 살펴볼 수 있습니다. 다만 이는 단서일 뿐입니다. DNS, 프로토콜, 노드를 한꺼번에 바꾸면 어떤 변경이 효과가 있었는지 알 수 없습니다. 설정을 수정할 때는 먼저 복사본을 남기고 한 번에 필드 하나만 바꾸세요.

세 번째 단계: 회선 혼잡과 대상 사이트 제한 구분

회선 문제는 낮에는 정상이다가 저녁에 느려지거나, 연결은 되지만 전송 속도가 크게 오르내리거나, 같은 시간대에 여러 대상에서 문제가 생기는 형태로 나타날 수 있습니다. 이를 확인하려면 같은 연결 네트워크, 같은 노드, 같은 테스트 대상을 사용해 시간대별로 기록해야 합니다. 한 번 측정한 지연 시간만으로 판단하지 마세요.

시간대별 비교: 오전 9시, 오후 3시, 오후 9시에 각각 한 차례씩 테스트할 수 있습니다. 이는 기록 시간을 정하는 예시일 뿐, 모든 지역이 같은 시간대에 혼잡하다는 뜻은 아닙니다.
대상별 비교: 같은 노드에서 서로 독립적인 합법적 대상 두 곳을 테스트하세요. 한 사이트만 느리다면 해당 사이트의 서비스 상태, 계정 제한, CDN 할당, 앱 자체 동작을 확인하세요.
출구별 비교: 이용 중인 구독에 지역이나 회선이 다른 노드가 이미 있다면 같은 시간대에 비교할 수 있습니다. 노드 이름이 다르다고 상위 경로까지 다르다고 보장할 수 없으므로 결과를 신중하게 해석하세요.
지속 속도 확인: 처음 몇 초 동안은 빠르다가 이후 안정적으로 느려진다면 속도 제한일 수도 있고, 캐시 소진이나 혼잡 제어 변화 때문일 수도 있습니다. 서비스 제공업체의 트래픽 및 대역폭 정책과 함께 확인해야 합니다.

‘지리적으로 가깝다’는 이유만으로 회선이 좋다고 판단하지 마세요. 실제 경로, 통신사 간 연결, 서버 출구 모두 사용 경험에 영향을 줄 수 있습니다. 특정 시간대에만 느려진다면 ‘저녁에 너무 느리다’고만 설명하기보다 정확한 시간, 시간대, 연결 네트워크, 대상에서 나타난 현상을 본인 서비스 제공업체에 전달해야 확인하기 쉽습니다.

네 번째 단계: 노드 서버와 실제 오류 확인

같은 연결 네트워크에서 이용 중인 구독의 다른 노드는 정상인데 특정 노드만 계속 문제가 생긴다면 점검 범위를 해당 노드와 그 경로로 좁힐 수 있습니다. 노드는 연결 끝점일 뿐 전체 회선과 같지 않습니다. 서버가 온라인이어도 출구 대역폭 부족, 연결 수 제한, 원격 네트워크 장애가 발생할 수 있습니다.

아래는 네트워크 진단 과정에서 나타날 수 있는 실제 저수준 오류 문구입니다. 매번 같은 형식으로 표시된다는 뜻은 아닙니다. 오류가 발생한 시각과 전체 맥락을 보존하세요. 오류 한 건만으로는 범위를 좁힐 수 있을 뿐, 문제가 발생한 구간을 단정할 수 없습니다.

오류: connection timed out

가능한 원인: 제한 시간 내에 연결을 완료하지 못한 상태입니다. 경로의 패킷 손실, 포트 연결 불가, UDP 제한, 서버 무응답 등이 원인일 수 있습니다.

조치: 노드 매개변수는 그대로 두고 Wi-Fi와 모바일 데이터에서 각각 다시 테스트하세요. 두 연결 모두 실패하면 본인 서비스 제공업체에 주소, 포트, 서비스 상태를 확인하세요.

오류: connection refused

가능한 원인: 연결이 명시적으로 거부된 상태입니다. 대상 포트에서 서비스가 대기 중이지 않거나 중간 장치가 연결을 적극적으로 거부하는 경우가 흔합니다.

조치: 서버 주소와 포트를 확인하고 포트를 계속 추측해서 바꾸지 마세요. 서비스 제공업체에 대기 상태와 접근 제어 설정을 확인해 달라고 요청하세요.

오류: certificate has expired

가능한 원인: 확인 대상 인증서가 만료되었거나 기기 시간이 잘못되어 인증서 유효 기간이 잘못 판단되었을 수 있습니다.

조치: 먼저 시스템 날짜와 시간을 확인한 뒤 서비스 제공업체에 TLS 인증서와 SNI를 확인하세요. 인증서 검증은 유지하고, 검증 건너뛰기를 속도 개선 방법으로 사용하지 마세요.

구독 업데이트에 성공했다고 현재 노드를 사용할 수 있다는 뜻은 아닙니다. 설정을 가져오는 작업이 완료되었다는 의미일 뿐입니다. 반대로 업데이트 실패가 기존 노드의 속도 저하 원인을 설명하는 것도 아닙니다. 새로고침이 필요하면 Home에서 기존 구독을 업데이트하고 주소와 권한이 여전히 유효한지 확인하세요. 문제를 찾는 대신 모든 설정을 삭제하고 다시 가져오지는 마세요.

특정 노드만 문제인 경우: 노드 식별 정보, 오류 원문, 재현 시각을 제공하고 서버 부하, 점검 여부, 포트 상태를 문의하세요.
모든 노드에서 문제가 생기는 경우: 먼저 로컬 연결, 계정 상태, 공통 설정을 확인한 뒤 같은 상위 경로를 공유하는지 살펴보세요.
점검 기록을 공유하기 전에: 구독 주소, token, 비밀번호, 개인 키, 개인 접속 기록을 숨기고 문제 확인에 필요한 항목만 남기세요.

자주 묻는 질문: 연결은 정상인데도 느린 경우

지연 시간이 낮게 표시되는데 동영상이 계속 버퍼링되는 이유는 무엇인가요?

지연 시간 측정 결과는 동영상 CDN에서 사용할 수 있는 대역폭을 나타내지 않습니다. 같은 동영상과 화질을 고정해 재생이 지속되는지 먼저 확인한 뒤 다른 합법적 대상으로 바꿔 보세요. 해당 플랫폼에서만 문제가 생긴다면 대상 CDN 경로와 플랫폼 제한을 확인하세요. 지연 시간만으로 노드 순위를 정하지 마세요.

Global Routing을 Proxy로 바꾸니 해결됐습니다. 어떻게 해야 하나요?

먼저 원래 모드를 기록한 뒤 Config에서 대상과 관련된 규칙 및 정책을 확인하세요. Proxy 비교에서는 정상인데 Config에서 문제가 생긴다면 모드별 처리 경로가 다를 수 있다는 뜻입니다. 프로토콜 자체가 더 빠르다는 의미는 아닙니다. 잘못 매칭된 규칙을 수정한 뒤 원래 Config 모드로 되돌리고 같은 대상을 다시 테스트하세요.

Hysteria2로 전환하면 반드시 빨라지나요?

그렇지 않습니다. Hysteria2를 지원하는 서버와 해당 설정이 이미 있어야 하며, 연결 네트워크에서도 필요한 UDP 통신을 허용해야 합니다. 사용 여부를 결정하기 전에 같은 네트워크에서 연결 가능성과 지속 전송 속도를 비교하세요. 기존의 다른 프로토콜 노드 이름만 Hysteria2로 바꾸어 사용할 수는 없습니다.

연결을 끊어도 자동으로 다시 연결됩니다. 점검에 영향을 주나요?

직접 연결 비교에 영향을 줍니다. Settings → On Demand에서 실행 조건을 확인하고 테스트 환경에서 연결을 끊어도 되는지 확인한 뒤 잠시 비활성화하세요. 다음으로 연결 상태를 다시 확인합니다. 테스트가 끝나면 기록해 둔 원래 설정으로 복구하고, 기존 자동 연결 설정을 잊은 채 계속 꺼 두지 마세요.

점검 기록 제출: 재현에 필요한 최소 정보만 남기기

네 단계 점검을 마치면 ‘어떤 네트워크에서, 어떤 노드를 사용해, 어떤 모드로, 어떤 대상에 접속할 때 느린가?’에 답할 수 있어야 합니다. 여전히 원인이 불분명하다면 최적화 매개변수를 계속 추가하지 말고 변수 하나씩 비교하는 단계로 돌아가세요. Mac, Windows, Android, Linux에서도 같은 단계별 점검 방법을 적용할 수 있지만, iPhone / iPad의 시스템 메뉴 경로를 그대로 사용하지는 마세요.

환경: 기기 종류, 시스템, Wi-Fi 또는 모바일 데이터 여부, 백그라운드에서 대용량 작업이 실행 중인지 기록하세요.
설정: 프로토콜 이름, 현재 Global Routing, 민감 정보가 아닌 노드 식별 정보, 최근 본인 구독을 업데이트했는지 기록하세요.
증상: 첫 화면 로딩 시간, 안정적인 전송 속도와 단위, 중단 여부, 오류 원문, 발생 시각을 기록하세요.
비교: 어떤 변수를 바꾼 뒤 개선되었는지, 결과가 몇 차례 연속으로 동일했는지, 테스트 후 어떤 설정을 복구했는지 기록하세요.