Shadowrocket 속도 저하 해결: 서버·회선·프로토콜·로컬 네트워크 단계별 점검

이 글 한눈에 보기

이 글은 Shadowrocket에 직접 보유한 서버나 구독을 설정했고 연결은 되지만 속도가 느린 경우에 적용됩니다. 로컬 네트워크, 트래픽 경로, 개별 서버, 프로토콜 설정, DNS, 자동 연결 조건을 차례로 확인하세요. 한 번에 하나의 조건만 바꾸고 같은 대상을 다시 테스트해 지연 시간, 전송 속도, 연결 실패를 구분한 뒤 재현 가능한 점검 기록을 남깁니다.

1. 먼저 ‘느림’의 유형을 구분하세요: 연결 대기인가, 전송 속도 저하인가

연결 스위치가 켜져 있다는 것은 시스템 터널이 활성화되었다는 뜻일 뿐, 대상 서버부터 웹사이트까지 전체 경로가 정상이라는 의미는 아닙니다. 웹페이지가 처음 열릴 때 오래 기다리는 현상, 다운로드 속도가 낮은 현상, 동영상이 간헐적으로 멈추는 현상은 서로 다릅니다. 테스트 전에 발생 시간, 현재 Wi-Fi 또는 셀룰러 네트워크, Home에서 선택한 서버, 현재 Global Routing 옵션을 기록하세요.

로컬 네트워크 시스템 터널 규칙 기반 라우팅 서버 송신 경로 대상 사이트

Connectivity Test는 전체 경로 중 일부만 확인하는 경우가 많습니다. 지연 시간 측정값이 낮다고 지속 전송 속도도 빠른 것은 아니며, 특정 웹사이트의 응답이 느리다고 모든 서버를 사용할 수 없는 것도 아닙니다. 지연 시간 수치를 다운로드 속도로 환산하지 마세요.

관찰된 현상	먼저 확인할 항목	기록 방법
처음 열 때 오래 기다리지만, 로딩 후에는 정상	DNS, 연결 설정, TLS 핸드셰이크	첫 방문과 재방문 결과의 차이를 기록
지속 전송 속도가 낮음	로컬 대역폭, 서버 부하, 송신 회선	같은 리소스를 같은 네트워크에서 연속 테스트
자주 끊기거나 시간 초과 발생	네트워크 패킷 손실, 서버 포트, UDP 연결 가능 여부	네트워크 전환 전후 결과를 기록
특정 웹사이트만 느림	해당 도메인에 적용된 규칙과 대상 사이트 상태	다른 도메인 하나를 추가해 비교

2. 로컬 네트워크: Wi-Fi와 셀룰러 네트워크를 먼저 비교하세요

로컬 네트워크는 이후 모든 테스트의 공통 조건입니다. 공용 Wi-Fi의 웹 인증이 완료되지 않았거나, 라우터가 혼잡하거나, 무선 신호가 불안정하면 Shadowrocket 연결 후 속도가 느릴 수 있습니다. 아래 절차는 iPhone을 기준으로 합니다. iPad에서 셀룰러 네트워크를 비교하려면 기기 자체가 해당 기능을 지원해야 합니다.

Home에서 연결 스위치를 끄고 Safari로 현재 네트워크에서 직접 접속할 수 있는 페이지를 엽니다. 이때도 느리다면 서버 설정을 바로 바꾸지 말고 로컬 네트워크부터 점검하세요.
Wi-Fi 웹 인증을 완료하고 기기에서 대용량 작업을 일시 중지하세요. 라우터 가까이에서 다시 테스트합니다. DNS나 Global Routing은 동시에 변경하지 마세요.
Home으로 돌아가 원래 서버를 다시 선택하고 스위치를 켠 뒤 같은 대상을 테스트하세요.
Wi-Fi를 끄고 셀룰러 네트워크로 전환되었는지 확인한 다음, 같은 서버와 Global Routing 옵션으로 테스트하세요. 셀룰러 데이터 사용량에 유의하세요.
두 네트워크에서 연결이 설정되는지, 첫 방문만 느린지, 지속 전송 중 끊기는지 기록하세요.

2가지

로컬 네트워크 비교: Wi-Fi와 셀룰러 네트워크

1개

매 회차 테스트 조건 하나만 변경

3회

한 번의 변동으로 잘못 판단하지 않도록 같은 대상을 반복 관찰하는 것을 권장합니다.

정리: 문제가 재현되는 네트워크부터 고정하세요

