Shadowrocket에 연결됨으로 표시되어도 모든 요청이 목적지에 성공적으로 도달한 것은 아닙니다. 이미 자체 서비스 제공업체와 구독을 이용 중이며 연결은 되지만 웹페이지나 동영상 로딩이 느린 사용자를 위해, 먼저 테스트 조건을 고정한 뒤 로컬 접속, 프로토콜 설정, 네트워크 경로, 노드 부하를 차례로 확인합니다. 마지막으로 Ping과 Log를 활용해 나중에 다시 살펴볼 수 있는 근거를 남깁니다.
1. 테스트 조건을 고정하고 지연 시간과 처리량 구분하기
‘느리다’는 현상은 적어도 세 가지로 나뉩니다. 클릭 후 한참 동안 반응이 없거나, 페이지 로딩이 시작된 뒤에도 계속 느리거나, 연결 속도가 들쭉날쭉한 경우입니다. 첫 번째는 DNS 조회나 핸드셰이크, 두 번째는 가용 대역폭이나 혼잡, 세 번째는 네트워크 전환과 패킷 손실, 서버 부하를 살펴봐야 할 수 있습니다. 상태 막대의 VPN 표시만으로는 이들을 구분할 수 없습니다.
테스트 전에 Home(홈)에서 현재 선택한 노드와 Global Routing(전역 라우팅)의 설정값을 기록하세요. 구독 업데이트, 프로토콜 전환, DNS 변경을 한꺼번에 하지 마세요. 속도가 회복되더라도 무엇이 원인이었는지 알 수 없습니다. 아래 테스트 횟수는 문제 해결을 위한 권장 사항이며 앱의 기본값이 아닙니다.
- 이미 접속할 수 있는 웹페이지와 특정 동영상 구간을 하나씩 정한 뒤, 첫 응답 시간과 지속 로딩 상태를 각각 확인하세요. 전체 점검 동안 같은 대상을 사용합니다.
- 사진 동기화, 시스템 업데이트 등 데이터 사용량이 큰 작업을 일시 중지하고 기기 위치와 네트워크 접속 상태를 유지하세요.
- 각 조건에서 3회씩 확인하고 네트워크 종류, 노드 메모, 테스트 시간, 실패 양상을 기록하세요. 가장 빨랐던 결과만 적지 마세요.
- 한 번에 조건 하나만 바꾸세요. 비교가 끝나면 기존 라우팅과 설정으로 되돌린 다음 다음 테스트를 진행합니다.
2. 로컬 네트워크: Wi-Fi와 셀룰러 네트워크 비교하기
첫 번째로 iPhone 또는 iPad에서 로컬 네트워크 출구까지의 구간을 확인합니다. Wi-Fi 신호가 강하다고 해서 라우터의 외부 연결에 혼잡이 없는 것은 아닙니다. 같은 노드가 셀룰러 네트워크에서는 정상이고 특정 Wi-Fi에서만 느리다면, 접속 네트워크나 해당 네트워크에서 노드까지의 경로가 다를 수 있다는 단서입니다. 이를 곧바로 서버 문제로 단정할 수는 없습니다.
- 현재 Wi-Fi에서 원래 직접 접속할 수 있던 자주 쓰는 페이지를 열어 로컬 네트워크에서도 지연이 발생하는지 확인하세요. Shadowrocket을 잠시 연결 해제해 테스트한다면 직접 접속하기에 적합한 콘텐츠만 이용하세요.
- Settings → On Demand(요청 시 연결)로 이동해 현재 조건을 기록하세요. 기본값은 현재 앱에 표시된 값을 기준으로 합니다. 이 설정이 수동 연결 해제 비교를 방해한다면 이번 테스트 동안만 잠시 끄고, 종료 후 원래 값으로 복원하세요.
- 같은 노드와 설정을 유지한 채 Wi-Fi를 끄고 기기에서 사용할 수 있는 셀룰러 네트워크로 다시 테스트하세요. 데이터 사용량에 유의하세요.
- Wi-Fi에서만 문제가 생긴다면 라우터 가까이에서 다시 테스트하고 같은 네트워크에서 대용량 전송이 진행 중인지 확인하세요. 먼저 모든 프로토콜 설정을 바꾸지는 마세요.
포트 번호는 경로를 확인할 때 참고할 단서이지 속도 조절 설정이 아닙니다. 서비스 제공업체가 지정한 프록시 포트를 임의로 443으로 바꾸거나 모든 DNS 요청이 포트 53을 사용한다고 가정하면 새로운 연결 문제가 생길 수 있습니다.
3. 프로토콜 설정: 원본 구성을 대조하고 이름만으로 속도 판단하지 않기
두 번째로 클라이언트에 저장된 설정이 서버 요구 사항과 일치하는지 확인합니다. Shadowrocket의 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 프로토콜과 설정 항목이 서로 다릅니다. 이름만 바꾸면 서로 전환되는 속도 설정이 아닙니다. 이미 구독을 이용 중이라면 먼저 서비스 제공업체가 안내한 유효한 설정값과 대조하세요.
| 프로토콜 또는 항목 | 확인할 내용 | 이것만으로 판단하면 안 되는 점 |
|---|---|---|
| Shadowsocks | 서버 주소, 포트, 암호, 암호화 방식이 일치하는지 확인합니다. | 포트에 연결할 수 있어도 인증이나 이후 데이터 전달이 성공한다는 뜻은 아닙니다. |
| VMess / VLESS | 인증 정보, 전송 방식, 실제 설정에서 활성화된 TLS 및 전송 관련 항목을 확인합니다. | 주소와 포트만 남기고 나머지 필수 설정을 무시해서는 안 됩니다. |
| Trojan | 암호, TLS 관련 요구 사항, 서버 이름이 서버 설정과 일치하는지 확인합니다. | 인증서 검증을 끄는 것을 일반적인 속도 개선 방법으로 삼지 마세요. |
| Hysteria2 | 인증 정보, TLS 요구 사항, 현재 경로에서 UDP를 사용할 수 있는지 확인합니다. | QUIC 기반이라고 해서 모든 접속 네트워크에서 더 빠른 것은 아닙니다. |
| WireGuard | 키, 엔드포인트, 주소, 라우팅 범위가 기존 설정과 일치하는지 확인합니다. | 핸드셰이크가 확인되더라도 DNS와 목적지 라우팅이 모두 올바르다는 뜻은 아닙니다. |
위 항목에 모든 서버에 적용되는 공통 권장값은 없습니다. 기본값은 현재 앱에 표시된 값을 기준으로 하고, 연결 설정은 기존 서버 구성을 따르세요. 구독 업데이트 직후 문제가 생겼다면 업데이트 전후의 주소, 포트 또는 전송 항목 변화를 기록한 뒤 서비스 제공업체에 확인하세요. 기존 항목을 삭제하고 반복해서 다시 가져오면 비교 조건을 잃을 수 있으니 피하세요.
결론: 설정값이 일치하는지 확인한 다음 프로토콜별 상태를 비교하세요
특정 설정이 핸드셰이크 단계에서 반복적으로 실패한다면 먼저 인증, TLS 또는 전송 설정을 점검하세요. 두 설정 모두 같은 요청을 안정적으로 완료할 때만 속도 비교가 의미 있습니다.
4. 경로 품질: Ping과 실제 요청을 따로 살펴보기
세 번째로 로컬 네트워크에서 노드까지, 노드에서 목적지까지의 경로를 확인합니다. 앱 내 Ping(지연 시간 테스트) 결과는 테스트 방식을 고려해 해석해야 합니다. ICMP 응답, TCP 연결, 프록시를 거친 웹페이지 요청은 서로 다른 항목을 측정합니다. 노드가 ICMP에 응답하지 않는다고 해서 프록시 서비스를 사용할 수 없다고 단정할 수도 없습니다.
지연 시간이 짧다는 것은 특정 탐지의 왕복 시간이 짧았다는 뜻이지, 지속 전송에 필요한 대역폭이 충분하다는 뜻은 아닙니다. 탐지는 정상이지만 동영상이 계속 버퍼링된다면 실제 전송 상태와 시간대별 차이를 더 살펴보세요. 한 번의 시간 초과를 전체 경로의 패킷 손실률로 환산하지 마세요.
- Ping은 빠른데 웹페이지 첫 응답이 느림: Log에서 DNS 대기, 연결 재시도, TLS 오류가 있는지 확인하고 요청이 실제로 어떤 라우팅을 적용받았는지 살펴보세요.
- 첫 응답은 빠르지만 로딩이 계속 느림: 같은 대상을 고정해 다시 테스트하고 로컬 대역폭 사용량, 경로 혼잡, 서버 속도 제한 여부를 확인하세요.
- 같은 노드가 특정 접속 네트워크에서만 느림: 먼저 Wi-Fi와 셀룰러 네트워크의 비교 결과를 저장해 접속 경로 차이를 확인하세요.
- 특정 웹사이트 하나만 느림: 정상적으로 접속되는 다른 대상을 비교해 보세요. 대상 사이트, 콘텐츠 전송 경로, 노드 출구 모두 영향을 줄 수 있습니다.
‘거리가 더 가깝다’는 이유만으로 경로가 더 빠르다고 판단하지 마세요. 지리적 거리, 통신망 간 연결, 혼잡, 대상 사이트가 선택한 콘텐츠 전송 위치는 서로 다른 요소입니다. 같은 조건에서 요청 결과를 비교해 판단해야 합니다.
5. 노드 부하: 요청이 선택한 노드를 실제로 통과하는지 확인하기
네 번째 단계에서 기존 노드의 서버 측 상태를 비교합니다. Home → Global Routing으로 이동해 현재 값을 먼저 기록하세요. Config(규칙 기반 라우팅), Proxy(프록시), Direct(직접 연결), Scene(시나리오)은 각각 의미가 다릅니다. 기본값은 앱에 표시된 값을 기준으로 합니다. 평소에는 기존 설정 요구 사항에 맞춰 사용하고, 점검 중 비교를 위해 Proxy를 임시로 선택했다면 테스트가 끝난 뒤 원래 값으로 복원하세요.
Config에서는 특정 노드를 선택해도 모든 요청이 해당 노드를 거치는 것은 아닙니다. DOMAIN-SUFFIX는 도메인 접미사, IP-CIDR은 IP 주소 대역, GEOIP는 IP 주소의 지리적 위치를 기준으로 일치하며 FINAL은 최종 규칙입니다. 실제 처리 결과는 규칙 순서와 정책에도 좌우됩니다. Scene은 기존 시나리오 정의를 함께 확인해야 하며, 고정된 프록시 정책으로 간주해서는 안 됩니다.
- 같은 대상으로 새 요청을 한 번 보내고 Log에서 적용된 정책, 아웃바운드 또는 관련 연결 기록을 확인하세요. 필드 이름은 현재 앱에 표시된 값을 기준으로 합니다.
- 요청이 Direct로 처리됐다면 먼저 라우팅 원인을 확인하세요. 선택한 프록시 노드의 속도 때문이라고 결론 내리지 마세요.
- 사용할 수 있는 노드가 여러 개라면 대상, 접속 네트워크, 라우팅 설정을 그대로 유지하고 노드만 바꿔 비교하세요.
- 같은 테스트를 시간대를 달리해 반복하세요. 혼잡 시간에만 느리다면 네트워크 혼잡이나 부하가 원인일 수 있지만, 클라이언트 결과만으로 서버 CPU, 접속자 수, 속도 제한 상태를 확정할 수는 없습니다.
6. Log 오류: 속도 관련 키워드를 추측하지 말고 발생 단계별로 확인하기
앱 내 Log(로그)를 열고 느리거나 실패하는 요청을 한 번 재현한 뒤, 해당 시각 전후의 기록만 확인하세요. Log의 진입 경로와 기록 가능한 내용은 현재 앱에 표시된 정보를 기준으로 합니다. 아래 영어 문구는 네트워크 로그에서 자주 볼 수 있는 오류입니다. 구체적인 접두어, 대소문자, 전체 문맥은 다를 수 있으며 매번 같은 오류 문구가 표시되는 것은 아닙니다.
오류: i/o timeout
원인: 네트워크 작업이 제한 시간 안에 완료되지 않았습니다. 이 한 줄만으로는 DNS, 연결 또는 이후 읽기·쓰기 단계 중 어디에서 발생했는지 알 수 없습니다.
해결 방법: 전후 로그에서 대상과 작업 단계를 확인하고, 같은 노드에서 접속 네트워크를 바꿔 다시 테스트한 뒤 서버 설정 확인이 필요한지 판단하세요.
오류: connection refused
원인: 연결 요청이 명시적으로 거부됐습니다. 대상 포트에서 서비스가 대기 중이 아니거나 네트워크 장비가 연결을 거부했을 수 있습니다.
해결 방법: 서버 주소와 포트가 기존 설정과 일치하는지 확인하고 해당 포트의 서비스 상태를 서비스 제공업체에 문의하세요.
오류: certificate has expired or is not yet valid
원인: 인증서 유효 기간 확인에 실패했습니다. 인증서 상태나 기기 시간이 잘못됐을 수 있습니다.
해결 방법: 먼저 기기의 날짜와 시간을 확인하세요. 시간이 맞다면 서버 인증서를 점검하고, 검증을 꺼서 문제를 덮지 마세요.
- 로그 오류가 구독 업데이트 주소를 가리키더라도 업데이트 작업에 문제가 있다는 뜻일 뿐, 이미 가져온 노드의 데이터 전달 속도에 문제가 있다고 단정할 수는 없습니다.
- 로그를 다른 사람에게 전달하기 전에 구독 인증 정보, 암호, 키, 불필요한 접속 기록을 숨기세요. 시간, 오류 발생 단계, 비교 조건은 남겨 두세요.
- 증거를 확인하는 대신 장시간 반복해서 재연결하지 마세요. 연속 재시도는 연결 상태를 바꿀 수 있지만 처음 어느 구간에서 대기했는지는 설명해 주지 않습니다.
7. 자주 묻는 질문과 설정 복원 확인
Ping은 수십 ms인데 동영상이 계속 버퍼링되는 이유는 무엇인가요?
Ping은 처리량 테스트가 아닙니다. 특정 동영상 구간을 정하고 같은 노드를 유지한 채 Wi-Fi와 셀룰러 네트워크에서 지속 로딩 상태를 비교하세요. 이어서 Log에서 해당 요청이 실제로 선택한 아웃바운드를 사용했는지 확인합니다.
Proxy로 바꾸면 정상인데 Config로 돌아가면 느립니다. 어떻게 확인하나요?
먼저 Config에서 같은 대상을 다시 요청하고 일치한 규칙과 정책을 확인한 뒤 Config(구성)에서 관련 규칙 순서를 살펴보세요. 해당 요청에 DOMAIN-SUFFIX, IP-CIDR, GEOIP, FINAL이 어떻게 적용되는지 중점적으로 확인하고, 전체 구성을 계속 전역 프록시로 바꾸지는 마세요.
프로토콜만 바꾸면 반드시 빨라지나요?
아닙니다. 자체 서버가 해당 프로토콜을 지원하고 설정이 완전하며 경로에서 필요한 전송을 허용할 때만 비교할 수 있습니다. 먼저 연결과 요청이 안정적인지 확인한 뒤 같은 대상과 접속 네트워크에서 비교하세요.
점검이 끝난 뒤 어떤 설정을 원래대로 돌려야 하나요?
테스트 전에 기록한 Global Routing, Settings → On Demand 조건, 임시로 변경한 설정을 복원한 다음 원래 대상에 다시 접속해 확인하세요. 효과가 있었던 개별 수정 사항은 유지하되 테스트용 임시 설정을 평소 기본값으로 사용하지 마세요.
점검을 마친 뒤에는 ‘어떤 네트워크에서, 어떤 노드와 라우팅 설정을 사용해, 어떤 대상을 요청했을 때 어느 단계에서 대기했는지’를 설명할 수 있어야 합니다. 조건이 아직 고정되지 않았다면 DNS, 포트, 프로토콜을 계속 바꿀수록 변수가 늘어납니다. 먼저 비교 기록을 갖춘 뒤 원인을 찾은 구간을 점검하세요.