Shadowrocket에 연결됨으로 표시되어도 전체 접속 경로에 충분한 대역폭이 확보된 것은 아닙니다. 이미 본인 서비스의 설정이나 구독을 보유한 사용자를 대상으로, 직접 연결 기준선부터 Global Routing, 프로토콜 설정, 네트워크 간 경로, 노드 부하까지 차례로 점검합니다. 테스트 대상을 고정하고 한 번에 한 가지 조건만 바꾸면 웹페이지 첫 로딩 지연, 지속적인 다운로드 저하, 연결 시간 초과를 구분할 수 있어 불필요한 설정 변경을 줄일 수 있습니다.
1. 지연 시간, 처리량, 연결 실패 구분하기
접속 속도는 여러 구간의 영향을 받습니다. iPhone과 Wi-Fi 액세스 포인트 또는 기지국 사이, 로컬 통신사와 원격 서버 사이, 서버 처리 성능, 서버에서 대상 웹사이트까지의 경로가 모두 포함됩니다. Home에 표시되는 지연 시간은 특정 테스트 방식의 응답 과정만 반영하므로 다운로드 속도로 바로 환산할 수 없습니다. 지연 시간이 한 번 낮게 나와도 장시간 전송 중 패킷 손실이나 혼잡이 없다는 뜻은 아닙니다.
먼저 증상을 구분한 뒤 테스트를 선택하세요. 웹페이지가 처음 열릴 때만 멈칫하고 이후에는 정상이라면 도메인 조회와 연결 수립을 먼저 살펴봅니다. 파일 다운로드가 시작부터 느리다면 대역폭과 경로를 비교합니다. 다운로드 속도가 오르내리면 무선 간섭, 패킷 손실, 공유 부하를 확인합니다. 계속 시간 초과가 발생한다면 도달 가능성 문제이므로 속도를 높이기 전에 연결부터 복구해야 합니다.
예를 들어 80 Mbps는 이론상 10 MB/s에 해당하지만, 실제 파일 전송 속도는 프로토콜 오버헤드, 대상 사이트의 속도 제한, 네트워크 변동에 영향을 받습니다. 이는 단위 환산일 뿐 속도를 보장하는 수치가 아닙니다. 테스트할 때 네트워크 유형, 선택한 노드, 라우팅 모드, 대상 웹사이트, 시간대를 기록해야 나중에 유효하게 비교할 수 있습니다.
2. 1단계: 로컬 네트워크의 직접 연결 기준선 확인
먼저 프록시 없이도 정상적으로 접속할 수 있는 동일한 웹사이트나 파일을 기준 대상으로 정합니다. 안전하고 직접 연결이 허용되는 상황에서 Shadowrocket 연결을 잠시 중단한 뒤 테스트하세요. 직접 연결부터 느리다면 프록시 프로토콜을 계속 조정해도 해결되지 않을 가능성이 큽니다. 서로 다른 웹사이트의 다운로드 속도를 비교해 프록시가 네트워크를 느리게 했다고 판단하지 마세요. 서버와 대역폭 제한이 다를 수 있습니다.
-
현재 설정 기록
Home에서 선택된 노드와 Global Routing의 현재 값을 기록한 뒤 Settings → On Demand에서 온디맨드 연결 상태를 확인합니다. 진단 중 수동으로 연결을 끊어야 한다면 On Demand를 잠시 비활성화해 기존 조건에 따라 시스템이 연결을 다시 설정하지 않도록 합니다.
-
직접 연결 기준선 측정
Home에서 연결을 중단하고 연결 상태가 바뀌었는지 확인합니다. Safari에서 고정한 테스트 대상을 열어 첫 로딩과 지속 전송 상태를 기록하세요. 이때 시스템 업데이트, 사진 동기화, 대용량 업로드를 동시에 실행하지 마세요.
-
접속 네트워크 변경
iPhone의 Settings → Wi-Fi에서 무선 연결을 전환하고, Wi-Fi와 셀룰러 네트워크로 동일한 대상을 각각 테스트합니다. 셀룰러 데이터 사용량에 유의하고 두 테스트는 가능한 한 비슷한 시간대에 진행하세요.
-
복원 후 재측정
Home으로 돌아가 같은 노드와 라우팅 설정을 복원하고 동일한 네트워크에서 다시 테스트합니다. 테스트가 끝나면 원래 On Demand 조건도 복원해 진단용 임시 설정이 계속 남지 않도록 합니다.
Wi-Fi에서만 느리다면 먼저 라우터 가까이에서 테스트하고, 서로 다른 주파수 대역의 연결을 비교하며, 대용량 업로드를 하는 사용자가 있는지 확인합니다. 업로드 대역폭이 꽉 차면 웹 요청도 대기할 수 있습니다. 셀룰러 네트워크에서만 느리다면 위치와 시간대를 바꿔 비교하고 현재 요금제에 속도 제한이 있는지 확인하세요. 상태 표시줄의 신호 막대만으로 충분한 대역폭을 판단해서는 안 됩니다.
3. 2단계: 라우팅 모드와 프로토콜 설정 확인
로컬 네트워크에 문제가 없다면 테스트 트래픽이 실제로 어떤 경로를 거치는지 먼저 확인합니다. Home → Global Routing의 Proxy, Direct, Config, Scene은 서로 다른 라우팅 모드입니다. Config는 현재 설정의 규칙에 따라 경로를 정하고, Scene은 설정된 장면 조건에 따라 해당 설정을 적용하므로 고정된 전체 프록시 모드로 보면 안 됩니다. 대상 웹사이트가 DIRECT 규칙에 해당한다면 테스트 결과로 선택한 프록시 노드의 속도를 판단할 수 없습니다.
| 설정 항목 | 의미 | 점검할 내용 |
|---|---|---|
| Proxy | 프록시 라우팅 모드 사용 | 테스트 도중 선택된 프록시나 정책 그룹이 바뀌지 않았는지 확인합니다. |
| Direct | 직접 연결 라우팅 모드 사용 | 라우팅 비교에 적합하지만 프록시 노드 속도를 나타내지는 않습니다. |
| Config | 현재 설정의 규칙 적용 | 대상 연결에 일치하는 규칙과 최종 정책을 확인합니다. |
| Scene | 장면 설정에 따른 조건 적용 | 현재 네트워크에 적용된 장면과 라우팅 설정을 확인합니다. |
Config에서 아래 규칙을 통해 테스트 대상의 경로를 이해할 수 있습니다. 전체 설정이 아닌 규칙 구문 예시입니다. example.com은 예시 도메인이고 PROXY는 프록시 정책을 뜻합니다. 실제 사용 전 현재 설정에 정의된 정책을 확인하세요. 규칙은 위에서부터 순서대로 일치 여부를 확인하므로 먼저 일치하는 규칙이 최종 결과를 결정할 수 있습니다.
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT그런 다음 Home에서 기존 노드의 편집 화면을 열어 유형, 주소, 포트, 인증 정보를 확인합니다. Shadowsocks의 암호화 방식, VMess 또는 VLESS의 ID와 전송 설정, Trojan의 비밀번호와 TLS 매개변수는 서버 설정과 일치해야 합니다. 서버가 TCP 포트 443을 사용한다고 해서 어떤 프로토콜이든 443을 입력하면 작동하는 것은 아닙니다. 포트가 같아도 전송되는 내용은 다를 수 있습니다.
- TLS 및 SNI: 본인 설정에 따라 서버 이름과 인증서 검증 조건을 확인합니다. 인증서 오류를 숨기기 위해 안전하지 않은 인증을 허용하지 마세요. 또한 iPhone의 Settings → General → Date & Time에서 시스템 시간이 정확한지 확인합니다.
- 전송 설정: 기존 설정에서 WebSocket을 사용한다면 경로와 Host가 서버 요구 사항과 일치해야 합니다. 양식을 저장할 수 있다고 해서 매개변수가 서버 검증을 통과한 것은 아닙니다.
- UDP 조건: Hysteria2는 QUIC 기반으로 UDP를 사용하며 WireGuard도 UDP를 사용합니다. 현재 네트워크에서 UDP를 제한하면 TCP 기반 설정과 다른 결과가 나타날 수 있으므로 프로토콜 이름만으로 속도를 판단할 수 없습니다.
- 구독 업데이트: 구독을 가져오거나 업데이트하면 설정을 받을 수 있지만 경로 자체의 대역폭이 높아지지는 않습니다. 기존 구독을 업데이트한 뒤에는 선택한 항목을 다시 확인해 주소나 매개변수 변경을 단순한 속도 변동으로 오해하지 않도록 합니다.
오류: certificate has expired
원인 및 해결: 이 TLS 오류는 인증서 시간 검증에 실패했음을 뜻하며, 인증서 만료나 기기 시간 오류가 원인일 수 있습니다. 먼저 시스템 시간을 맞춘 다음 본인 서비스 제공자에게 인증서 상태를 확인하고 인증서 검증은 계속 활성화해 두세요.
오류: Connection refused
원인 및 해결: 대상 엔드포인트나 중간 장비에서 연결을 명시적으로 거부한 경우입니다. 포트가 수신 대기 상태가 아니거나 접근 정책에서 차단했을 때 흔히 발생합니다. 주소, 포트, 프로토콜을 확인하고 반복적인 속도 테스트를 해결 방법으로 삼지 마세요.
오류: Operation timed out
원인 및 해결: 제한 시간 안에 요청이 완료되지 않은 상태입니다. 경로의 패킷 손실, 연결할 수 없는 포트, 원격 응답 없음 등이 원인일 수 있습니다. 먼저 접속 네트워크를 바꿔 같은 설정을 테스트한 다음 본인 서비스 제공자에게 원격 상태를 확인하세요.
위 오류는 네트워크 및 TLS 진단에서 흔히 볼 수 있는 원문이며 실제 화면에는 추가 정보가 포함될 수 있습니다. 전체 오류 메시지와 발생 시간을 기록해 DNS 조회, 연결, 핸드셰이크, 전송 중 어느 단계에서 발생했는지 구분하세요. ‘시간 초과’라는 두 단어만 보고 노드 부하 탓으로 단정하지 마세요.
4. 3단계: 교차 테스트로 경로 문제 확인
경로 품질은 로컬 접속 네트워크와 원격 서버 사이의 왕복 지연 시간, 지터, 패킷 손실, 혼잡 상태를 말합니다. 서버까지의 지리적 거리와 관련은 있지만 거리만으로 결정되지는 않습니다. 같은 지역으로 표시된 기존 노드 두 개라도 전혀 다른 상호 연결 경로를 이용할 수 있으므로 노드 이름만으로 경로 품질을 판단해서는 안 됩니다.
보유 중인 설정으로 교차 테스트를 진행합니다. 먼저 노드를 고정한 채 접속 네트워크를 바꾸고, 그다음 접속 네트워크를 고정한 채 기존 노드를 바꿉니다. 테스트 대상과 방법은 동일하게 유지하고 각 조합을 3회 반복해 중간 결과를 기록하세요. 순간적으로 나온 최고 속도를 지속 속도로 간주하거나 테스트를 짧은 간격으로 여러 개 동시에 실행하지 마세요. 테스트 자체가 연결을 가득 채울 수 있습니다.
| 관찰된 조합 | 우선 점검할 항목 | 다음 단계 |
|---|---|---|
| 같은 노드가 Wi-Fi에서는 느리고 셀룰러에서는 정상 | Wi-Fi 접속 환경 또는 해당 통신사 경로 | 직접 연결 기준선과 함께 비교해 무선 문제와 원격 경로 차이를 구분합니다. |
| 같은 노드가 두 네트워크에서 모두 느리고 다른 기존 노드는 정상 | 해당 노드의 경로 또는 서버 상태 | 노드 설정을 그대로 둔 채 다른 시간대에 다시 테스트합니다. |
| 특정 웹사이트만 느리고 다른 대상은 정상 | 대상 사이트, DNS 조회 또는 노드에서 대상까지의 경로 | 같은 사이트의 서로 다른 리소스를 비교하고 실제 적용된 라우팅 정책을 확인합니다. |
| 모든 노드와 직접 연결이 동시에 느림 | 로컬 네트워크 또는 테스트 대상 | 다른 전송을 중단하고 고정된 테스트 대상을 바꾼 뒤 기준선을 다시 측정합니다. |
정리: 변수를 고정한 뒤 네트워크 변경
같은 설정이 특정 접속 네트워크에서만 비정상이라면 프로토콜 매개변수는 그대로 두고 해당 네트워크와 원격 경로를 중점적으로 점검합니다. DNS, 포트, 프로토콜을 한꺼번에 변경하면 어떤 변경이 결과에 영향을 줬는지 알 수 없습니다.
웹페이지 첫 로딩만 느리고 지속 전송은 정상일 때 DNS를 중점적으로 확인합니다. 같은 도메인을 처음 열 때와 다시 열 때의 차이를 비교하고 연결 기록에서 DNS 조회와 연결에 걸린 시간을 확인하세요. 두 번째 접속이 빨라진 것은 브라우저 캐시 때문일 수도 있으므로 이것만으로 DNS 오류라고 단정할 수 없습니다. 임의로 DNS 주소를 변경하면 대상 서버 배정이나 규칙 일치 결과가 달라질 수 있으므로 변경 전에 현재 설정을 백업하세요.
5. 4단계: 노드 부하와 대상 사이트 제한 구분
노드 부하에는 서버 처리 성능, 출구 대역폭, 동시 연결 수, 서버 측 속도 제한이 포함됩니다. 클라이언트에서 확인할 수 있는 것은 응답과 전송 상태이며, 일반적으로 원격 CPU 사용량이나 출구 대역폭 점유율을 직접 확인할 수는 없습니다. 따라서 ‘지연 시간은 낮지만 다운로드는 느림’은 지연 시간과 처리량이 일치하지 않는다는 뜻일 뿐 서버 과부하를 입증하지는 않습니다.
- 시간대별 비교: 같은 네트워크, 노드, 대상을 사용했을 때 혼잡 시간대에만 계속 느리고 다른 시간대에는 정상이라면 공유 경로 혼잡이나 부하 변화일 수 있습니다. 다만 원격 서버 상태도 함께 확인해야 합니다.
- 여러 대상 비교: 같은 노드에서 서로 무관한 여러 대상에 접속해도 모두 느리다면 한 웹사이트만 느린 경우보다 노드의 출구나 공통 경로를 점검할 필요가 큽니다. 특정 사이트만 느린 경우에는 대상 사이트의 속도 제한일 수도 있습니다.
- 지속 상태 비교: 전송 속도가 일정한 범위에 머무는지, 간헐적으로 멈추는지 기록합니다. 일정한 상한은 속도 제한과 관련이 있을 수 있고, 뚜렷한 멈춤은 패킷 손실, 재전송, 연결 중단과 관련이 있을 수 있습니다. 어느 쪽도 클라이언트만으로 확정할 수는 없습니다.
- 서비스 상태 확인: 본인 서비스 제공자에게 기존 서비스에 대역폭, 데이터 사용량, 동시 연결 제한이 있는지 확인합니다. 민감 정보를 가린 증상 기록만 제공하고 구독 주소, 비밀번호, 인증 정보는 보내지 마세요.
속도 측정 수치를 높이려고 동시 연결 수를 무작정 늘리거나 다운로드를 계속 실행하지 마세요. 여러 연결을 이용하면 일시적으로 총 처리량이 커질 수 있지만 웹페이지 하나의 요청이 빨라진다는 뜻은 아니며 데이터도 소모됩니다. 두 프로토콜의 서버, 포트, 출구, 경로가 서로 다르면 결과를 ‘특정 프로토콜이 항상 더 빠르다’고 일반화할 수 없습니다.
정리: 근거를 바탕으로 원격 구간 점검
직접 연결이 정상이고 매개변수가 같으며, 여러 대상에서 느리고 접속 네트워크를 바꿔도 같은 문제가 재현될 때 해당 노드의 출구와 부하를 우선 서비스 제공자에게 확인하세요. 시간대와 비교 결과를 함께 전달하면 클라이언트 설정을 반복해서 바꾸는 것보다 원인을 파악하기 쉽습니다.
6. 기록 정리 및 평소 설정 복원
점검을 마친 뒤에는 세 가지를 답할 수 있어야 합니다. 로컬 직접 연결은 정상인지, 대상 요청에 실제로 어떤 정책이 적용되는지, 문제가 노드 또는 접속 네트워크 변경을 따라가는지입니다. 여전히 판단하기 어렵다면 최소한의 재현 조건을 보존하고 변경을 더 쌓지 마세요. 특히 구독 업데이트, 규칙 변경, 프로토콜 조정을 동시에 하면 원래 문제와 비교하기 어려워집니다.
- iPhone이 Wi-Fi와 셀룰러 중 어느 네트워크를 사용했는지, 각 테스트의 날짜와 시간, 지속 시간을 기록합니다. 공개 기록에 전체 공인 IP 주소를 포함할 필요는 없습니다.
- Home → Global Routing 값, 현재 설정, 선택한 노드의 식별 정보를 가려 기록하고 테스트 중 자동 전환이 있었는지 적습니다.
- 직접 연결 기준선, 같은 노드의 네트워크별 결과, 같은 네트워크에서 서로 다른 기존 노드를 사용한 결과를 기록하고 속도 단위가 Mbps인지 MB/s인지 표시합니다.
- 오류 원문은 보존하되 전송 전에 주소의 민감 정보, 인증 필드, 구독 인증 정보는 가립니다.
- 평소 사용하는 Config, 규칙, Settings → On Demand 조건을 복원하고 자주 방문하는 웹사이트에 예상한 라우팅이 적용되는지 확인합니다.
규칙과 라우팅 모드를 더 확인하려면 기술 참고 자료 또는 프록시 모드 안내를 읽어보세요. Shadowrocket은 Apple 플랫폼 전용 상용 비공개 소스 앱이며 주로 iPhone과 iPad에서 사용합니다. 시스템 요구 사항은 App Store 페이지 표기를 기준으로 확인하세요. 앱은 일회성 구매 방식이며 네트워크 회선 요금제와는 별개입니다. 이 글은 사용자가 이미 보유한 설정을 점검하는 방법을 안내하며 노드나 구독을 제공·판매·추천하지 않습니다.