같은 서버가 특정 Wi-Fi에서만 계속 문제를 일으킨다면 해당 네트워크의 인증, 혼잡, 전송 제한부터 확인하세요. 로컬 네트워크 문제를 가리기 위해 프로토콜을 바꾸지는 마세요.

3. Global Routing: 요청이 예상한 경로를 거치는지 확인하세요

Home에서 Global Routing을 열고 현재 Proxy, Direct, Config, Scene 중 어떤 옵션이 선택되어 있는지 기록하세요. 점검을 시작하기 전에 기존 상태를 저장하고 테스트가 끝나면 복원합니다. 모드 전환은 속도를 높이는 기능이 아닙니다. 트래픽이 어떤 경로를 선택할지 정할 뿐 회선 대역폭을 늘리지는 않습니다.

옵션	점검 시 의미	확인 방법
Proxy	전체 프록시 경로와 비교	Home에서 현재 서버를 확인한 뒤 같은 대상에 접속
Direct	직접 연결과 비교	현재 네트워크에서 원래 직접 접속할 수 있는 대상만 테스트
Config	현재 설정된 규칙과 정책에 따라 트래픽 분배	Config에서 실제로 활성화된 파일 확인
Scene	설정된 Scene 조건에 따라 해당 설정 적용	현재 네트워크에 해당하는 Scene을 확인하고, 고정된 프록시 경로로 간주하지 않기

Proxy에서는 정상인데 Config에서 느리다면 다음 단계로 대상 도메인에 어떤 규칙이 적용되는지, 규칙이 지정한 정책에서 실제로 어떤 서버가 선택되는지 확인하세요. Config에서 현재 설정을 열고 DOMAIN-SUFFIX, IP-CIDR, GEOIP, FINAL 순으로 확인합니다. FINAL은 앞선 규칙에 일치하지 않을 때 적용되는 기본 규칙이므로 이미 일치한 규칙을 덮어쓰지 않습니다.

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

위 내용은 규칙 구문 예시이며 그대로 대체해 사용할 수 있는 완성된 설정이 아닙니다. example.com은 예시 도메인입니다. 실제 점검은 문제가 발생한 대상을 기준으로 진행하세요. 정책 그룹을 사용하는 경우 그룹에서 현재 선택된 항목도 확인해야 합니다. 규칙 행 끝에 PROXY가 적혀 있다는 이유만으로 Home에서 예상한 서버가 사용 중이라고 단정하지 마세요.

4. 개별 서버와 회선: 보유한 설정으로 교차 확인하세요

여기서 서버 또는 ‘노드’는 사용자가 직접 보유한 서비스의 연결 항목을 뜻합니다. 서버 진입점, 진입점에서 출구까지의 회선, 출구에서 대상 사이트까지의 경로 중 어느 한 곳이 혼잡해도 속도가 떨어질 수 있습니다. 클라이언트에 표시되는 지연 시간만으로는 어느 구간이 혼잡한지 특정할 수 없습니다.

Home에서 현재 서버의 Connectivity Test를 실행하고 테스트 방식, 결과, 시간을 기록하세요. 측정값이 나왔다고 해서 대용량 전송까지 검증된 것은 아닙니다.
로컬 네트워크와 Global Routing은 그대로 두고 직접 보유한 다른 서버를 선택해 같은 대상에 접속하세요.
특정 서버에서만 문제가 발생하면 해당 서버의 편집 화면을 열고 원본 자료와 주소, 포트, 프로토콜, 인증 설정을 대조하세요.
여러 서버에서 같은 웹사이트만 느리다면 다른 대상도 테스트해 출구에서 대상까지의 경로 문제인지 일반적인 전송 문제인지 구분하세요.
같은 테스트를 시간대를 바꿔 반복하세요. 저녁에만 문제가 생긴다면 부하나 혼잡의 단서일 수 있지만, 서버 상태나 회선 기록으로 추가 확인이 필요합니다.

구독 주소에 접속 인증 정보가 포함될 수 있습니다. 직접 이용 중인 서비스 제공자에게 문의할 때는 서버 별칭, 시간, 네트워크 유형, 테스트 결과만 전달하면 됩니다. 공개된 기록에 전체 구독 주소, 비밀번호, 개인 키를 첨부하지 마세요. 이 매뉴얼은 사용자가 보유한 서비스의 설정 확인 방법만 안내합니다.

