이 글은 Shadowrocket에서 자체 서비스 제공업체의 설정을 가져온 뒤 연결은 되지만 웹 응답이나 파일 전송이 느린 사용자를 위한 안내입니다. 점검할 때는 테스트 대상과 시간을 고정하고, 서버 상태, 전송 회선, 프로토콜 매개변수, 로컬 네트워크를 차례로 확인하세요. Global Routing, Connectivity Test와 반복 테스트 결과를 사용하면 문제 위치를 좁힐 수 있습니다.
먼저 ‘느리다’의 기준을 정하고 테스트 조건을 고정하세요
‘연결됨’은 시스템 터널이 설정되었다는 뜻일 뿐, 기기에서 대상 웹사이트까지의 전체 경로가 정상이라는 의미는 아닙니다. 하나의 요청은 보통 로컬 Wi‑Fi 또는 셀룰러 네트워크, 시스템 VPN 터널, Shadowrocket 규칙 매칭, 사용자가 보유한 서버, 대상 사이트를 차례로 거칩니다. 어느 한 구간에서 대기, 패킷 손실 또는 DNS 응답 지연이 발생하면 페이지가 계속 로딩되는 것처럼 보일 수 있습니다.
먼저 세 가지 현상을 구분하세요. 첫째는 시작 지연입니다. 웹페이지가 오래 빈 화면으로 있다가 이후 정상 속도로 로드되면 DNS, 연결 설정 또는 첫 바이트 대기와 관련 있을 수 있습니다. 둘째는 지속적인 저속입니다. 큰 파일이 처음부터 끝까지 느리다면 회선 처리량, 서버 부하, 로컬 네트워크를 우선 확인하세요. 셋째는 속도 변동입니다. 속도가 빠르다 느려지고 동영상 화질이 자주 바뀐다면 패킷 손실, 무선 간섭, 피크 시간대 부하를 살펴보세요.
테스트 사이트 고정
안정적으로 접속되는 동일한 웹페이지와 크기가 명확한 동일한 테스트 파일을 선택하세요. 대상 사이트마다 대역폭과 캐시 정책이 다르므로 서로 다른 사이트를 직접 비교하지 마세요.
설정 고정
Home에서 동일한 서버, 동일한 Global Routing 상태, 동일한 네트워크 연결 방식을 유지하세요. 먼저 3회 연속 테스트하고 첫 응답 시간과 지속 전송 속도를 기록합니다.
백그라운드 작업 중지
사진 동기화, 앱 업데이트, 클라우드 백업 및 기타 대용량 작업을 일시 중지하세요. 그렇지 않으면 시스템 대역폭 경쟁으로 테스트 결과를 비교하기 어려워집니다.
변수는 하나씩 변경
매번 한 가지 요소만 조정하세요. 예를 들어 서버만 바꾸거나 Wi‑Fi에서 셀룰러 네트워크로만 전환합니다. 여러 매개변수를 동시에 바꾸면 무엇이 영향을 주었는지 알 수 없습니다.
1단계: 서버 부하와 서버 응답 확인
서버 단계에서는 사용자가 보유한 서버가 연결을 제때 받아 데이터를 처리할 수 있는지 확인합니다. 지연 시간이 짧다고 처리량이 반드시 높은 것은 아닙니다. Connectivity Test의 밀리초 값은 주로 한 번의 연결 또는 요청 왕복 시간을 나타내며, 지속 다운로드 속도는 서버 외부 대역폭, 동시 접속 부하, 대상 사이트 제한에도 영향을 받습니다.
Home의 서버 목록에서 현재 서버에 Connectivity Test를 실행하고 성공 여부, 시간 초과 여부, 지연 시간이 크게 변하는지를 기록하세요. 인터페이스 배치에 따라 테스트 메뉴가 서버 작업 메뉴 안에 있을 수 있으므로 앱에 현재 표시되는 항목을 기준으로 하세요. 예를 들어 결과가 85 ms, 92 ms, 410 ms라면 세 번째 결과가 앞의 두 번과 크게 달라 회선 또는 서버 변동을 의심할 수 있습니다. 매번 빠르게 완료되지만 큰 파일 전송만 느리다면 회선 처리량을 계속 확인하세요.
현재 서버 확인
Home으로 돌아가 실제로 선택된 서버 항목을 확인하세요. 구독 그룹 이름을 현재 외부 연결 서버로 착각하지 않도록 주의합니다.
연결 테스트 실행
동일한 서버에서 Connectivity Test를 3회 연속 실행하세요. 각 테스트 사이에 약 5초 간격을 두고 성공 여부와 지연 변동 범위를 기록합니다.
같은 그룹 내 교차 검증
자체 서비스 제공업체 설정에서 사용 가능한 것으로 확인된 다른 서버를 선택한 뒤, 서버만 바꿔 동일한 테스트를 반복하세요. 새 서버가 정상으로 돌아오면 문제는 원래 서버 또는 그 상위 경로에 있을 가능성이 큽니다.
구독 상태 확인
Home에서 아래로 당겨 기존 구독을 업데이트하고, 서버 주소와 포트가 서비스 제공업체가 현재 제공하는 값인지 확인하세요. 예시 구독 주소는 https://example.com/sub?token=xxxx와 같은 형식으로만 설명해야 하며, 실제 정보는 자신의 서비스 제공업체에 확인하세요.
오류: The request timed out
원인 및 해결:정해진 시간 안에 연결 응답을 받지 못한 상태입니다. 서버의 일시적인 혼잡, 회선 패킷 손실 또는 서버 연결 불가가 원인일 수 있습니다. 다른 조건을 유지한 채 테스트를 반복한 다음, 자체 설정의 다른 사용 가능한 서버로 바꿔 교차 확인하세요.
오류: Connection reset by peer
원인 및 해결:원격 서버 또는 중간 네트워크가 연결을 강제로 재설정한 상태입니다. 먼저 서버 주소, 포트, 비밀번호, UUID와 전송 매개변수를 확인하세요. 설정이 올바른데도 계속 발생하면 해당 서비스 제공업체에 서버 측 상태를 확인해 달라고 요청하세요.
오류: Failed to load subscription
원인 및 해결:구독 링크가 만료되었거나 응답 시간이 초과되었거나 접근 조건이 바뀌었을 수 있습니다. 링크가 자신의 서비스 제공업체에서 발급된 것인지 확인하고 Home에서 아래로 당겨 새로 고침하세요. 계속 실패하면 서비스 제공업체에 링크의 유효성을 확인하세요.
서버 이름에 포함된 지역명만 보고 속도를 판단하지 마세요. 이름은 설정 라벨일 뿐 실제 경로, 부하, 외부 연결 품질을 직접 나타내지 않습니다. 반복 테스트 성공 여부, 지연 변동, 첫 응답 시간, 고정 파일의 지속 전송 속도를 함께 확인해야 합니다.
2단계: 회선 지연, 패킷 손실, 피크 시간대 혼잡 확인
회선은 기기와 서버 사이를 지나는 네트워크 경로입니다. 서버 자체의 부하가 정상이어도 접속 네트워크, 통신사 경로, 시간대에 따라 큰 차이가 생길 수 있습니다. 대표적인 회선 문제로는 안정적이지만 높은 지연 시간, 갑작스러운 지연 증가, 간헐적인 시간 초과, 작은 웹페이지는 열리지만 장시간 전송 속도가 계속 떨어지는 현상이 있습니다.
회선 테스트의 핵심은 시간대와 접속 방식을 비교하는 것입니다. Shadowrocket 서버와 프로토콜을 그대로 둔 채 Wi‑Fi에서 한 차례 테스트하고, 셀룰러 네트워크로 전환해 다시 테스트하세요. 한 가지 접속 방식에서만 뚜렷하게 느리다면 프로토콜 매개변수를 바로 바꾸기보다 해당 로컬 네트워크와 서버까지의 경로를 먼저 확인하세요.
- 지연 시간이 짧고 속도가 안정적:서버와 회선의 현재 상태는 대체로 정상입니다. 특정 웹사이트만 느리다면 대상 사이트 또는 규칙 매칭을 확인하세요.
- 지연 시간이 높지만 안정적:경로가 멀거나 우회 경로가 많을 수 있습니다. 상호작용 응답은 느려도 지속 전송 자체가 반드시 불가능한 것은 아닙니다.
- 지연 시간이 수백 밀리초 이상 변동:동영상 버퍼링과 페이지 리소스의 단계적 로딩이 나타날 수 있습니다. 패킷 손실, 무선 신호, 피크 시간대 혼잡을 확인하세요.
- 테스트가 간헐적으로 시간 초과:연결이 끊기는 구간이 있다는 뜻이므로, 성공한 한 번의 최저 지연 시간만 보지 마세요.
- 낮에는 정상이고 특정 시간대에 느림:시간대별 부하 또는 네트워크 혼잡에 가깝습니다. 같은 시간에 여러 날 연속으로 다시 테스트하세요.
| 관찰 결과 | 우선 판단 | 다음 조치 |
|---|---|---|
| Wi‑Fi는 느리지만 셀룰러 네트워크는 정상 | 라우터, 무선 간섭 또는 광대역 경로 | 라우터 가까이에서 주파수 대역을 바꾸고 네트워크 장비를 재시작한 뒤 다시 테스트 |
| 두 네트워크 모두 하나의 서버에서만 느림 | 서버 부하 또는 서버 상위 회선 | 자체 설정의 다른 서버로 교차 검증 |
| 모든 서버가 하나의 웹사이트에서만 느림 | 대상 사이트, DNS 또는 규칙 매칭 | 요청이 예상대로 DIRECT 또는 프록시 정책을 사용하는지 확인 |
| 저녁에 전반적인 속도 저하 | 피크 시간대 혼잡 | 아침과 저녁에 동일한 조건으로 각각 3회 측정하고 중간값 비교 |
3단계: 프로토콜과 전송 매개변수 오버헤드 확인
Shadowrocket은 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard 등의 설정 유형을 지원합니다. 프로토콜마다 핸드셰이크 방식, 암호화 처리, 전송 계층, 패킷 손실 복구 방식이 다르지만 서버 측 설정과 분리해 특정 프로토콜이 반드시 더 빠르다고 판단할 수는 없습니다. 클라이언트 매개변수는 서버 측과 항목별로 일치해야 합니다.
프로토콜 문제를 회선 저하로 잘못 판단하는 경우가 많습니다. 전송 방식, TLS, SNI, Path, 비밀번호 또는 UUID가 일치하지 않으면 핸드셰이크 반복, 연결 재설정, 연결 불가가 발생할 수 있습니다. UDP가 제한된 환경에서는 UDP 특성을 사용하는 설정의 속도 측정이 불안정할 수 있습니다. 이때 Global Routing을 반복해서 바꿔도 매개변수 오류는 해결되지 않습니다.
| 설정 유형 | 중점 점검 항목 | 일반적인 판단 기준 |
|---|---|---|
| Shadowsocks | 서버 주소, 포트, 비밀번호 및 암호화 방식 | 한 항목이라도 일치하지 않으면 연결 실패 또는 즉시 연결 해지로 이어지는 경우가 많음 |
| VMess / VLESS | UUID, TLS, SNI, Transport 및 Path | 핸드셰이크 시간 초과 또는 재설정 시 전체 매개변수 조합을 먼저 확인 |
| Trojan | 비밀번호, TLS, SNI 및 인증서 관련 설정 | TLS 단계의 이상은 연결 설정 불가로 나타날 수 있음 |
| Hysteria2 | UDP 연결 가능 여부, 인증 정보 및 서버 매개변수 | 제한된 네트워크에서는 속도 변동 또는 연결 완료 실패가 발생할 수 있음 |
| WireGuard | 키, Endpoint, Allowed IPs 및 MTU | 일부 웹사이트만 멈추고 작은 요청은 정상일 때 MTU 확인 |
기존 설정 저장
수정하기 전에 현재 서버 주소, 포트, 프로토콜 매개변수를 기록하세요. 추측만으로 TLS, MTU, Transport 또는 UDP 관련 옵션을 일괄 조정하지 마세요.
서버 측 정보 확인
Home의 서버 세부 정보와 자신의 서비스 제공업체가 현재 제공하는 설정을 항목별로 비교하세요. 특히 대소문자, 경로 앞의 슬래시, SNI와 포트를 확인합니다.
매개변수는 하나만 수정
한 번에 명확하게 일치하지 않는 필드 하나만 수정하고 저장한 뒤 다시 연결해 동일한 테스트를 반복하세요. 그래야 변경 사항을 되돌리기 쉽습니다.
기존 값 복원
변경 후 개선되지 않거나 새로운 오류가 발생하면 기록해 둔 기존 설정으로 즉시 복원한 뒤 다른 계층을 계속 점검하세요.
MTU는 명확한 단편화 증거가 있거나 특정 웹사이트가 멈출 때만 조정해야 합니다. 값이 너무 크면 일부 패킷이 통과하지 못할 수 있고, 너무 작으면 헤더 비율과 처리 횟수가 늘어납니다. 한 네트워크 환경에서 효과가 있었던 MTU 값을 모든 설정에 그대로 복사하지 마세요.
4단계: 로컬 Wi‑Fi, 셀룰러 네트워크, 백그라운드 트래픽 확인
로컬 네트워크는 가장 쉽게 간과되는 계층입니다. 기기가 라우터에서 너무 멀거나, 같은 주파수 대역에 간섭이 있거나, 라우터가 장시간 높은 부하 상태이거나, 광대역 업로드 대역폭이 포화되면 Shadowrocket의 지연 시간이 높아질 수 있습니다. 이때 연결을 끈 상태에서 로컬 사이트에 접속해도 느릴 수 있으므로, 연결을 켠 상태와 끈 상태를 먼저 비교하세요.
Wi‑Fi 신호 아이콘이 가득 찼다는 것은 기기가 강한 무선 신호를 받고 있다는 뜻일 뿐 인터넷 외부 연결의 혼잡 여부를 직접 나타내지는 않습니다. 2.4 GHz는 일반적으로 커버리지가 넓지만 같은 주파수 대역 장비의 영향을 더 쉽게 받습니다. 5 GHz는 가까운 거리에서 대체로 더 높은 사용 가능 대역폭을 제공하지만 벽을 통과할 때 감쇠가 더 큽니다. 실제 주파수 대역 이름과 전환 방법은 라우터에 따라 다릅니다.
백그라운드 전송 중지
클라우드 사진 동기화, 시스템 백업, 앱 업데이트, 로컬 네트워크 파일 전송을 일시 중지하고 약 30초 후 다시 테스트하세요.
라우터 가까이 이동
장애물이 없는 가까운 위치에서 동일한 서버를 테스트하세요. 지연 변동이 뚜렷하게 줄어들면 무선 커버리지 또는 간섭 문제를 우선 처리하세요.
접속 네트워크 전환
서버, 프로토콜, Global Routing은 그대로 두고 Wi‑Fi에서 셀룰러 네트워크로 전환한 뒤 동일한 웹페이지와 파일을 테스트하세요.
네트워크 연결 재설정
Shadowrocket 연결 스위치를 끄고 현재 네트워크에 다시 연결한 다음 연결을 다시 켜세요. 계속 이상하면 기기와 라우터의 일반적인 절차에 따라 재시작한 뒤 다시 테스트할 수 있습니다.
On Demand 확인
Settings → On Demand로 이동해 Wi‑Fi와 셀룰러 네트워크를 전환할 때 규칙이 반복적으로 연결하거나 해제하지 않는지 확인하세요. 점검 중에는 기존 설정을 기록한 뒤 잠시 비활성화하고 수동으로 연결해 테스트할 수 있습니다.
오류: Network is unreachable
원인 및 해결:현재 기기에 사용 가능한 네트워크 경로가 없거나, 네트워크 전환 중 라우팅이 아직 복구되지 않은 상태입니다. 먼저 Wi‑Fi 또는 셀룰러 네트워크 자체가 접속 가능한지 확인한 뒤 Shadowrocket 연결을 껐다가 다시 켜세요.
오류: The Internet connection appears to be offline
원인 및 해결:시스템이 사용 가능한 인터넷 연결을 감지하지 못한 상태입니다. 먼저 Shadowrocket을 끈 상태에서 로컬 네트워크를 확인하고, 연결이 복구된 후 시스템 VPN 터널을 다시 설정하세요.
Global Routing, 규칙 매칭, DNS 대기 확인
속도 문제는 트래픽이 잘못된 경로로 전달되어도 발생할 수 있습니다. Shadowrocket의 Global Routing에는 일반적으로 Proxy, Direct, Config, Scene 상태가 있습니다. Proxy는 모든 트래픽에 프록시 정책을 적용하고, Direct는 직접 연결하며, Config는 Config의 규칙을 위에서 아래로 매칭합니다. Scene은 설정된 시나리오에 따라 처리합니다. 점검할 때는 현재 상태가 예상과 일치하는지 반드시 확인하세요.
Global Routing이 Direct에 머물러 있으면 현재 서버가 해당 프록시 트래픽을 처리하지 않습니다. Proxy에 머물러 있으면 원래 DIRECT로 처리해야 할 로컬 리소스도 우회할 수 있습니다. 일상적으로 Config를 사용할 때는 규칙 순서가 특히 중요합니다. Shadowrocket은 조건에 맞는 첫 번째 규칙을 적용한 뒤 보통 아래 규칙을 계속 확인하지 않으므로, 범위가 넓은 규칙을 앞에 두면 뒤의 정확한 규칙이 가려질 수 있습니다.
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY위 예시는 매칭 순서만 설명하기 위한 것입니다. example.com은 먼저 DOMAIN-SUFFIX에 따라 PROXY를 사용하고, 로컬 네트워크 주소는 IP-CIDR에 따라 직접 연결합니다. GEOIP 조건에 맞는 나머지 트래픽은 DIRECT를 사용하며, 앞선 규칙에 매칭되지 않은 요청은 최종적으로 FINAL에 도달합니다. 실제 정책 이름은 자신의 Config에 정의된 값과 일치해야 합니다.
DNS 대기는 도메인을 처음 열 때는 매우 느리지만 같은 페이지를 새로 고치면 빨라지는 현상으로 나타날 수 있습니다. 점검할 때는 도메인 접속과 알려진 사용 가능 IP 리소스 접속의 차이를 비교할 수 있지만, 출처를 알 수 없는 DNS 주소를 임의로 입력하지 마세요. 또한 Config에 GEOIP 또는 IP-CIDR 판단을 위해 해석이 필요한 규칙이 있는지, 해석을 실행할 필요가 없는 상황에 `no-resolve`가 사용되었는지도 확인하세요.
- Home에서 현재 Global Routing이 Proxy, Direct, Config, Scene 중 무엇인지 확인하고 테스트 전 상태를 기록하세요.
- Config를 사용할 때는 규칙 상단부터 내려오며 대상 도메인에 매칭될 수 있는 첫 번째 DOMAIN-SUFFIX, DOMAIN-KEYWORD, GEOIP, IP-CIDR 또는 FINAL을 찾으세요.
- 첫 요청만 느리다면 DNS 해석과 첫 바이트 대기를 중점적으로 기록하세요. 연결 설정 후에도 계속 느리다면 회선과 서버 처리량 단계로 돌아가 점검합니다.
- 점검이 끝나면 기존 Global Routing 상태로 복원하세요. 테스트 중 임시로 사용한 Proxy 상태를 장기적인 결론으로 삼지 마세요.
현상: Connected but no traffic
원인 및 해결:시스템 터널은 설정되었지만 규칙, DNS 또는 서버 외부 연결에서 유효한 응답이 발생하지 않은 상태입니다. 먼저 Global Routing이 실수로 Direct로 설정되지 않았는지 확인한 다음 Config에서 대상 도메인의 첫 번째 매칭 결과를 하나씩 확인하세요.
정해진 순서로 다시 테스트하고 결론 기록
한 계층의 조정을 마친 뒤에는 처음 정한 테스트 대상을 사용해 다시 확인하세요. 웹사이트를 바꾼 뒤 주관적인 느낌으로 판단하지 마세요. 날짜, 시간, 접속 네트워크, 서버 라벨, 프로토콜, Global Routing, 3회의 지연 시간, 첫 응답 상태와 지속 속도를 기록하는 것이 좋습니다. 기록 항목이 같으면 일시적인 변동인지 안정적인 차이인지 구분할 수 있습니다.
지연 시간은 매우 짧은데 다운로드는 왜 느린가요?
지연 시간은 한 번의 왕복 시간을 나타낼 뿐 서버 외부 연결과 전체 경로의 지속 처리량을 의미하지 않습니다. 크기가 명확한 파일 하나를 정해 3회 연속 테스트하고 서버 부하와 피크 시간대 회선 상태도 확인하세요.
서버를 바꾸자마자 빨라졌습니다. 바로 결론을 내려도 되나요?
먼저 동일한 네트워크, 동일한 Global Routing, 동일한 테스트 대상으로 3회 반복하세요. 원래 서버는 계속 느리고 새 서버는 계속 정상일 때에만 문제 범위를 원래 서버 또는 상위 회선으로 좁힐 수 있습니다.
Wi‑Fi는 느리지만 셀룰러 네트워크는 정상일 때 어떻게 하나요?
Shadowrocket 설정은 그대로 두고 라우터 가까이에서 다시 테스트하며 백그라운드 동기화를 일시 중지하세요. 가까운 거리에서 정상으로 돌아오면 무선 커버리지를 확인하고, 여전히 느리면 라우터 부하와 광대역 경로를 확인합니다.
구독 업데이트 실패가 기존 서버에 영향을 주나요?
기존 항목은 일시적으로 남아 있을 수 있지만 서비스 제공업체의 이후 설정 변경 사항을 가져오지 못합니다. 먼저 Home에서 아래로 당겨 업데이트하세요. Failed to load subscription이 표시되면 자신의 서비스 제공업체에 링크와 접근 조건을 확인하세요.
Proxy 테스트를 장기간 사용해야 하나요?
Proxy는 점검 중 전체 트래픽을 프록시 경로로 보내는지 확인할 때 유용하지만 Config의 분류 결과를 우회합니다. 테스트가 끝나면 기존 상태로 복원하고 DOMAIN-SUFFIX, GEOIP, IP-CIDR, FINAL의 실제 매칭 순서를 확인하세요.
- 현재 네트워크와 현재 서버에서 기준 테스트를 먼저 완료하고 결과를 3회 연속 기록하세요.
- 서버만 바꿔 서버 부하 또는 서버 상위 경로에 이상이 있는지 판단하세요.
- Wi‑Fi와 셀룰러 네트워크만 전환해 로컬 접속과 회선 차이를 판단하세요.
- 프로토콜 매개변수를 확인하고 포트, TLS, Transport 또는 MTU를 추측으로 변경하지 마세요.
- Global Routing, Config 규칙 순서, DNS 첫 응답을 확인하세요.
- 기존 설정을 복원하고 동일한 대상으로 3회 다시 테스트한 뒤 중간값을 결론으로 기록하세요.
Shadowrocket은 Apple 플랫폼용 유료 상용 앱입니다. iPhone과 iPad가 주요 사용 기기이며, 스토어 호환성 항목에는 Mac, Apple TV, Apple Vision이 표시될 수도 있습니다. 시스템 요구 사항은 App Store 페이지의 표기를 기준으로 하세요. 유일한 공식 이용 경로는 App Store이며, 제품 페이지의 개발자는 Shadow Launch Technology Limited, 앱 ID는 932747118, 구매 방식은 일회성 구매입니다. 클라이언트 구매와 사용자가 별도로 이용하는 회선 서비스는 서로 다른 사항입니다.