Shadowrocket에 연결한 뒤 속도가 느려지면 로컬 네트워크 혼잡, 연결 설정 오류, 네트워크 간 회선 변동, 원격 노드 부하를 구분해야 합니다. 이미 본인 설정을 보유한 사용자를 대상으로, 동일한 테스트 대상과 노드를 유지하고 한 번에 한 항목만 변경해 비교하는 방법을 설명합니다. Connectivity Test로 확인할 수 있는 범위와 클라이언트 설정 변경을 멈추고 이용 중인 서비스 제공업체에 점검 기록을 전달해야 할 시점도 안내합니다.
먼저 ‘느림’을 구분하세요: 연결 대기와 지속 전송을 따로 기록
웹페이지가 한참 동안 비어 있거나, 이미지가 하나씩 늦게 뜨거나, 재생이 시작된 뒤 버퍼링이 반복되는 현상은 각각 이름 해석, 연결 설정, 지속 전송과 관련될 수 있습니다. ‘연결됨’ 표시만으로 실제 접속 경로가 정상이라고 판단할 수는 없습니다. 시스템 터널이 성공적으로 설정되어도 원격 노드나 대상 웹사이트까지 모두 정상이라는 뜻은 아닙니다. 평소 접속 가능한 웹페이지 하나와 반복해서 받을 수 있는 파일 하나를 정한 뒤, 이후에도 같은 대상을 기준으로 비교하세요.
약 30초 간격으로 세 번 연속 확인하고, 네트워크 유형, 선택한 노드, Global Routing 설정, 실패 양상을 기록하세요. 아래 수치는 기록 방법을 보여 주는 예시일 뿐, 실제 제품 측정값이나 성능 기준이 아닙니다. 첫 콘텐츠가 표시될 때까지 2초, 5초, 3초가 걸렸다고 기록하면 ‘가끔 느림’이라고만 적는 것보다 문제를 재현하기 쉽습니다. 반복 테스트는 데이터를 사용하므로 셀룰러 네트워크에서는 파일 크기를 조절하세요.
- 초기 대기 시간: 요청을 보낸 시점부터 첫 콘텐츠가 표시될 때까지 기록하세요. 웹페이지 렌더링 애니메이션 시간은 연결 지연 시간에 포함하지 않습니다.
- 지속 전송: 같은 파일을 일정 시간 전송할 때의 안정적인 속도를 기록하세요. MB/s와 Mbps는 다르며, 1 MB/s는 약 8 Mbps입니다.
- 간헐적 끊김: 화면을 잠갔다가 다시 켜거나 Wi-Fi와 셀룰러 네트워크를 전환한 뒤에만 발생하는지 기록하세요.
- 영향 범위: 모든 대상에 영향을 주는지, 특정 웹사이트에만 나타나는지, 특정 앱에서만 발생하는지 기록하세요.
1단계: 로컬 네트워크와 라우팅 설정 확인
로컬 네트워크에는 기기와 라우터 간 무선 연결, 라우터의 외부 연결, 현재 접속한 네트워크가 포함됩니다. 라우터에서 멀리 떨어져 있거나, 같은 네트워크에서 대용량 데이터가 전송 중이거나, 게스트 네트워크 인증이 끝나지 않은 경우 원격 노드가 느린 것처럼 보일 수 있습니다. 먼저 노드와 설정을 그대로 둔 채 접속 네트워크만 바꿔야 문제가 로컬 환경에서 비롯됐는지 확인할 수 있습니다.
-
기준 상태 저장
Home에서 선택한 노드와 현재 Global Routing 옵션을 기록한 다음, 정해 둔 웹페이지의 로딩 상태를 기록하세요. 구독을 업데이트하거나 여러 설정을 동시에 바꾸지 마세요.
-
라우팅 확인
Home → Global Routing으로 이동하세요. Config는 현재 설정의 규칙에 따라 처리하고, Proxy는 전역 프록시 설정, Direct는 직접 연결 설정에 사용합니다. Scene은 장면 설정과 관련되므로 고정된 속도 측정 모드로 간주하면 안 됩니다.
-
직접 연결과 비교
직접 연결이 허용되는 일반적인 대상이라면 Direct로 잠시 비교할 수 있습니다. 이 설정은 요청 경로를 바꾸므로 민감한 작업을 먼저 중단하고, 비교가 끝나면 원래 옵션으로 되돌리세요. 직접 연결도 느리다면 먼저 로컬 네트워크를 점검하세요.
-
접속 네트워크 변경
가능하다면 같은 기기와 같은 노드로 Wi-Fi와 셀룰러 네트워크에 각각 연결한 뒤, 연결을 새로 설정하고 같은 대상을 테스트하세요. 네트워크를 바꾸는 동시에 노드까지 변경하지 마세요.
-
On Demand 확인
연결을 끊은 뒤 자동으로 다시 연결된다면 Settings → On Demand를 확인하세요. 잠시 비활성화해야 한다면 먼저 기존 설정을 기록하고, 비교가 끝난 뒤 복원하세요. On Demand는 필요할 때 연결하는 기능이며 대역폭을 높이는 옵션이 아닙니다.
특정 Wi-Fi 환경에서만 느리고 셀룰러 네트워크에서는 같은 설정이 정상이라면 무선 신호, 라우터 부하, 해당 네트워크의 제한을 먼저 확인하세요. 두 접속 환경에서 모두 느리더라도 곧바로 노드 문제라고 단정할 수는 없습니다. 프로토콜과 실제 트래픽 분기 상태를 계속 확인하세요. 직접 연결과 프록시 연결은 경로가 다르므로 직접 연결이 더 빠르다는 사실만으로 혼잡이 발생한 구간을 특정할 수는 없습니다.
2단계: 프로토콜 항목 확인, MTU와 포트를 무작정 변경하지 마세요
Home에서 현재 노드의 편집 화면을 열고, 서비스 제공업체가 전달한 원래 설정과 항목별로 비교하세요. Server, Port, 인증 정보, 전송 방식, TLS 관련 설정은 서로 맞아야 합니다. Port는 서버가 연결을 받도록 설정된 포트입니다. 예를 들어 원래 설정에 443이 사용됐더라도 모든 노드를 443으로 바꿔야 한다는 뜻은 아닙니다. 흔히 쓰이는 포트라고 해서 서버가 같은 프로토콜을 실제로 제공한다고 볼 수도 없습니다.
| 프로토콜 또는 설정 | 확인할 항목 | 흔한 오해 |
|---|---|---|
| Shadowsocks | Server, Port, 비밀번호, 암호화 방식이 동일한 서버 설정에 대응하는지 확인하세요. | 암호화 방식만 바꿔서는 서버 설정 불일치를 해결할 수 없습니다. |
| VMess / VLESS | 인증 정보, 전송 방식, 설정에서 요구하는 Host, Path, TLS 매개변수를 확인하세요. | 포트에 연결된다고 해서 전송 계층 연결과 인증까지 성공한 것은 아닙니다. |
| Trojan | 비밀번호, 서버 이름, 인증서 검증에 필요한 정보를 확인하세요. | 인증서 오류를 검증 해제로 해결하거나 속도 최적화로 처리하면 안 됩니다. |
| Hysteria2 | 인증 정보와 포트를 확인하고, 현재 네트워크에서 필요한 UDP 통신을 허용하는지도 확인하세요. | 다른 TCP 기반 연결이 정상이어도 UDP 경로까지 정상이라는 뜻은 아닙니다. |
| WireGuard | 키, Endpoint, 터널 주소, AllowedIPs, 원래 설정의 MTU를 확인하세요. | 터널에서 핸드셰이크가 이루어져도 모든 대상 주소로 올바르게 라우팅된다는 뜻은 아닙니다. |
작은 웹페이지는 열리지만 큰 응답이나 장시간 연결이 멈춘다면 경로 MTU 문제를 원인 후보로 고려할 수 있습니다. 다만 패킷 손실, 서버 속도 제한, 대상 웹사이트 문제도 같은 현상을 일으킬 수 있습니다. 먼저 원래 설정의 MTU로 되돌리고 사본을 보관하세요. 적절한 안내를 받은 경우에만 한 번에 한 항목씩 변경하세요. MTU 단위는 속도가 아닌 바이트이며, 값을 높이거나 낮춘다고 반드시 빨라지는 것은 아닙니다.
Connectivity Test: 연결 가능 여부와 전송 속도는 다릅니다
Home → Connectivity Test에서 테스트를 실행하고 현재 네트워크, 선택한 노드, Global Routing 설정, 현재 설정에서의 테스트 결과를 기록하세요. 테스트에 사용되는 방식과 대상은 앱 내 현재 설정을 기준으로 확인해야 합니다. 표시되는 밀리초 값은 해당 테스트 조건에서의 응답 시간이며, 파일 전송 속도가 아니고 영상 화질로 바로 환산할 수도 없습니다.
- 수치는 낮지만 전송이 느린 경우: 짧은 요청은 정상이더라도 지속적인 데이터 전송이 제한될 수 있습니다. 같은 파일로 안정적인 속도를 확인하고, 대상 트래픽이 실제로 선택한 노드를 통과하는지 점검하세요.
- 수치 변동이 큰 경우: 같은 네트워크와 노드로 세 번 반복해 측정 범위를 기록하세요. 가장 좋은 결과만 남기지 마세요. 무선 간섭, 경로 혼잡, 원격 노드 부하가 원인일 수 있습니다.
- 테스트는 실패하지만 웹페이지가 열리는 경우: 테스트 대상과 현재 라우팅을 확인하세요. 특정 테스트 요청은 실패하더라도 웹페이지 요청에는 다른 규칙이나 연결 방식이 적용될 수 있습니다.
- 테스트는 성공하지만 특정 사이트가 열리지 않는 경우: 해당 사이트의 DNS, 규칙 적용 여부, TLS, 대상 서비스 상태를 계속 확인하세요. 테스트 성공만으로 모든 접속이 정상이라고 판단할 수는 없습니다.
Config에서는 설정에 지정된 규칙 순서와 정책에 따라 요청이 처리됩니다. Config에서 현재 활성화된 파일을 확인할 때 DOMAIN-SUFFIX, GEOIP, IP-CIDR, FINAL 항목을 살펴보세요. 도메인 규칙과 주소 규칙은 서로 다른 조건을 기준으로 하며, FINAL은 앞선 규칙에 일치하지 않는 요청에 적용되는 기본 처리 규칙입니다. Home에서 선택한 노드만 바꿔도 이미 DIRECT나 다른 정책에 매칭된 요청은 바뀌지 않을 수 있습니다. Proxy로 임시 비교한 뒤에는 원래 라우팅 설정을 복원하고 요청을 새로 보내세요. 기존 연결이 계속 사용되지 않도록 해야 합니다.
3·4단계: 회선 변동과 노드 부하 구분
회선 품질은 기기가 접속 네트워크를 거쳐 원격 노드에 도달하는 경로 상태를 뜻합니다. 노드 부하는 원격 서버가 연결과 데이터 전송을 처리할 수 있는 능력을 말합니다. 클라이언트에서 지연 시간 하나만으로 둘을 완전히 구분하기는 어렵습니다. 현상만으로 원인을 단정하기보다 비교 테스트로 범위를 좁히고, 재현 가능한 근거를 본인의 서비스 제공업체에 전달하세요.
| 비교 조건 | 관찰 결과 | 판단에 참고할 점 |
|---|---|---|
| 같은 노드와 대상에서 접속 네트워크만 변경 | 특정 접속 환경에서만 계속 느립니다. | 해당 접속 환경과 노드까지의 경로를 우선 확인할 수 있지만, 원격 서버 전체의 장애를 입증하는 것은 아닙니다. |
| 같은 접속 환경과 대상에서 기존 설정의 노드 변경 | 특정 노드 하나만 뚜렷하게 느립니다. | 해당 노드 또는 노드까지의 경로를 추가로 점검할 필요가 있습니다. |
| 같은 설정과 접속 환경으로 시간대를 바꿔 반복 측정 | 정해진 혼잡 시간대에 느려지고 다른 시간대에는 회복됩니다. | 혼잡이나 용량 제한 가능성을 기록하세요. 시간대만으로 혼잡 위치를 특정할 수는 없습니다. |
| 같은 노드와 접속 환경에서 대상만 변경 | 특정 대상 하나만 느립니다. | 대상 서비스, 대상 측의 제한, 노드에서 대상까지의 경로를 확인하세요. |
문제를 비교할 때는 본인이 이미 보유하고 사용 권한이 있는 설정만 이용하세요. 점검을 위해 새 서비스를 찾을 필요는 없습니다. 기록을 전달할 때는 테스트 시각과 시간대, 접속 유형, 노드 메모, 프로토콜, 대상 유형, 세 번의 결과를 적으세요. 외부에 공유하기 전에는 비밀번호, PrivateKey, 전체 구독 주소, 인증 정보가 포함된 링크를 삭제하세요. 스크린샷에서도 해당 정보를 가려야 합니다. 클라이언트는 일회성 구매이며 회선 서비스와는 별개입니다. 클라이언트를 구매해도 원격 회선 용량은 포함되지 않습니다.
로그에 오류가 표시되면 원문으로 실패 단계 확인
다음은 네트워크 로그에 나타날 수 있는 표준 오류 문구입니다. 모든 장애에서 표시되는 것은 아니며 모든 화면에 고정적으로 나타나는 안내도 아닙니다. 먼저 실제 오류 전문을 보존하고 같은 시각 전후의 요청 기록을 확인하세요. 오류 문구는 문제 발생 단계를 찾는 데 도움이 될 뿐, 네트워크와 설정을 비교하지 않은 채 책임을 단정할 근거는 아닙니다.
오류: connection refused
원인: 대상 서버 또는 경로상의 장비가 연결을 거부했을 수 있습니다. 주소, 수신 대기 중인 포트, 서버 상태를 먼저 확인하세요.
해결: 현재 노드의 Server와 Port가 원래 설정과 일치하는지 확인한 뒤, 해당 포트에서 서비스가 정상 제공되는지 본인의 서비스 제공업체에 문의하세요.
오류: i/o timeout
원인: 네트워크의 읽기 또는 쓰기 단계가 제한 시간 내에 완료되지 않았습니다. 패킷 손실, 경로 접속 불가, 원격 서버의 느린 응답 등이 원인일 수 있습니다.
해결: 노드는 그대로 두고 접속 네트워크를 바꿔 다시 테스트하세요. 시간 초과 전후의 대상과 시각을 기록하고, 대기 시간을 늘리는 것을 전송 속도 문제의 해결책으로 보지 마세요.
오류: certificate has expired or is not yet valid
원인: 인증서 유효 기간 또는 기기의 날짜와 시간이 검증 조건에 맞지 않아 보안 연결 검증 단계에서 실패했습니다.
해결: 먼저 시스템 날짜와 시간을 확인한 다음 본인의 서비스 제공업체에 인증서 유효 기간을 확인해 달라고 요청하세요. 인증서 검증을 유지하고 검증을 건너뛰는 방식으로 문제를 대신 해결하지 마세요.
자주 묻는 질문: 언제 설정을 더 바꾸고, 언제 멈춰야 하나요?
지연 시간이 수십 밀리초뿐인데 재생이 계속 버퍼링되는 이유는 무엇인가요?
지연 시간은 짧은 요청에 대한 응답을 나타내며, 지속적으로 사용할 수 있는 대역폭을 뜻하지 않습니다. Home에서 선택한 노드와 Global Routing 설정을 그대로 두고 같은 파일의 안정적인 전송 속도를 확인한 뒤 여러 대상을 비교하세요. 특정 동영상 서비스만 느리다면 대상 측 문제와 실제 트래픽 분기를 확인하세요. 프로토콜부터 바꿀 필요는 없습니다.
노드를 바꿨는데 결과가 거의 달라지지 않는 이유는 무엇인가요?
먼저 Home → Global Routing에서 Config가 선택되어 있는지 확인한 다음 Config에서 현재 규칙과 적용 정책을 살펴보세요. 요청에 DIRECT, 고정 정책, 기존 장시간 연결이 적용될 수 있습니다. 테스트 트래픽이 새 노드를 사용하는지 확인한 뒤 요청을 새로 보내야 비교할 수 있습니다.
Wi-Fi를 바꾼 뒤 느려졌는데 설정을 전부 다시 만들어야 하나요?
먼저 설정을 다시 만들 필요는 없습니다. 새 네트워크가 인터넷에 연결되어 있는지 확인하고, 진행 중인 전송을 중단한 뒤 연결을 끊었다가 다시 설정하여 같은 대상을 테스트하세요. 시스템에서 자동으로 다시 연결한다면 Settings → On Demand의 기존 조건을 확인하고, 네트워크 전환 후에만 문제가 생기는지 기록하세요.
모든 항목이 일치하는데도 느립니다. 어떤 값을 더 바꿔야 하나요?
우선 무작위로 설정을 바꾸지 마세요. 기준 설정으로 복원하고 세 번 반복한 결과와 네트워크 간 비교 결과를 저장한 뒤, 민감한 정보를 제거하여 본인의 서비스 제공업체에 전달하세요. 원격 용량, 네트워크 간 경로, 대상 서비스 상태는 클라이언트 항목을 바꾸는 것만으로 확인하거나 해결할 수 없습니다.
점검을 마친 뒤 원래 Global Routing, On Demand, 임시 변경 설정을 복원하세요. 정상적으로 접속되던 때의 기록을 보관해 두면 다음에 문제가 생겼을 때 바로 비교할 수 있습니다. Shadowrocket은 주로 iPhone과 iPad에서 사용하며, Mac 등 Apple 플랫폼의 호환 기기와 시스템 요구 사항은 App Store 페이지를 기준으로 확인하세요. 기기마다 무선 환경과 테스트 조건이 다르므로 결과를 각각 기록해야 합니다.