5. 프로토콜 설정: 연결 조건부터 확인한 뒤 전송 상태를 판단하세요

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 조건이 서로 다르므로 프로토콜 이름만 바꿔 비교할 수 없습니다. 다른 프로토콜을 테스트하려면 해당 프로토콜에 맞는 서버 설정이 이미 있어야 합니다. 포트 번호가 같아도 프로토콜을 서로 바꿔 쓸 수 있는 것은 아닙니다. 예를 들어 443은 포트 식별자일 뿐, 어떤 프로토콜이나 전송 방식을 사용하는지 판단할 근거가 되지 않습니다.

프로토콜	서버 설정과 일치해야 하는 항목	잘못 판단하기 쉬운 현상
Shadowsocks	주소, 포트, 암호화 방식, 비밀번호	인증 불일치로 연결이 실패한 것이지 대역폭이 낮은 것은 아님
VMess / VLESS	사용자 ID, 전송 유형, 해당 TLS·Host·Path 설정	전송 경로가 잘못되면 연결 설정 단계에서 시간 초과가 발생할 수 있음
Trojan	비밀번호, TLS, 서버에서 요구하는 Server Name	TLS 핸드셰이크 실패로 페이지가 계속 대기하는 것처럼 보일 수 있음
Hysteria2	인증, TLS, UDP 연결 가능 여부, 관련 대역폭 설정	QUIC 기반 연결은 현재 네트워크의 UDP 환경에 영향을 받음
WireGuard	키, Endpoint, 터널 주소, 라우팅 관련 설정	설정 항목이 있다고 해서 UDP 핸드셰이크가 완료된 것은 아님

Home에서 서버 편집 화면을 열고 저장해 둔 원본 설정과 항목별로 대조하세요. 테스트를 위해 인증서 검증을 끄지 마세요. 실제 문제에 맞게 서버 이름, 인증서, 기기 시간 등을 바로잡아야 합니다. MTU나 대역폭 설정을 근거 없이 큰 값으로 지정하지 마세요. MTU는 패킷 크기와 관련이 있고, 대역폭 설정은 해당 서비스의 안내에 따라야 합니다. 일반적인 속도 향상 스위치가 아닙니다.

오류: `connection refused`

원인 및 해결 방법: 대상 포트 또는 중간 장치가 연결을 적극적으로 거부한 상태입니다. 먼저 Home의 서버 편집 화면에서 주소와 포트를 확인하고, 해당 포트가 수신 대기 중인지 직접 이용하는 서비스 제공자에게 문의하세요. 분할 라우팅 규칙을 반복해서 바꿔도 포트 거부는 해결되지 않습니다.

오류: `i/o timeout`

원인 및 해결 방법: 제한 시간 안에 읽기 또는 쓰기가 완료되지 않았다는 뜻입니다. 이 정보만으로 혼잡인지 연결 불가인지 판단할 수 없습니다. 테스트, 핸드셰이크, 전송 중 어느 단계에서 발생했는지 기록한 뒤 로컬 네트워크를 바꾸고 같은 서버로 다시 테스트하세요.

위 오류 문구는 연결 과정에서 나타날 수 있는 예시입니다. 실제 표시는 실패 단계와 하위 구현에 따라 다르며 모든 연결 실패에 같은 문구가 표시되지는 않습니다. 문제를 전달할 때 실제 오류 원문을 남기고, 모든 이상을 ‘속도 느림’으로 뭉뚱그리지 마세요.

6. DNS와 On Demand: 첫 접속 지연 및 네트워크 전환 후 문제 점검

DNS는 도메인 이름을 해석하며, 연결 재사용과 DNS 캐시, 대상 사이트의 캐시도 재방문 결과에 영향을 줍니다. 따라서 처음 열 때는 느리고 새로 고침 후 빨라지는 현상은 DNS 해석 또는 연결 설정 문제의 단서일 수 있습니다. HTTPS 주소를 IP 주소로 바꾸는 것도 신뢰할 만한 확인 방법은 아닙니다. 인증서, Server Name, 사이트 콘텐츠 제공 방식이 달라질 수 있습니다.

