이미 이용 중인 서비스와 구독이 있고 Shadowrocket에 연결되지만 웹 페이지를 열거나 파일을 전송할 때 느린 경우에 적용할 수 있습니다. 먼저 지연 시간, 전송 속도, 첫 화면이 표시되기까지의 대기를 구분하고 테스트 조건을 고정한 뒤 로컬 네트워크, 노드, 경로, 프로토콜 순서로 점검하세요. 매번 한 가지 항목만 바꾸면 설정을 무작정 바꾸는 대신 재현 가능한 문제 기록을 남길 수 있습니다.
1. 먼저 ‘느리다’의 의미부터 구분하기: 지연 시간, 전송 속도, 첫 화면 대기
Shadowrocket의 연결 스위치가 켜져 있다는 것은 시스템 터널이 시작됐다는 뜻일 뿐, 모든 대상에 정상적으로 접속할 수 있다는 의미는 아닙니다. Home의 지연 시간 테스트도 지속적인 대역폭 측정은 아닙니다. 한 번 탐색에 성공해도 이후 발생하는 패킷 손실, 혼잡, 원격 서버의 속도 제한 또는 대상 사이트의 느린 응답을 배제할 수 없습니다.
문제가 어느 단계에서 발생하는지 먼저 확인하세요. 링크를 누른 뒤 한참 동안 아무 내용도 표시되지 않는다면 DNS 조회, 연결 설정 또는 TLS 핸드셰이크가 지연되는 것일 수 있습니다. 페이지의 텍스트는 금방 표시되지만 이미지가 계속 로드된다면 리소스 요청이나 지속적인 전송이 제한됐을 수 있습니다. 동영상이 처음에는 잘 재생되다가 반복해서 버퍼링된다면 몇 분 동안 전송 속도가 어떻게 바뀌는지 살펴보세요. 밀리초 숫자 하나만으로 경로 품질을 판단하지 마세요.
| 관찰된 증상 | 우선 확인할 항목 | 비교 방법 |
|---|---|---|
| 처음 열 때만 느림 | DNS, 연결 설정, TLS | 같은 페이지를 연속으로 세 번 열고 첫 번째와 이후 결과를 따로 기록합니다. |
| 처음에는 빠르지만 계속 느려짐 | 전송 속도, 혼잡, 서버 측 속도 제한 | 같은 파일을 60초 동안 연속 전송하고 중간 구간의 속도를 기록합니다. |
| 특정 웹사이트 하나만 느림 | 대상 서비스, 라우팅 결과, 노드 출구 | 노드는 그대로 두고 평소 이용하는 다른 대상 두 곳에서도 확인합니다. |
| 모든 앱이 동시에 느려짐 | 로컬 네트워크 연결, 현재 노드, 공통 경로 | 먼저 Wi-Fi와 Cellular를 비교한 다음 기존 노드를 비교합니다. |
단위에 유의하세요. Mbps는 초당 메가비트이고 MB/s는 초당 메가바이트입니다. 이론상 80 Mbps는 약 10 MB/s에 해당하며, 실제 앱에서는 프로토콜 오버헤드가 추가됩니다. 앱에 표시된 8 MB/s를 요금제에 적힌 80 Mbps와 비교해 속도가 10분의 1이라고 판단하지 마세요.
2. 반복 가능한 테스트 기준 만들기
시작하기 전에 현재 설정을 저장하고 Home에서 선택한 노드, Global Routing 상태, 테스트에 사용할 네트워크를 기록하세요. 아래 단계에서는 이미 보유한 설정을 사용하며, 새로운 연결 서비스를 구하는 과정은 다루지 않습니다. 서로 다른 시간대의 네트워크 부하를 설정 차이로 오해하지 않도록 테스트는 가능한 한 짧은 시간 안에 진행하세요.
-
현재 상태 기록하기
Home에서 현재 노드와 Global Routing을 기록하고 Config에서 현재 설정을 확인합니다. Settings → On Demand에 자동 연결 조건이 설정되어 있는지도 확인하되, 현재 상태만 기록하고 속도 테스트를 위해 바꿀 필요는 없습니다.
-
테스트 대상 고정하기
평소 접속할 수 있는 웹 페이지 하나와 테스트가 허용된 고정 파일 하나를 선택하세요. 매번 같은 대상을 사용하고 클라우드 동기화, 사진 업로드 및 대역폭을 많이 사용하는 다른 작업은 일시 중지해 테스트에 영향을 주지 않도록 합니다.
-
라우팅 확인하기
Home → Global Routing에서 현재 선택된 항목을 확인하세요. Config는 설정된 규칙에 따라 요청을 처리하고, Proxy는 프록시 경로를, Direct는 직접 연결 경로를 사용합니다. Scene을 사용하는 경우에는 장면 이름만 볼 것이 아니라 실제 적용된 설정도 확인해야 합니다.
-
측정 반복하기
각 조건에서 약 60초씩 세 번 측정하고 중간값에 해당하는 결과를 기록하세요. 노드, 프로토콜, 네트워크를 한꺼번에 바꾸지 마세요. 브라우저가 이전 연결이나 캐시를 재사용해 차이를 가리지 않도록 테스트 전에 대상에 새로 연결하세요.
-
원래 설정으로 복원하기
임시 비교를 마친 뒤 Global Routing과 설정을 원래대로 복원하세요. On Demand를 변경했다면 기존 조건으로 되돌린 다음 평소 사용하는 앱으로 확인해 진단 설정이 이후 사용에 영향을 주지 않도록 합니다.
3. 로컬 네트워크 점검: Wi-Fi와 Cellular 비교하기
같은 노드를 사용할 때 Wi-Fi에서는 느리고 Cellular로 전환하면 정상으로 돌아온다면 접속 네트워크와 관련된 차이가 있다는 뜻이지만, 라우터 고장이라고 바로 단정할 수는 없습니다. 두 접속 방식은 통신사 경로가 다르므로 접속 네트워크와 노드 사이에서 차이가 생겼을 수도 있습니다. 먼저 문제 범위를 좁힌 다음 라우터를 점검할지 이용 중인 서비스 제공업체에 문의할지 결정하세요.
- 접속 지점 가까이에서 다시 측정: 같은 iPhone 또는 iPad를 사용해 라우터 가까이에서 다시 측정하세요. Wi-Fi 신호 막대만으로 간섭이나 재전송 여부를 모두 알 수는 없습니다. 벽을 사이에 두면 눈에 띄게 느려지는 경우 무선 신호 범위부터 확인하세요.
- 실제 연결된 네트워크 확인: 시스템 Settings → Wi-Fi에서 연결된 네트워크를 확인하세요. Cellular로 전환할 때는 Wi-Fi 연결이 끊겼는지 확인합니다. 셀룰러 데이터를 사용할 수 없는 iPad라면 정상 작동이 확인된 다른 Wi-Fi와 비교하고 접속 방식을 기록하세요.
- 공유 대역폭 사용 줄이기: 다른 기기의 대용량 파일 업로드를 일시 중지하세요. 업로드 대역폭이 꽉 차면 웹 요청과 전송 확인 응답도 대기할 수 있어 다운로드와 상호작용이 함께 느려질 수 있습니다.
- 네트워크 접속 제한 확인: 웹 인증이 필요한 Wi-Fi라면 먼저 인증을 완료하세요. 정상적인 웹 페이지도 Direct에서 느리다면 프록시 설정을 점검하기 전에 접속 네트워크 문제부터 해결하세요.
네트워크를 전환한 뒤에는 새 요청을 시작해 확인하세요. 이미 다운로드 중인 작업만 계속 지켜보지 마세요. 기존 연결은 주소가 바뀌면서 끊기거나 재시도를 기다릴 수 있습니다. 전환 후에만 문제가 발생한다면 Shadowrocket 연결을 수동으로 끊었다가 다시 연결해 확인하세요. On Demand는 주로 자동 연결 시점을 정하는 기능이지 대역폭을 높이는 스위치가 아닙니다.
4. 노드와 경로 점검: 서버 차이와 시간대별 차이 구분하기
여기서 ‘노드’는 Home에 등록된 서버 연결 설정을 뜻하고, ‘경로’는 기기에서 해당 서버까지, 이어서 대상 서비스까지 이어지는 네트워크 경로를 뜻합니다. 노드를 바꾸면 출구 위치와 네트워크 경로도 달라지는 경우가 많습니다. 따라서 ‘다른 노드로 바꾸니 빨라졌다’는 결과만으로는 차이가 변경된 경로와 관련 있음을 알 수 있을 뿐, 이전 서버의 성능이 부족하다고 단정할 수 없습니다.
이미 사용 중인 노드 가운데 두 개를 골라 비교하고, 가능하면 프로토콜, 대상, 로컬 네트워크를 동일하게 유지하세요. 특정 노드 하나만 계속 느리다면 서비스 상태, 사용량 제한, 설정 변경 여부를 확인하세요. 여러 노드가 저녁에만 느려지고 낮에는 정상이라면 모든 설정을 즉시 다시 만들기보다 시간대를 기록하세요. 공유 경로의 혼잡, 진입점 부하, 대상 서비스의 부하 모두 이런 현상을 일으킬 수 있습니다.
| 고정 조건 | 변경 항목 | 측정 예시 | 판단할 수 있는 내용 |
|---|---|---|---|
| 같은 Wi-Fi, 같은 파일 | 노드 A에서 노드 B로 변경 | 0.8 MB/s에서 5.2 MB/s로 변경 | 두 노드와 각 경로를 계속 비교하고 로컬 DNS는 우선 변경하지 않습니다. |
| 노드 A, 같은 파일 | Wi-Fi에서 Cellular로 변경 | 0.8 MB/s에서 4.6 MB/s로 변경 | 접속 네트워크와 노드까지의 경로를 우선 확인합니다. |
| 같은 노드, 같은 Wi-Fi | 14:00과 21:00 | 5.0 MB/s에서 0.7 MB/s로 변경 | 시간대와의 관련성이 의심되므로 여러 날 재측정해 판단을 뒷받침해야 합니다. |
이용 중인 서비스 제공업체의 계정 페이지에서 데이터 소진, 만료 또는 속도 제한 여부도 확인하세요. Shadowrocket의 Data 수치와 서비스 제공업체의 과금 기준은 다를 수 있으므로 기기에 표시된 누적 수치 하나만으로 계정 페이지의 제한을 부정할 수 없습니다. 기존 구독을 갱신해야 한다면 먼저 설정을 저장하고 원래 구독 경로를 통해 갱신한 뒤 선택된 노드의 설정이 실제로 바뀌었는지 확인하세요.
5. 프로토콜 점검: 전송 방식 차이를 살피기 전에 설정 확인하기
Home에서 현재 서버의 편집 화면을 열고 기존 서비스 제공업체가 안내한 Type, 주소, 포트를 대조하세요. 포트 번호만으로 프로토콜이나 속도를 판단할 수는 없습니다. 서버가 443을 지정했다면 443을 입력해야 하며, 다른 포트가 흔히 쓰인다는 이유만으로 임의로 바꾸면 안 됩니다. 로컬 포트를 바꿔도 서버가 해당 서비스를 자동으로 제공하지는 않습니다.
- Shadowsocks: 암호화 방식, 비밀번호, 서버에서 요구하는 추가 설정을 확인하세요. 설정이 잘못된 경우 정상적으로 느린 상태라기보다 연결 또는 데이터 전송 실패로 나타나는 경우가 많습니다.
- VMess / VLESS: UUID, 전송 방식, TLS 설정을 확인하세요. WebSocket을 사용하는 경우 Host와 Path도 각각 대조해야 합니다. UUID가 같다고 해서 다른 설정을 생략할 수 있는 것은 아닙니다.
- Trojan: 비밀번호, TLS, Server Name을 확인하세요. 인증서 도메인, 서버 주소, 전송 진입점은 서로 다른 값일 수 있으므로 기존 설정에 따라 입력하세요.
- Hysteria2: QUIC 기반 전송을 사용하므로 네트워크 경로에서 해당 UDP 통신이 허용되어야 합니다. 서비스 제공업체가 대역폭 값을 안내한 경우 그 설명에 따르고 추정한 값을 임의로 크게 설정하지 마세요.
- WireGuard: 키, Endpoint, 서버에서 제공한 기타 설정을 확인하세요. MTU를 첫 번째 최적화 항목으로 삼지 마세요. 특정 크기의 데이터에서 전송이 멈추는 등 단서가 있을 때만 서비스 제공업체의 안내에 따라 항목별로 확인하세요.
프로토콜 비교는 서버가 해당 진입점을 실제로 지원하는 경우에만 가능합니다. 테스트를 위해 Type에서 VLESS를 Trojan으로 바꾸기만 해서는 안 됩니다. 두 진입점을 모두 사용할 수 있더라도 서버가 서로 다를 수 있어 측정된 차이가 프로토콜 때문이라고 단정할 수 없습니다. 먼저 설정 전체와 네트워크 조건을 비교한 다음 프로토콜 오버헤드를 검토하세요.
오류: i/o timeout
원인 및 해결: 네트워크 읽기 또는 쓰기 단계 중 하나가 제한 시간 안에 완료되지 않았다는 뜻입니다. 이 메시지만으로 문제 위치를 특정할 수는 없습니다. 같은 기록의 대상과 전후 맥락을 확인하고 주소와 포트를 대조한 뒤 다른 로컬 네트워크에서 같은 노드로 재확인하세요.
오류: connection refused
원인 및 해결: 대상 포트에서 연결을 거부했습니다. 서비스가 해당 포트에서 대기 중이지 않거나 중간 장치가 연결을 능동적으로 거부했을 수 있습니다. 기존 설정에서 포트를 확인하고 서비스 제공업체에 진입점 상태를 문의하세요. 반복 측정으로 해결하려고 하지 마세요.
오류: certificate verify failed
원인 및 해결: TLS 인증서 검증에 실패했습니다. 정확한 원인은 전체 오류 내용을 함께 확인해야 합니다. 시스템 날짜와 시간, Server Name, 서버 인증서 상태를 확인하고 속도를 높이기 위해 인증서 검증을 끄지 마세요.
오류 문구는 연결 구성 요소에 따라 다르게 표시될 수 있으므로 실제 기록을 기준으로 확인하세요. 오류가 계속되면 먼저 연결 실패로 처리해야 합니다. 반복 재시도로 대기 시간이 길어진 것을 사용 가능한 대역폭이 낮은 것으로 오해하지 마세요.
6. 규칙과 DNS 점검: 요청이 실제로 거치는 경로 확인하기
같은 노드에서 Proxy를 사용할 때는 정상인데 Config로 돌아오면 느리다면 현재 Config의 규칙과 DNS 동작을 우선 확인하세요. 규칙은 요청 처리 방식을 정하고 DNS는 도메인 조회 방식을 정하므로 두 기능은 같은 스위치가 아닙니다. 설정, DNS 서버, 노드를 한 번에 모두 바꾸면 어떤 변경이 효과를 냈는지 판단할 수 없습니다.
- 규칙 적용 순서 확인:
DOMAIN-SUFFIX는 도메인 접미사를 기준으로,IP-CIDR은 주소 범위를 기준으로,GEOIP는 IP 지리 데이터베이스를 기준으로 일치 항목을 찾습니다.FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 먼저 적용되는 규칙에 걸리면 테스트 중인 노드를 거치지 않을 수 있습니다. - 실제 요청 확인: 웹 페이지 본문, 이미지, 동영상은 서로 다른 도메인에서 제공될 수 있습니다. 주 도메인 하나가 프록시를 사용한다고 해서 페이지의 모든 리소스도 같은 경로를 이용한다고 볼 수는 없습니다.
- 이름 조회와 전송 구분: 첫 요청만 오래 기다리고 이후 전송은 정상이라면 DNS 조회와 핸드셰이크 단계를 확인하세요. 연결이 이미 설정된 뒤에도 계속 느리다면 DNS만 바꿔서는 설명할 수 없습니다.
- 기존 설정 보관: 규칙을 변경하기 전에 원본을 저장하고 매번 대상과 관련된 항목 하나만 조정하세요. 테스트를 위해 FINAL을 임의로 이동하거나 규칙 전체를 삭제하지 마세요.
일반적인 속도 테스트에 HTTPS 도메인 대신 IP 주소를 직접 사용하는 것은 권장하지 않습니다. 인증서 검증, TLS Server Name, 가상 호스트, CDN 경로가 달라져 테스트 대상 자체가 바뀔 수 있습니다. 정상 도메인으로 요청하고 연결 기록을 확인해 DNS 조회가 완료됐는지, 어떤 정책이 적용됐는지 판단하세요.
7. 자주 묻는 질문과 점검 마무리
지연 시간이 수십 밀리초에 불과한데 다운로드는 왜 느린가요?
지연 시간은 짧은 순간의 응답 속도를 나타내지만 다운로드에는 지속적인 전송이 필요합니다. 노드와 파일을 고정해 60초 동안 측정하고 세 차례 반복하세요. 전송 속도는 낮은데 지연 시간은 안정적이라면 속도 제한, 부하, 출구 경로를 계속 확인하세요. 지연 시간만으로 순위를 매겨 결론 내리지 마세요.
Proxy로 전환하면 빨라지는데 계속 이렇게 사용해도 되나요?
먼저 규칙 점검을 위한 단서로 보세요. Home → Global Routing의 비교 결과를 기록하고 Config에서 대상 요청에 일치하는 규칙을 확인하세요. 진단이 끝나면 평소 사용 목적에 맞는 설정으로 복원하세요.
네트워크를 바꾸고 멈췄는데 다시 연결하면 해결되나요?
먼저 새 요청으로 확인해 기존 연결이 재시도를 기다리는 문제인지 살펴보세요. 그런 다음 Settings → On Demand에서 자동 연결 조건을 확인하고 수동 연결과 자동 연결의 차이를 기록하세요. 반복해서 재연결하는 것을 지속적인 속도 개선 방법으로 여기지 마세요.
사용 중인 노드가 모두 느리다면 다음 단계에서 어떤 정보를 제출해야 하나요?
테스트 시간, 접속 유형, 대상 유형, 세 차례 측정값, 이미 진행한 단일 변수 비교 결과를 제공하세요. 오류 기록을 첨부할 때는 비밀번호, UUID, 키, 구독 링크의 token을 가리세요. 서비스 상태는 이용 중인 서비스 제공업체에 문의하세요.
점검을 마친 뒤에는 “같은 노드와 대상에서 Wi-Fi는 세 차례 모두 느렸고 Cellular에서는 정상으로 돌아옴”처럼 재현 가능한 조건으로 결론을 기록하세요. “Shadowrocket이 매우 느림”이라고만 적지 마세요. 특정 대상에서만 문제가 발생한다면 해당 대상과 출구의 관계를 계속 확인하고, 모든 대상에서 문제가 발생한다면 공통된 접속 환경이나 노드 경로를 점검하세요. 비교 결과가 나오기 전에는 원인을 단정하지 마세요.