이 글은 Shadowrocket에 본인 구독을 추가하고 연결도 되지만 웹페이지 로딩이나 전송 속도에 문제가 있는 경우를 위한 안내입니다. 먼저 테스트 대상과 Global Routing 설정을 고정한 뒤, 네트워크 연결, 프로토콜 설정, 전송 경로, 노드 리소스를 차례로 확인하세요. 매번 한 가지 조건만 바꾸고 반복 테스트하면 지속적인 병목과 일시적인 변동을 구분하는 데 도움이 됩니다.
지연 시간, 첫 화면 로딩, 지속 전송 속도를 구분하세요
‘속도가 느리다’는 현상은 크게 세 가지로 나뉩니다. 연결이 성립되기까지 오래 걸리거나, 웹페이지의 첫 화면이 늦게 뜨거나, 파일 전송이 시작된 뒤에도 전송량이 계속 낮은 경우입니다. 지연 시간 테스트는 특정 방식과 대상에 대한 응답 시간을 보여줄 뿐, 사용 가능한 대역폭을 의미하지 않습니다. Home의 Connectivity Test는 연결 가능성을 확인하는 보조 수단입니다. 테스트에 성공해도 모든 웹사이트와 대용량 파일 전송이 정상이라고 단정할 수는 없습니다.
접근 권한이 있고 파일 크기가 일정한 HTTPS 리소스를 테스트 대상으로 정해 매번 같은 웹사이트를 이용하세요. 세 번 연속 테스트하면서 시작 시각, 첫 데이터가 표시되기까지 걸린 시간, 안정적인 전송 속도를 각각 기록합니다. 아래는 기록 방법의 예시이며, 실제 제품 측정 결과나 속도 보장이 아닙니다.
| 증상 | 기록 예시 | 우선 확인할 항목 |
|---|---|---|
| 지연 시간은 짧지만 다운로드가 느림 | 응답 약 80 ms, 지속 전송 약 300 KB/s | 경로 혼잡, 노드 속도 제한, 대상 사이트 속도 제한 |
| 처음 열 때 느리고 이후에는 정상 | 약 5초 대기 후 약 5 MB/s로 안정 | DNS, 핸드셰이크, 연결 재설정 |
| 전송이 간헐적으로 멈춤 | 세 번 연속 몇 초 동안 데이터가 수신되지 않음 | 무선 간섭, 패킷 손실, 네트워크 전환 |
수치를 비교하기 전에 단위를 통일하세요. 이론상 8 Mbps는 약 1 MB/s입니다. 실제 전송 속도에는 프로토콜 오버헤드도 영향을 줍니다. 속도 테스트 페이지의 Mbps와 파일 다운로드 페이지의 MB/s를 그대로 비교하지 마세요. 지연 시간이 가장 낮게 나온 노드가 전송 속도도 가장 빠르다고 단정할 수 없습니다.
1단계: 네트워크와 테스트 조건 고정
네트워크 연결 품질은 이후의 모든 판단에 영향을 줍니다. Wi-Fi 신호가 가득 차 있어도 기기가 강한 무선 신호를 받고 있다는 뜻일 뿐, 라우터의 업링크나 가정용 인터넷 회선, 현재 네트워크 출구의 혼잡 여부까지 보장하지는 않습니다. 사진 동기화, 시스템 업데이트, 기타 대용량 작업을 먼저 일시 중지한 뒤 비교 테스트를 시작하세요.
-
현재 상태 기록
Home에서 현재 노드와 Global Routing 선택 상태를 기록하고, Settings → On Demand에서 활성화 여부를 확인하세요. 연결을 끊은 상태의 기준 속도를 테스트하려면 자동 연결을 잠시 꺼서 설정이 자동으로 복원되지 않게 합니다. 테스트가 끝나면 원래 설정으로 되돌리세요.
-
기준 속도 측정
Shadowrocket 연결을 끄고 현재 네트워크에서 직접 접속할 수 있는 고정 리소스를 세 번 테스트하세요. 이 상태에서도 느리다면 프로토콜을 바로 바꾸지 말고 라우터, 무선 간섭, 인터넷 회선 연결부터 확인하세요.
-
테스트 조건 고정
Home으로 돌아가 Global Routing을 열고 현재 Proxy, Direct, Config, Scene 중 어떤 설정인지 확인하세요. 규칙의 영향을 분리하려면 Proxy를 임시로 선택하고 특정 노드에 다시 연결해 테스트한 뒤 원래 설정으로 되돌리면 됩니다.
-
네트워크 연결 변경
노드와 테스트 대상을 그대로 둔 채 Wi-Fi와 셀룰러 네트워크에서 각각 테스트하세요. 네트워크를 바꾼 뒤에는 연결이 안정될 때까지 기다렸다가 다시 연결하고, 전송 중에는 네트워크를 전환하지 마세요. 셀룰러 네트워크를 사용하기 전에 데이터 잔여량도 확인하세요.
같은 노드가 셀룰러 네트워크에서는 정상이고 Wi-Fi에서 계속 느리다면, 해당 Wi-Fi의 연결이나 출구 또는 노드까지의 경로에 문제가 있을 가능성이 큽니다. 그렇다고 노드 서버의 장애가 입증되는 것은 아닙니다. 두 네트워크 모두 느리다면 설정과 전송 경로를 계속 확인하세요. On Demand는 조건에 따라 연결을 설정하는 기능이지, 대역폭을 높이는 옵션이 아닙니다.
2단계: 프로토콜 설정을 하나씩 확인하고 TLS를 짐작으로 바꾸지 마세요
설정 오류는 대개 연결 실패, 핸드셰이크 실패 또는 반복 재시도를 일으키며, 웹페이지가 오래 기다리는 현상으로 나타나기도 합니다. 먼저 Home에서 현재 노드의 편집 화면을 열고 본인 서비스 제공업체의 설정과 항목별로 비교하세요. 구독으로 추가한 노드는 구독을 업데이트한 뒤 다시 테스트하는 것이 좋습니다. 직접 수정하기 전에는 기존 값을 기록해 두세요. 그래야 업데이트로 수정 내용이 덮여 결과를 잘못 판단하는 일을 막을 수 있습니다.
| 프로토콜 또는 옵션 | 확인할 항목 | 자주 하는 오판 |
|---|---|---|
| Trojan 및 TLS | 주소, 포트, Password, SNI, 인증서 요구 사항 | 연결 주소와 SNI가 반드시 같지는 않습니다. 서비스 제공업체의 설정을 기준으로 확인하세요. |
| VMess / VLESS | 인증 정보, 전송 방식, 해당하는 경우 Host, Path, TLS | 노드 이름이 해석된다고 해서 전송 설정이 모두 올바른 것은 아닙니다. |
| Shadowsocks | 암호화 방식, Password, 포트, 서버에서 요구하는 플러그인 설정 | 비밀번호가 맞아도 암호화 방식이 맞지 않으면 연결에 실패할 수 있습니다. |
| Hysteria2 / WireGuard | 서버에 맞는 인증 정보 또는 키, 주소, 포트 설정 | 둘 다 UDP를 사용하므로 현재 네트워크의 UDP 처리 방식도 연결에 영향을 줍니다. |
포트는 설정에 기재된 그대로 입력하세요. 예를 들어 서버에서 포트 8443을 지정했다면 TLS에서 흔히 쓰이는 포트가 443이라는 이유로 443으로 바꾸면 안 됩니다. 포트 번호만으로 속도 등급을 알 수도 없습니다. TLS 노드에서는 인증서 검증을 유지하세요. 속도가 느리다는 이유로 Allow Insecure를 켜는 것을 일반적인 해결책으로 삼지 마세요. 인증서 문제가 있다면 iPhone 또는 iPad의 시스템 시간도 확인하세요.
연결 기록에 아래와 같은 영문 오류가 표시되면 의미를 바탕으로 원인 범위를 좁힐 수 있습니다. 연결 단계에 따라 전체 메시지는 다를 수 있으므로, 단어 하나만 보고 서버 문제라고 단정하지 마세요.
오류: i/o timeout
원인 및 해결 방법: 특정 단계의 읽기 또는 쓰기가 제한 시간 안에 완료되지 않은 상태입니다. 네트워크, 전송 경로 또는 서버가 원인일 수 있습니다. 오류 전후의 연결 단계를 기록하고 노드는 그대로 둔 채 네트워크를 바꿔 다시 테스트하세요.
오류: connection refused
원인 및 해결 방법: 대상 장치나 중간 장치가 연결을 거부한 상태입니다. 해당 포트에서 서비스가 대기 중이지 않거나 접근이 거부된 경우가 흔합니다. 먼저 주소와 포트를 확인한 뒤 서비스 제공업체에 해당 서비스의 상태를 문의하세요.
오류: certificate verify failed
원인 및 해결 방법: TLS 인증서 검증에 실패한 상태입니다. 이름, 인증서 체인 또는 시스템 시간이 원인일 수 있습니다. SNI와 시스템 날짜를 확인하고 서비스 제공업체의 설정과 대조한 뒤, 검증 기능은 유지한 채 원인을 바로잡으세요.
3단계: 교차 테스트로 경로 혼잡과 패킷 손실 확인
여기서 ‘경로’란 기기가 연결된 네트워크부터 노드 서버까지 데이터가 이동하는 경로를 말합니다. 이 과정에는 네트워크 접속, 네트워크 간 연동, 중계 구간이 포함될 수 있으며 품질은 시간에 따라 달라집니다. 한 번 연결에 성공했다고 혼잡이 없다고 볼 수 없고, 특정 대상 사이트의 속도가 느리다고 전체 경로의 대역폭이 부족하다고 단정할 수도 없습니다.
- 같은 노드, 다른 네트워크: 노드와 리소스를 고정하고 Wi-Fi와 셀룰러 네트워크만 바꾸세요. 차이가 반복해서 나타난다면 각 네트워크 출구에서 해당 노드까지의 경로가 다른지 우선 확인하세요.
- 같은 네트워크, 다른 시간대: 비교적 한산한 시간대와 평소 문제가 발생하는 시간대에 각각 세 번 테스트하세요. 특정 시간대에 주로 속도가 떨어진다면 프로토콜을 바로 바꾸기보다 혼잡 가능성을 확인할 항목으로 두세요.
- 같은 노드, 다른 대상: 서로 별개인 고정 리소스 두 곳에 접속해 비교하세요. 한 대상에서만 느리다면 대상 사이트의 속도 제한, 지역별 연결 경로 배정, 노드에서 대상 사이트까지의 경로를 추가로 살펴보세요.
- 같은 네트워크, 다른 노드: 본인이 이미 보유한 구독에서 사용 가능한 다른 노드를 선택하고 리소스와 테스트 방식은 그대로 유지하세요. 여러 다운로드를 동시에 실행하면 추가적인 경합이 발생하므로 피하세요.
웹페이지는 열리지만 동영상이나 대용량 파일 전송이 주기적으로 멈춘다면 최저 지연 시간만 보지 말고 패킷 손실과 전송 속도의 안정성도 확인하세요. UDP에 의존하는 프로토콜을 사용하는 경우 다른 네트워크로 바꿨을 때 문제가 해결된다면, 서비스 제공업체에 현재 네트워크 환경에서 UDP에 접속할 수 있는지 확인해 달라고 요청하세요. MTU, DNS, 전송 설정을 한꺼번에 바꾸지 마세요. 여러 옵션을 동시에 변경하면 비교 결과를 해석하기 어렵습니다.
4단계: 노드 리소스, 요금제 제한, 대상 사이트 병목 구분
앞의 세 단계를 마친 다음 특정 노드를 살펴보세요. 노드에 연결할 수 있다고 해서 출구 대역폭, 동시 연결 리소스, 대상 사이트까지의 연결이 충분하다는 뜻은 아닙니다. 지연 시간은 정상인데 전송 속도가 계속 낮다면 노드 부하, 요금제 속도 제한, 데이터 한도 또는 대상 사이트의 제한이 원인일 수 있습니다. 클라이언트만으로는 서버 CPU나 출구 사용량 같은 내부 상태를 정확히 측정하기 어렵습니다.
- 본인 서비스 제공업체의 계정 정보에서 유효 기간, 잔여 데이터, 약정된 속도 제한을 확인하세요. 제한을 우회하려고 구독을 반복해서 새로 고치지는 마세요.
- 기존 구독을 업데이트한 뒤에도 같은 노드를 테스트하는지 확인하세요. 노드 이름이나 주소가 바뀌면 이전 결과와 비교할 수 없게 됩니다.
- 같은 네트워크에서 기존 구독의 노드 두 개를 비교하세요. 여러 대상에서 한 노드만 계속 느리다면 해당 노드의 테스트 기록을 서비스 제공업체에 전달하세요.
- 여러 노드에서 특정 웹사이트만 느리다면 다른 대상에서는 정상인 비교 결과를 함께 기록하고, 대상 사이트와 관련 출구 경로를 우선 확인하세요.
기록을 전달할 때는 테스트 시각과 시간대, Wi-Fi 또는 셀룰러 네트워크, 프로토콜, Global Routing 설정, 대상 유형, 세 번의 테스트 결과, 오류 메시지를 포함하세요. 구독 전체 링크, Password, 개인 키, 인증 정보는 보내지 마세요. 스크린샷을 공유하기 전에도 해당 정보를 가리세요. 클라이언트 구매 내역과 네트워크 경로 상태는 서로 다른 정보이며, 구매 상태로 경로의 속도 제한 여부를 판단할 수 없습니다.
자주 묻는 질문: 낮은 지연 시간, 자동 연결, 설정 복원
지연 시간이 수십 ms뿐인데 다운로드는 왜 느린가요?
지연 시간 테스트는 특정 탐색 요청의 응답을 측정하며 지속적인 전송 속도를 측정하지 않습니다. 큰 리소스 하나를 정해 세 번 연속 테스트하고 다른 대상의 결과와 비교하세요. Global Routing 설정과 선택한 노드가 바뀌지 않았는지도 확인한 뒤 대역폭 또는 대상 사이트의 제한 여부를 판단하세요.
On Demand를 켜면 더 빨라지나요?
Settings → On Demand는 자동 연결 조건을 설정하며 경로 대역폭을 늘려 주지는 않습니다. 네트워크를 전환한 뒤 재연결하는 과정에서 대기가 발생한다면 같은 네트워크에 연결한 상태에서 수동으로 연결해 다시 테스트하세요. 재연결에 걸리는 시간과 안정된 다운로드 속도를 혼동하지 마세요.
Proxy에서는 정상인데 Config에서 느립니다. 계속 Proxy를 써야 하나요?
장기간 사용할 설정을 먼저 바꿀 필요는 없습니다. 문제가 발생하는 도메인을 기록하고 요청 기록에서 실제 아웃바운드가 무엇인지 확인한 뒤 Config에서 먼저 일치한 규칙과 FINAL을 점검하세요. 관련 규칙이나 정책을 수정한 다음 Config로 되돌려 같은 대상을 다시 테스트하세요.
테스트가 끝난 뒤 어떤 설정을 복원해야 하나요?
원래 사용하던 Global Routing 설정, 현재 노드, Settings → On Demand 상태로 되돌리세요. 설정을 수정했다면 미리 기록한 값을 기준으로 복원하세요. 유효한 비교 결과는 보관하되, 한 번 우연히 빨라졌다는 이유로 검증되지 않은 변경 사항을 여러 개 저장하지 마세요.
문제 해결의 목표는 더 빨라 보이는 옵션 하나를 찾는 것이 아니라 차이를 재현할 수 있는지 확인하는 것입니다. 어떤 네트워크, 노드, 대상, 시간대에서 문제가 발생하는지 파악하세요. 근거가 아직 부족하다면 설정과 기록을 먼저 보관한 뒤 서비스 제공업체에 꼭 필요한 정보만 전달하세요. 설정을 모두 지우고 다시 추가하는 것보다 원인을 찾기 쉽습니다.