Settings에서 DNS 관련 설정을 확인하고, Config의 현재 파일에 있는 DNS 설정도 살펴보세요. 먼저 기존 DNS 주소와 덮어쓰기 설정을 기록합니다.
현재 네트워크에서 설정된 DNS 서버에 연결할 수 있는지, 프록시 경로와 직접 연결 경로에서 결과가 다른지 확인하세요. 여러 DNS 주소와 분할 라우팅 규칙을 동시에 바꾸지 마세요.
문제가 확인된 항목 하나만 조정한 뒤 다시 연결해 같은 도메인에 접속하고, 첫 방문과 이후 방문의 차이를 기록하세요.
Wi-Fi 또는 셀룰러 네트워크를 전환한 뒤에만 문제가 발생한다면 Settings → On Demand에서 현재 자동 연결 조건을 기록하세요.
On Demand를 잠시 끄고 Home에서 직접 연결을 끊었다가 다시 연결해 현재 네트워크에서 결과를 확인하세요. 테스트가 끝나면 기존 자동 연결 설정을 복원합니다.

정리: 자동 연결과 전송 성능을 따로 확인하세요

수동으로 다시 연결한 뒤에는 정상으로 돌아오지만 네트워크 전환 후 같은 문제가 반복된다면 먼저 On Demand 조건과 Scene별 설정을 확인하세요. 문제를 프로토콜 전송 속도 탓으로 바로 돌리지 마세요.

7. 자주 묻는 질문과 제출용 점검 기록

지연 시간이 더 짧은 서버인데 다운로드는 왜 더 느린가요?

지연 시간 테스트와 지속 전송 테스트는 서로 다른 항목을 측정합니다. Global Routing과 대상 리소스를 고정하고 Home에서 보유한 서버 두 개를 바꿔 가며 각각 반복 테스트하세요. 한 번의 지연 시간 순위만 보지 말고 전송이 안정적인지 기록합니다.

저녁에만 느린데 프로토콜을 잘못 선택한 걸까요?

먼저 기존 프로토콜과 서버를 그대로 두고 같은 대상을 서로 다른 두 시간대에 테스트한 뒤 로컬 네트워크를 바꿔 보세요. 같은 시간대에 문제가 반복되면 부하와 회선을 확인할 수 있도록 기록을 직접 이용하는 서비스 제공자에게 전달하세요. 발생 시간만으로 프로토콜 문제라고 단정할 수는 없습니다.

Proxy로 바꾸면 정상인데 계속 이렇게 사용해야 하나요?

먼저 Config로 되돌린 뒤 현재 Config 파일에서 대상 도메인에 해당하는 규칙과 정책 그룹 선택을 확인하세요. 잘못 일치한 규칙이나 유효하지 않은 정책을 바로잡고 다시 테스트합니다. Proxy는 비교를 위한 조건이지 계속 유지해야 하는 해결책은 아닙니다.

구독을 업데이트한 뒤 느려졌는데 다시 추가해야 하나요?

먼저 Home에서 현재 선택된 서버가 바뀌었는지 확인한 다음 해당 항목을 열어 주소, 포트, 프로토콜을 대조하세요. 서비스 제공자가 설정을 변경했다면 유효한 설정을 사용해야 합니다. 이전 속도 측정 결과를 되찾으려고 기존 항목을 반복해서 덮어쓰지 마세요.

점검을 마친 뒤에는 다른 사람이 조건을 재현할 수 있도록 기록을 남기세요. ‘너무 느림’이라고만 적어서는 부족합니다. 아래 목록에 실제로 관찰한 내용을 작성하면 되며 인증 정보는 공개할 필요가 없습니다.

발생 시간과 네트워크: 현지 시간으로 구체적인 시각, Wi-Fi 또는 셀룰러 네트워크 여부, 전환 후 결과를 기록합니다.
연결 조건: 서버 별칭, 프로토콜, 포트, Global Routing 옵션, Config의 현재 파일명
대상과 현상: 도메인, 첫 접속 대기 또는 지속 전송 문제, 특정 사이트에만 영향을 주는지 여부
비교 결과: 다른 네트워크, 보유한 다른 서버, Proxy로 임시 전환했을 때의 변화
오류 기록: 실제 오류 원문. 제출 전에 구독 token, 사용자 ID, 비밀번호, 키를 삭제하세요.

Shadowrocket은 Apple 플랫폼용 유료 클라이언트로, 주로 iPhone과 iPad에서 사용하며 App Store에서만 제공됩니다. 개발자는 Shadow Launch Technology Limited이고 앱 ID는 932747118입니다. 클라이언트의 일회성 구매 비용과 사용자가 별도로 보유한 서비스의 회선 비용은 각각 청구됩니다. 시스템 요구 사항, 구매 가능한 기기와 범위는 App Store 페이지의 안내를 확인하세요.