Shadowrocket 연결 후 속도가 느리다면 먼저 테스트 대상, 서버, 시간을 고정하고 Wi-Fi와 셀룰러 네트워크를 비교하세요. 그다음 라우팅 모드, 기존 프로토콜 설정, 회선 변동, 서버 부하를 확인합니다. 이 글은 이미 보유한 서비스 설정이나 구독을 사용하는 경우를 대상으로 합니다. ‘연결 지연이 낮음’, ‘웹페이지가 빨리 열림’, ‘다운로드 속도가 꾸준히 빠름’을 구분하고, 한 번에 하나씩 조건을 바꿔 원인을 좁혀 갑니다. 한 번의 Ping 결과만으로 모든 설정을 바꾸지는 마세요.
1. 속도 저하를 연결·첫 응답·지속 전송으로 구분하기
먼저 알아둘 점은 Ping 수치가 낮다고 대역폭이 큰 것은 아니며, 연결 스위치가 켜져 있다고 요청이 예상한 경로로 프록시 처리되는 것도 아니라는 것입니다. 점검 전에 Home에서 현재 서버를, Global Routing에서 현재 모드를 기록하고 Config에서 사용 중인 설정을 확인하세요. 설정을 복사해 둔 뒤 매번 변수 하나만 바꾸세요.
웹페이지에 내용이 표시되기까지 오래 걸린다면 DNS, 연결 수립, 대상 서버의 응답이 원인일 수 있습니다. 페이지는 빨리 열리지만 대용량 파일 다운로드가 느리다면 지속 처리량 문제일 가능성이 큽니다. 영상이 처음엔 잘 재생되다가 중간중간 멈춘다면 속도 변동, 패킷 손실, 대상 서버의 속도 제한을 살펴보세요. 여러 현상이 함께 나타날 수도 있으므로 모두 프로토콜 문제라고 단정하지 마세요.
- 접근 권한이 있고 반복 테스트가 가능한 페이지나 파일 하나를 정해 매번 같은 대상을 사용하세요.
- 연결에 걸린 시간, 페이지가 처음 표시될 때까지의 시간, 전송이 안정된 뒤의 속도를 각각 기록하세요.
- Wi-Fi 또는 셀룰러 네트워크, 서버 이름, Global Routing 모드, 테스트 시간을 기록하세요.
- 각 조건에서 세 번씩 테스트하고 실패 횟수도 기록하세요. 가장 빠른 결과만 남기지 마세요.
2. 로컬 네트워크 점검: Wi-Fi와 셀룰러 네트워크 비교
같은 서버, 대상, 설정을 유지하고 접속 네트워크만 바꾸세요. Wi-Fi에서 느리고 셀룰러 네트워크에서는 정상이라면 접속 네트워크나 해당 네트워크에서 서버까지의 경로에 차이가 있을 수 있습니다. 그렇다고 공유기 고장이라고 단정할 수는 없습니다. 무선 간섭, 업로드 대역폭 점유, 네트워크 정책, 통신사별 라우팅 차이도 영향을 줄 수 있습니다.
- Wi-Fi에서 세 차례 테스트하고 결과를 기록하세요. 신호가 약한 영향을 배제하려면 무선 액세스 포인트 가까이에서 진행하세요.
- Wi-Fi를 끄고 셀룰러 네트워크에 연결됐는지 확인하세요. Shadowrocket 연결을 끊었다가 다시 연결해 새로운 접속 경로를 사용하도록 합니다.
- 같은 서버와 대상을 유지한 채 세 차례 테스트하세요. 다운로드 테스트는 셀룰러 데이터를 사용하므로 먼저 데이터 잔여량을 확인하세요.
- Wi-Fi로 돌아와 한 번 더 테스트하세요. 특정 액세스 포인트에서만 문제가 반복된다면 해당 네트워크의 혼잡이나 제한을 점검하세요.
일반 네트워크가 정상인지 확인하려면 원래 직접 접속할 수 있는 대상을 골라 연결을 잠시 끊고 비교하세요. 이때 트래픽은 시스템의 일반 네트워크 경로로 전송됩니다. 테스트 중 자동으로 다시 연결되지 않도록 Settings → On Demand에서 현재 자동 연결 조건을 기록한 뒤 잠시 끄고, 테스트가 끝나면 복원하세요. 원래 직접 접속할 수 없는 대상으로 로컬 네트워크 장애 여부를 판단하지 마세요.
| 반복해서 나타나는 현상 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| Wi-Fi는 느리고 셀룰러 네트워크는 정상 | 무선 연결 품질, 접속망 혼잡, 서버까지의 경로 | 같은 Wi-Fi에서 액세스 포인트를 바꾸고 서버는 그대로 둔 채 다시 테스트 |
| 두 네트워크 모두 느리지만 직접 접속 비교 대상은 정상 | 프록시 경로, 서버 또는 대상 서버 | 라우팅 모드를 확인한 뒤 기존 서버끼리 비교 |
| 직접 접속과 프록시 접속 모두 느림 | 로컬 네트워크 사용량, 대상 서버 응답 | 백그라운드 전송을 중지하고 직접 접속할 수 있는 비교 대상을 하나 추가 |
3. 라우팅 점검: 같은 경로를 측정하고 있는지 확인
Home → Global Routing에서 현재 모드를 확인하세요. Config는 설정된 규칙에 따라 요청을 처리합니다. Proxy는 프록시 경로를 비교할 때, Direct는 직접 연결을 비교할 때 사용합니다. Scene은 선택된 시나리오에 따라 처리하므로 테스트 시 해당 시나리오도 확인해야 합니다. 서로 다른 모드에서 측정한 결과를 섞어 평균 내지 마세요.
Config에서는 규칙이 순서대로 적용됩니다. DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR과 GEOIP는 해당 IP 조건을 처리하고, FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 대상이 같아 보여도 페이지의 이미지나 미디어가 다른 도메인을 사용해 별도의 정책을 따를 수 있습니다. 홈페이지만 열리는지 확인하기보다 요청 기록에서 대상과 적용된 정책을 살펴보는 편이 정확합니다.
- 같은 대상을 Proxy 모드로 잠시 비교하기 전에 기존 모드를 기록하고, 테스트가 끝나면 원래 설정으로 되돌리세요.
- Proxy에서는 정상인데 Config에서 느리다면 프로토콜 설정을 바로 바꾸지 말고 적용된 규칙, 정책 그룹, 실제 선택 항목부터 확인하세요.
- 모드나 서버를 바꾼 뒤에는 테스트 연결을 새로 설정하세요. 기존 장시간 연결이 관찰 결과에 영향을 줄 수 있습니다.
- 처음 열 때만 느리고 이후 전송은 정상이라면 DNS 조회와 연결 수립 단계를 확인하세요. DNS, 규칙, 서버를 한꺼번에 바꾸지는 마세요.
4. 프로토콜 점검: 설정을 확인하고 무조건 프로토콜을 바꾸지 않기
Home에서 현재 서버의 편집 화면을 열고 주소, 포트, 프로토콜 설정을 기존에 보유한 설정과 하나씩 대조하세요. 포트는 속도 단계가 아니므로 임의로 443으로 바꿔 속도를 높이려 해서는 안 됩니다. 프로토콜, 포트, 서버 측 수신 설정은 서로 맞아야 합니다. 주소가 해석된다고 해서 인증 및 암호화 설정까지 올바르다는 뜻은 아닙니다.
| 프로토콜 | 중점 확인 사항 | 피해야 할 조치 |
|---|---|---|
| Shadowsocks | 서버 주소, 포트, 비밀번호, 암호화 방식, 설정된 플러그인 매개변수 | 암호화 방식이나 비밀번호를 임의로 변경 |
| VMess / VLESS | 사용자 ID, 전송 방식, TLS 사용 시 서버 이름 등의 설정 | 전송 방식이나 경로를 추측으로 변경 |
| Trojan | 비밀번호, 포트, TLS 서버 이름 | 인증서 검증을 꺼서 핸드셰이크 문제를 가리기 |
| Hysteria2 | 인증 정보, TLS 설정, 접속 네트워크에서 UDP에 접근할 수 있는지 | 설정에 입력된 대역폭 값을 회선 속도 보장으로 간주 |
| WireGuard | 키, 상대 주소, 포트, 터널 관련 설정 | 원인을 확인하지 않은 채 MTU를 바꾸거나 키를 교체 |
Hysteria2와 WireGuard는 UDP 전송 조건의 영향을 받습니다. 다른 프로토콜의 실제 전송 방식도 설정에 따라 달라집니다. 같은 UDP 설정이 특정 Wi-Fi에서만 계속 시간 초과되고 셀룰러 네트워크에서는 정상이라면 접속 네트워크의 UDP 제한을 먼저 확인하세요. 서버 측에서 호환되는 다른 설정을 제공하는 경우에만 프로토콜을 비교할 의미가 있습니다. 클라이언트에서 프로토콜 이름만 바꾸면 안 됩니다.
5. 회선과 서버 점검: Ping·시간대·지속 전송 결과를 함께 비교
Ping은 일반적으로 왕복 지연 시간을 측정하며 지속 처리량을 나타내지는 않습니다. 일부 서버는 ICMP에 응답하지 않으므로 Ping 시간이 초과되어도 실제 서비스 연결은 가능할 수 있습니다. TCP 연결 테스트도 특정 포트의 연결 단계만 확인하며 파일 다운로드 테스트와는 다릅니다. Home에서 Connectivity Test를 사용할 때는 테스트 방식과 대상을 먼저 확인하고, 서로 다른 방식의 수치를 그대로 비교하지 마세요.
회선 품질은 로컬 기기에서 서버까지, 그리고 서버에서 대상까지의 경로에 좌우됩니다. 서버 부하는 CPU, 사용 가능한 대역폭, 연결 수, 속도 제한과 관련이 있습니다. 클라이언트에서 한 번 측정한 결과만으로 둘을 완전히 구분하기는 어렵습니다. 시간, 접속 네트워크, 대상과 함께 현상을 기록하세요.
- 서버를 고정하고 시간대 비교: 문제가 발생하는 시간대와 다른 시간대에 같은 테스트를 반복하세요. 특정 시간대에만 느리다면 혼잡이나 부하와 관련이 있을 수 있지만, 어느 쪽에서 혼잡이 발생했는지는 단정할 수 없습니다.
- 대상을 고정하고 기존 서버 비교: 이미 보유했고 정상적으로 사용할 수 있는 설정만 비교하세요. 한 서버만 계속 느리고 다른 서버는 정상이라면 해당 서버나 관련 경로로 원인을 좁힐 수 있습니다.
- 서버를 고정하고 대상 비교: 특정 대상만 느리고 다른 대상은 정상이라면 대상 측 속도 제한, 대상까지의 경로, 적용된 규칙 차이를 확인하세요.
- 지속 전송 상태 확인: 전송이 안정된 구간과 멈춘 횟수를 기록하세요. 지연 시간이 낮아도 패킷 손실, 재전송, 서버 대기열로 인해 전송이 자주 중단될 수 있습니다.
‘저녁에 모든 대상이 느리고, 셀룰러 네트워크로 바꿔도 느리지만 다른 기존 서버에서는 정상’이라면 기록을 본인의 서비스 제공자에게 전달해 부하와 회선을 확인해 달라고 요청할 수 있습니다. 이 결과만으로는 서버 자원 부족과 공유 출구망 혼잡을 구분할 수 없으며 서버 측 모니터링이 필요합니다. 지리적으로 가깝거나 Ping이 가장 낮다는 이유만으로 서버를 선택하지 마세요.
6. 오류가 발생하면 먼저 연결 실패를 해결한 뒤 속도 측정
오류가 계속 표시된다면 현재 테스트가 안정적인 전송 단계에 진입하지 못했을 수 있습니다. 아래는 네트워크 로그에 자주 나타나는 오류 문구입니다. 실제 문구는 연결 기반 기술과 오류 발생 원인에 따라 달라지며 모든 프로토콜에서 같은 문구가 표시되는 것은 아닙니다. 본인 기록에 해당 문구가 실제로 있을 때만 참고하고, 표시되지 않은 오류를 문구만으로 추측하지 마세요.
오류: i/o timeout
원인 및 해결: 네트워크 읽기 또는 쓰기 작업이 제한 시간 안에 완료되지 않았습니다. 연결 불가, 패킷 손실, 상대 측 무응답 등이 원인일 수 있습니다. 서버는 그대로 두고 Wi-Fi와 셀룰러 네트워크를 바꿔 다시 테스트한 뒤, 연결 단계와 전송 단계 중 어디에서 시간 초과가 발생했는지 확인하세요.
오류: connection refused
원인 및 해결: 상대 측이나 중간 장비가 연결 요청을 거부한 것으로, 단순한 대역폭 부족과는 다릅니다. 주소, 포트, 서비스가 여전히 유효한지 확인하고 본인의 서비스 제공자에게 해당 포트의 서비스 상태를 문의하세요.
오류: certificate has expired
원인 및 해결: 인증서 유효 기간이 끝난 것으로 판정된 상태입니다. 기기 시간이 잘못된 경우도 확인해야 합니다. 먼저 시스템 날짜와 시간을 확인한 뒤 서비스 관리 담당자에게 인증서를 점검해 달라고 요청하세요. 속도를 높이기 위해 인증서 검증을 끄지 마세요.
본인의 구독 설정에서 최근 주소나 포트가 변경됐다면 Home에서 해당 구독을 찾아 업데이트한 뒤 현재 선택된 서버를 확인하세요. 업데이트 후에는 Config와 Global Routing이 기존 테스트 조건에 맞는지도 확인합니다. 구독 업데이트는 기존 설정을 동기화할 뿐 회선 성능을 보장하지 않습니다. 반복 테스트 중 함께 바뀌는 변수로 만들지 마세요.
7. 자주 묻는 질문과 설정 복원
Ping은 수십 ms인데 다운로드는 왜 이렇게 느린가요?
지연 시간과 처리량은 서로 다른 지표입니다. 현재 서버와 대상을 유지한 채 안정적인 전송을 일정 시간 측정하고 속도 단위, 멈춤 현상, 시간대를 기록하세요. 그런 다음 다른 대상으로 비교합니다. Ping만으로 대역폭 제한이나 대상 측 속도 제한을 배제하지 마세요.
Wi-Fi에서는 느리고 셀룰러 네트워크에서는 빠른데, 프로토콜을 잘못 선택한 건가요?
바로 단정할 수 없습니다. 같은 프로토콜과 서버를 유지하면서 접속 네트워크를 바꾸고 연결을 새로 설정하세요. 차이가 계속 재현되면 프로토콜과 네트워크를 동시에 바꾸지 말고 Wi-Fi 혼잡, UDP 제한, 경로 차이를 확인하세요.
MTU를 바로 바꾸거나 모든 옵션을 켜야 하나요?
우선 기존 값을 유지하세요. 작은 요청은 정상이지만 대용량 전송이 멈춘다는 사실만으로 MTU 문제라고 단정할 수 없습니다. 현재 터널에 맞는 매개변수나 명확한 진단 근거가 있을 때만 항목 하나를 바꾸고 다시 테스트하세요.
테스트가 끝난 뒤 어떤 설정을 복원해야 하나요?
원래 서버, Global Routing 모드, Config를 복원하세요. Settings → On Demand에서 자동 연결 조건도 원래대로 되돌린 다음 다시 연결해 자주 사용하는 대상을 확인합니다. 테스트 기록을 삭제하기 전에 최종적으로 정상 작동한 설정을 보관하세요.
본인의 서비스 제공자에게 문의할 때는 접속 네트워크, 서버 식별 정보, 프로토콜, 테스트 시간대, 대상 유형, 반복 테스트 결과를 전달하면 됩니다. 스크린샷이나 로그를 공유하기 전에는 구독 token, 비밀번호, 사용자 ID, 키를 가리세요. 회선과 부하를 여전히 구분할 수 없다면 ‘클라이언트 측 비교만으로는 판단하기 어려움’이라고 명시하는 편이 ‘속도가 느림’만 전달하는 것보다 원인 파악에 도움이 됩니다.
- 결론에는 ‘같은 서버에서 Wi-Fi는 세 번 모두 전송이 멈췄지만 셀룰러 네트워크에서는 세 번 모두 정상이었다’처럼 재현 가능한 현상을 우선 적으세요. 추측을 확정된 원인처럼 쓰지 마세요.
- Config와 Proxy 중 어떤 모드로 테스트했는지, 연결을 새로 설정했는지 기록하세요. 서로 다른 경로를 비교하는 일을 막을 수 있습니다.
- 원래 오류 문구와 발생 시간을 보관하되 전체 구독 링크나 인증 매개변수를 공개하지 마세요.