Shadowrocket에 연결한 뒤 속도가 느리다면 연결 시간 초과, 웹페이지 첫 로딩 지연, 지속적인 다운로드 저하를 먼저 구분하세요. 같은 대상, 서버, 네트워크 조건으로 하나씩 비교합니다. 이미 서비스와 설정을 보유한 사용자를 위한 안내입니다. Home에서 서버 선택, Global Routing, 프로토콜 매개변수, 로컬 네트워크 순으로 점검하고 재현 가능한 기록을 남기세요. 앱을 먼저 다시 설치할 필요는 없으며, 여러 설정을 한꺼번에 바꾸지 마세요.
1. 기준 상태 확인: 지연 시간과 다운로드 속도는 다릅니다
먼저 Home에서 사용할 서버를 선택하고 선택 표시를 확인한 다음 연결 스위치를 켜고 Connectivity Test를 실행하세요. 테스트 성공은 해당 테스트 요청이 완료됐다는 뜻일 뿐, 모든 웹사이트와 프로토콜 또는 대용량 파일 전송이 정상이라는 의미는 아닙니다. 지연 시간이 한 번 낮게 나와도 경로의 대역폭이 충분하다고 볼 수 없습니다. 연결이 이루어진 뒤에도 서버 부하, 출구 측 혼잡, 대상 사이트의 제한이 영향을 줄 수 있습니다.
‘느리다’는 현상을 반복해서 확인할 수 있도록 구체적으로 기록하세요. 웹페이지를 누른 뒤 오래 빈 화면이 나타나는지, 글은 금방 표시되지만 이미지 로딩이 계속되는지, 다운로드 시작 후 속도가 점점 떨어지는지 구분합니다. 아래 숫자는 단위 환산과 기록 방법을 설명하는 예시이며, 특정 경로의 실측 성능을 보장하지 않습니다.
- 클라우드 드라이브 동기화, 시스템 업데이트 및 다른 기기의 대용량 전송 작업을 중지하고 테스트 시간과 네트워크 연결 방식을 기록하세요.
- 같은 대상 페이지나 접근 권한이 있는 테스트 파일을 지정해 각 조건에서 연속으로 세 번 테스트하세요. 캐시가 결과에 섞이지 않도록 첫 방문과 재방문 결과를 따로 기록합니다.
- Connectivity Test 결과, 웹페이지 첫 로딩 시간, 지속 전송 속도, 연결 중단 여부를 각각 기록하세요. 이 지표를 하나의 ‘빠르기’ 평가로 합치지 마세요.
- 한 번에 조건 하나만 바꾸세요. 서버를 바꿀 때 Wi-Fi를 함께 바꾸지 말고, 프로토콜을 바꿀 때 DNS도 동시에 수정하지 마세요.
예를 들어 화면에 5 MB/s라고 표시된다면 약 40 Mbps입니다. 5 Mbps가 아닙니다. 앱의 순간 트래픽 표시가 현재 파일의 평균 속도와 일치하지 않을 수 있으므로 다운로드 도구의 평균값 및 테스트 시간과 함께 확인하세요.
2. 서버 점검: 선택 항목, 설정 유효성, 서비스 상태 확인
여기서 서버는 기존 서비스 설정에 등록된 서버 항목을 뜻하며, 설정 파일 자체를 가리키지 않습니다. Home에 여러 항목이 표시되더라도 설정에 등록되어 있다는 뜻일 뿐입니다. 실제 연결은 현재 선택된 항목에 따라 달라지며, 사용 중인 설정이 정책에 따라 다른 출구를 선택할 수도 있습니다. 항목을 바꾼 뒤 연결을 다시 설정하고 새 테스트 요청을 실행해 이전의 장시간 연결이 기존 경로를 계속 사용하는 상황을 피하세요.
- 먼저 서버 항목을 확인하세요: 서버 주소, 포트, 프로토콜, 인증 정보가 서비스 제공자가 안내한 내용과 일치하는지 확인합니다. 포트는 서비스 설정에 지정된 값을 사용해야 합니다. 일반적으로 HTTPS가 443을 사용한다는 이유만으로 포트를 모두 443으로 바꾸면 안 됩니다.
- 그다음 설정을 업데이트하세요: 기존 구독의 업데이트 기능을 사용한 뒤 현재 선택된 항목을 다시 확인합니다. 항목 이름이 같아도 서버 주소와 매개변수가 그대로라는 보장은 없습니다. 구독을 업데이트해도 현재 Config의 규칙까지 함께 업데이트되는 것은 아닙니다.
- 마지막으로 비교하세요: 유효한 서버가 하나 더 있다면 같은 네트워크, 시간대, 대상에서 전환해 비교합니다. 특정 항목 하나에서만 계속 문제가 발생한다면 해당 항목의 상태와 서비스 제한부터 확인하세요.
로그 예시: connection refused
원인: 연결 요청이 거부된 상태입니다. 대상 포트에서 서비스가 수신 대기 중이지 않거나 연결을 명시적으로 거부할 때 흔히 나타납니다. 단순한 대역폭 부족 문제는 아닙니다.
해결 방법: 주소와 포트를 확인하고 구독이 최신 상태인지 점검한 다음, 해당 서버의 서비스 상태를 서비스 제공자에게 문의하세요.
로그 예시: i/o timeout
원인: 제한 시간 안에 해당 읽기·쓰기 작업이 완료되지 않았습니다. 서버에 연결할 수 없거나, 경로에서 패킷이 손실되거나, 대상 응답이 너무 느린 경우 등이 원인일 수 있습니다. 이 메시지만으로는 어느 단계의 문제인지 확정할 수 없습니다.
해결 방법: 오류 발생 전후의 연결 단계와 시간을 기록하세요. 기존에 보유한 다른 서버와 네트워크를 각각 바꿔 테스트해 시간 초과가 어떤 조건을 따라 나타나는지 확인합니다.
위 문구는 네트워크 로그에 표시될 수 있는 오류 예시이며, 실제 화면의 표시는 다를 수 있습니다. 기록을 공유할 때는 서버 주소, 인증 정보, 구독 인증 정보를 가리세요. 이 글은 사용자가 보유한 설정의 문제 해결을 다룹니다. 이 사이트는 서버나 구독을 제공·판매·추천하지 않습니다.
3. 경로 점검: 라우팅 설정과 시간대별 비교로 범위 좁히기
한 번의 요청은 로컬 네트워크 접속, 프록시 서버 진입, 서버 출구, 대상 서비스 순으로 이동할 수 있습니다. 서버에 빠르게 연결되더라도 서버에서 대상 사이트까지의 경로가 빠르다는 뜻은 아닙니다. 특정 웹사이트만 느리다면 모든 서버 설정을 바로 바꾸기보다 대상 사이트의 부하, 콘텐츠 전송 위치, 출구 IP 주소에 대한 대상 사이트의 제한부터 확인하세요.
Home → Global Routing에서 현재 라우팅 모드를 확인하세요. 속도 비교에 앞서 트래픽이 어떤 경로를 이용하는지 파악해야 합니다. 임시 전환은 확인 목적으로만 사용하고 테스트가 끝나면 원래 설정으로 되돌리세요.
| 라우팅 모드 | 점검 목적 | 주의 사항 |
|---|---|---|
| Config | 현재 설정 규칙에 따라 요청을 처리해 평소 증상을 재현합니다. | 연결 스위치만 보지 말고 해당 도메인 또는 IP에 적용된 정책을 확인합니다. |
| Proxy | 규칙에 따른 트래픽 분기가 테스트 요청의 경로에 영향을 주는지 확인할 때 사용합니다. | 원래 직접 연결되던 요청의 처리 방식이 바뀝니다. 모든 문제의 장기적인 해결책으로 사용하기에는 적합하지 않습니다. |
| Direct | 원래 직접 연결할 수 있는 동일한 대상을 기준으로 삼습니다. | 대상에 직접 연결할 수 없다면, 연결 실패만으로 프록시 서버의 속도가 더 빠르거나 느리다고 판단할 수 없습니다. |
| Scene | 실제로 적용 중인 Scene과 해당 설정을 확인합니다. | 먼저 Scene의 적용 조건을 확인하세요. Scene 이름만으로 모든 요청에 같은 정책이 적용된다고 단정할 수 없습니다. |
로컬 네트워크를 그대로 유지하고 시간대를 바꿔 같은 테스트를 반복하세요. 보유한 서버 여러 개가 비슷한 시간대에 모두 느려진다면 공유 경로의 혼잡이 원인일 수 있습니다. 특정 대상 하나에서만 계속 문제가 생긴다면 대상까지의 경로를 확인하는 편이 좋습니다. 이는 원인을 좁히기 위한 단서일 뿐, 한 차례 테스트만으로 확정할 수 있는 결론은 아닙니다.
결론: 속도 비교 전에 경로부터 확인
같은 요청이 Proxy에서는 정상이고 Config에서는 문제가 생긴다면, 서버 인증 정보를 바로 다시 입력하지 말고 Config의 일치 규칙과 정책 경로부터 확인하세요.
4. 프로토콜 점검: 전송 조건을 확인하고 이름만으로 속도를 판단하지 않기
Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 모두 서버 측 설정과 매개변수가 일치해야 합니다. 프로토콜 이름이 속도 등급을 뜻하지는 않습니다. 서로 다른 접속 지점, 서버, 출구를 비교한 결과만으로 특정 프로토콜이 더 빠르다고 증명할 수 없습니다. 서비스 제공자가 해당 설정을 제공한 경우에만 전환 조건이 갖춰집니다.
- Shadowsocks: 암호화 방식, 비밀번호, 서비스에 필요한 기타 매개변수를 확인하세요. 인증 정보가 일치하지 않는 문제는 먼저 연결 오류로 해결해야 하며, 속도 조정에 해당하지 않습니다.
- VMess / VLESS: 인증 ID와 전송 유형, 서비스에서 지정한 Host, path, TLS 등의 매개변수를 확인하세요. 한 항목의 경로를 다른 접속 항목에 복사하지 마세요.
- Trojan: 비밀번호와 TLS 관련 설정을 확인하고, 서버에서 요구하는 이름이 서비스 설정과 일치하는지 확인하세요. ‘느리다’는 이유로 인증서 검증을 끄지 마세요.
- Hysteria2: QUIC 및 UDP 전송 조건에 영향을 받습니다. 로컬 네트워크에서 UDP가 제한되면 연결에 실패하거나 속도가 크게 불안정해질 수 있으므로 다른 네트워크에서도 확인하세요.
- WireGuard: 서비스에서 제공한 키, 엔드포인트, 라우팅 범위를 확인하세요. 일반적으로 UDP를 사용하므로 다른 TCP 요청이 정상이라는 이유만으로 해당 경로도 정상이라고 단정할 수 없습니다.
작은 요청은 성공하지만 대용량 파일 전송이 반복해서 멈춘다면 패킷 손실, 재전송, 서버 속도 제한, 경로 MTU 등이 원인일 수 있습니다. 같은 대상에서 다른 네트워크로 재현한 뒤 서버 안내에 따라 관련 매개변수를 조정하세요. 근거 없이 MTU를 계속 낮추거나 동시 연결 수를 늘리거나 실제보다 과도한 대역폭을 입력하면 원인을 찾기 더 어려워집니다.
5. 로컬 네트워크 점검: Wi-Fi, 셀룰러 네트워크, 자동 연결 확인
유효한 서버 여러 개와 대상 여러 곳에서 같은 Wi-Fi를 사용할 때만 느려지고 셀룰러 네트워크에서는 정상이라면 접속 환경을 먼저 확인하세요. 무선 간섭, 라우터 부하, 가정 내 업로드 대역폭 포화가 지연을 늘릴 수 있습니다. 셀룰러 네트워크도 신호와 기지국 부하에 따라 속도가 달라집니다. 네트워크를 바꾼 뒤에는 최고 속도 한 번만 측정하지 말고 같은 위치에서 연속으로 테스트하세요.
- 공유기 가까이에서 다시 테스트하세요: 가능하다면 서버와 대상을 그대로 둔 채 5 GHz와 2.4 GHz Wi-Fi를 비교합니다. 신호가 강해진 뒤 속도 변동이 줄어든다면 먼저 무선 커버리지를 개선하세요.
- 백그라운드 업로드를 중지하세요: 사진 백업, 파일 동기화 또는 다른 기기의 업로드를 중단한 뒤 웹페이지 첫 로딩과 다운로드 상태를 비교합니다. 업로드 혼잡은 다운로드 확인 응답과 상호작용 요청에도 영향을 줄 수 있습니다.
- 네트워크 인증을 완료하세요: 공용 Wi-Fi에서 웹 로그인을 요구한다면 먼저 인증을 완료합니다. 네트워크 접속이 허용되기 전까지 연결 시간 초과를 서버 성능의 근거로 볼 수 없습니다.
- 설정 충돌을 확인하세요: 시스템에서 다른 VPN 설정이나 네트워크 필터 기능을 동시에 사용 중인지 확인합니다. 테스트에 필요한 연결 조건만 한 번에 하나씩 유지하세요.
- 자동 재연결을 확인하세요: Settings → On Demand에서 실행 조건을 확인합니다. 연결을 끈 상태의 직접 연결 기준을 확인하는 중이라면 관련 자동 연결 조건을 잠시 끌 수 있습니다. 테스트가 끝나면 원래 설정으로 복원하세요.
기기가 계속 뜨겁거나 배터리가 부족한 상태로 작동하거나 백그라운드 작업이 많은 경우에도 측정 결과가 달라질 수 있습니다. 기기 상태를 비슷하게 유지하고 ‘Wi-Fi에서 느리고 셀룰러에서는 정상’인지, ‘모든 네트워크에서 느린지’를 따로 기록하세요. 순간 트래픽 화면만 캡처하는 것보다 문제를 파악하는 데 도움이 됩니다.
6. 첫 로딩 지연과 특정 웹사이트 속도 저하: DNS와 규칙 점검
웹페이지를 처음 열 때 오래 기다려야 하지만 이후 방문은 빨라진다면 DNS 조회나 연결 설정이 원인일 수 있으며, 캐시가 적용된 결과일 수도 있습니다. DNS는 주소 조회와 선택에 영향을 주지만, 이미 연결된 상태에서 대용량 파일의 전송 대역폭을 직접 높이지는 않습니다. 먼저 Config에서 현재 사용 중인 설정을 확인한 뒤 해당 설정의 DNS와 규칙을 점검하세요. 적용되지 않는 파일을 수정하지 않도록 주의합니다.
규칙은 일반적으로 순서대로 일치 여부를 확인하므로 구체적인 규칙은 기본 규칙보다 앞에 배치해야 합니다. 아래 내용은 문법 설명일 뿐, 기존 설정 전체를 교체하라는 뜻이 아닙니다. PROXY는 실제로 사용할 수 있는 프록시 정책을 가리켜야 합니다. 기존 설정을 보존하고 필요한 부분만 테스트하세요.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX는 도메인 접미사를 기준으로 일치 여부를 확인합니다. 예시의example.com은 문법 설명용이며 서비스를 추천하는 의미가 아닙니다.IP-CIDR은 IP 대역을 기준으로 일치 여부를 확인합니다.no-resolve는 해당 규칙이 도메인 조회를 직접 유발하지 않도록 합니다. DNS를 전역으로 끄는 설정은 아닙니다.GEOIP는 대상 IP를 지리 데이터베이스와 대조합니다. 도메인 접미사만 보지 말고 실제로 조회된 IP와 데이터베이스 결과를 확인하세요.FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 앞쪽 규칙의 잘못된 경로 지정을 숨기는 용도로 사용하면 안 됩니다.
시스템 DNS, 사용자 지정 DNS, DNS over HTTPS를 각각 테스트하고 조회 서버와 서버 설정을 동시에 바꾸지 마세요. DNS over HTTPS도 DNS 서비스에 연결할 수 있어야 합니다. 암호화가 추가된다고 첫 로딩 시간이 반드시 짧아지는 것은 아닙니다. 설정을 바꾼 뒤 첫 로딩만 개선되고 다운로드 속도는 여전히 느리다면 DNS 설정을 계속 초기화하지 말고 경로와 서버를 다시 점검하세요.
7. 자주 묻는 질문과 문제 해결 기록
Connectivity Test는 빠른데 다운로드는 왜 느린가요?
Connectivity Test는 특정 테스트 요청의 완료 상태를 보여줄 뿐 지속적인 전송량을 측정하지 않습니다. 현재 서버를 유지한 채 같은 파일을 세 번 연속으로 테스트하고, 보유한 다른 서버와 결과를 비교하세요. 단위 혼동을 막기 위해 MB/s 또는 Mbps도 함께 기록합니다.
저녁에만 느린데 Shadowrocket을 다시 설치해야 하나요?
먼저 같은 네트워크, 서버, 대상을 유지한 채 다른 시간대와 비교하세요. 특정 시간대에 문제가 반복된다면 시간과 속도 변동을 기록하고 로컬 네트워크 점유 상태를 확인한 뒤 서비스 제공자에게 문의하세요. 설정을 먼저 지우지 마세요.
Proxy에서는 정상인데 Config으로 바꾸면 느릴 때는 어떻게 해야 하나요?
Config에서 현재 사용 중인 파일을 확인한 다음 대상에 적용되는 일치 규칙과 정책 경로를 살펴보세요. 더 앞에 있는 DOMAIN-SUFFIX, IP-CIDR, GEOIP 규칙이 먼저 일치하는지, FINAL의 경로 지정이 예상과 맞는지 확인합니다.
Wi-Fi를 바꾼 뒤 연결이 가끔 멈추면 어떻게 점검하나요?
먼저 네트워크 인증을 완료한 뒤 Shadowrocket 연결을 다시 설정하고 Connectivity Test를 실행하세요. Settings → On Demand의 실행 조건을 확인하고 새 네트워크에서 같은 대상을 다시 테스트해 네트워크 전환 순간의 중단인지 지속적인 속도 문제인지 구분합니다.
점검을 마치면 임시로 바꾼 Global Routing 및 On Demand 설정을 원래대로 복원하세요. 서비스 제공자나 지원 담당자에게 전달하는 기록은 문제를 재현하기에 충분해야 하지만 인증 비밀번호, 전체 구독 링크, 키를 포함하면 안 됩니다.
| 기록 항목 | 기록할 내용 |
|---|---|
| 환경 | 기기 운영체제, Wi-Fi 또는 셀룰러 네트워크 여부, 백그라운드 업로드 여부, 발생 시간대 |
| 경로 | 서버의 로컬 메모, 프로토콜, Global Routing 모드, 현재 Config, 실제로 일치한 정책 |
| 증상 | 첫 로딩 대기 시간, 지속 속도와 단위, 세 차례 테스트 결과 범위, 연결 중단 여부와 오류 문구 |
| 비교 | 서버만 변경하거나 네트워크만 변경하거나 라우팅 모드만 변경했을 때도 같은 문제가 발생하는지 |