Shadowrocket에 연결됨으로 표시되더라도 시스템 VPN 터널이 설정되었다는 뜻일 뿐, 모든 서버와 대상 웹사이트, 전송 프로토콜이 정상 작동한다는 의미는 아닙니다. 사용자가 이미 서비스 제공업체와 구독을 보유하고 있다고 가정하고, 먼저 테스트 조건을 고정한 뒤 서버, 경로, 프로토콜, 로컬 네트워크를 차례로 바꿔 확인합니다. 첫 화면이 뜨기까지 걸리는 시간, 전송 지속 여부, 오류, 네트워크 전환 결과를 비교하면 문제를 구체적으로 점검할 지점까지 좁힐 수 있습니다.
1. 요청 경로를 확인한 뒤 느려지는 구간 찾기
요점: 연결 스위치나 VPN 표시만으로 서버 속도를 판단하지 말고, 요청이 예상한 정책을 따르는지 먼저 확인하세요. Home에서 현재 선택된 서버를 확인한 다음 Global Routing을 살펴봅니다. Proxy는 트래픽을 프록시 방식으로 처리하고, Direct는 직접 연결 방식으로 처리하며, Config는 현재 구성의 규칙에 따라 정책을 결정합니다. 모드가 다르면 테스트 결과를 같은 기록으로 비교할 수 없습니다.
Config를 사용하는 경우 Config에서 현재 어떤 구성을 사용 중인지 먼저 확인하세요. 한 웹페이지는 DIRECT에 해당하고 다른 웹페이지는 프록시를 거칠 수 있습니다. Global Routing에서 Scene을 사용 중이라면 해당 Scene 설정을 확인한 뒤 테스트 조건을 고정하세요. Scene 변경과 서버 전환이 동시에 일어나지 않도록 합니다. 잠시 Proxy로 비교할 때는 기존 모드를 기록하고 테스트가 끝나면 원래대로 되돌리세요.
- 같은 대상 웹페이지를 정하고, 처음 열 때 오래 기다리는 문제와 전송이 시작된 뒤 속도가 느린 문제를 구분하세요.
- Home에서 Connectivity Test를 실행하고 테스트 방식, 결과, 선택한 서버를 기록하세요. 테스트 값은 해당 테스트 대상에 대한 참고 자료일 뿐입니다.
- 대상에 다시 요청을 보내고 확인 가능한 연결 기록으로 대상 도메인과 실제 적용된 정책을 살펴보세요. DIRECT 요청을 서버 속도 측정으로 간주하지 마세요.
- 간헐적으로 연결이 끊긴다면 Settings → On Demand의 연결 조건을 확인해 테스트 중 네트워크 변화에 따라 반복적으로 재연결되지 않는지 살펴보세요.
2. 비교 기록 만들기: 한 번에 변수 하나만 바꾸기
요점: 한 번의 테스트에서는 조건 하나만 바꿔야 결과를 해석할 수 있습니다. 구독을 업데이트하고, 서버를 바꾸고, 프로토콜을 수정하고, Wi-Fi까지 바꾸는 일을 동시에 하지 마세요. 다른 기기의 대량 전송을 먼저 멈추고 같은 iPhone 또는 iPad, 같은 대상, 같은 테스트 방식, 같은 테스트 시간대를 유지하세요. 웹페이지 캐시 때문에 두 번째 방문이 훨씬 빨라질 수 있으므로 캐시된 콘텐츠와 새로 불러온 콘텐츠도 구분해 기록해야 합니다.
아래는 기록 양식이며 이 사이트에서 직접 측정한 결과가 아닙니다. A와 B는 사용자가 이미 보유한 구독에 포함된 두 서버를 가리킵니다. B를 선택할 때는 프로토콜과 지역 등 다른 조건이 가능한 한 비슷한 서버를 고르세요. 적절한 비교 항목이 없다면 조건이 다르다고 명시하고 결과를 하나의 요인 탓으로 단정하지 마세요.
| 테스트 단계 | 고정 조건 | 변경한 조건 | 기록 내용 |
|---|---|---|---|
| 기준 그룹 | 서버 A, 기존 구성, 동일한 대상 | 변경 없음 | 첫 화면 대기 시간, 지속 전송 여부, 오류 발생 여부 |
| 서버 그룹 | 기존 네트워크, 동일한 라우팅 모드 | A에서 B로 변경 | 개선이 꾸준히 나타나는지, 멈춤 현상이 계속되는지 |
| 네트워크 그룹 | 서버 A, 기존 프로토콜, 동일한 대상 | Wi-Fi에서 셀룰러 네트워크로 전환 | 같은 요청이 완료되는지, 재연결에 걸린 시간은 별도 기록 |
| 시간대 그룹 | 서버 A, 기존 네트워크, 기존 구성 | 테스트 시간대 | 혼잡 시간대와 비혼잡 시간대에 일정한 차이가 있는지 |
결론: 반복해서 확인되는 차이부터 찾기
요청 한 번만 빨라졌다면 같은 조건으로 테스트를 반복하세요. 다른 조건을 고정했는데도 차이가 계속 나타날 때 해당 변수를 더 살펴보세요. 캐시나 일시적인 변동을 문제 해결 효과로 오해하지 않도록 합니다.
3. 서버 계층: 지연 시간이 짧아도 지속 전송 속도가 빠른 것은 아닙니다
요점: 서버 테스트는 연결 가능 여부와 응답 시간을 확인하는 데 도움이 되지만, 대역폭을 직접 보여 주지는 않습니다. 짧은 요청은 데이터가 적어 빠르게 응답하더라도 대용량 파일이나 동영상 조각을 지속적으로 빠르게 전송할 수 있다는 뜻은 아닙니다. 서버 부하, 출구 용량, 대상 사이트까지의 경로는 지연 시간이 정상이어도 처리량을 제한할 수 있습니다.
- 특정 서버만 느린 경우: Home에서 기존 구독 중 조건이 비슷한 다른 서버로 바꾸고 동일한 대상을 테스트하세요. A에서만 문제가 계속되면 우선 A의 상태와 연결 설정을 확인하세요.
- 특정 대상만 느린 경우: 서버를 그대로 두고 평소 사용하는 다른 대상을 테스트하세요. 다른 대상은 정상이라면 해당 대상의 규칙, DNS 조회 결과, 서버에서 대상까지의 경로를 계속 확인하세요.
- 모든 서버가 느린 경우: 현재 구성을 유지한 채 로컬 네트워크를 비교하세요. 구독에 포함된 모든 서버가 고장 났다고 바로 단정하지 마세요.
- 구독 정보가 오래되었을 수 있는 경우: 앱 내 구독 업데이트 기능으로 서비스 제공업체가 제공한 최신 정보를 가져와 업데이트 성공 여부를 확인한 다음 서버를 다시 선택하세요. 구독 관리 항목을 직접 수정해 잘못된 정보를 장기간 덮어쓰지 마세요.
지역 이름은 서비스 제공업체가 붙인 식별 정보일 뿐이며, 이름만으로 실제 중계 경로나 사용 가능한 대역폭을 판단할 수 없습니다. 서비스 제공업체에 문의할 때는 단순히 “지연 시간은 낮은데 너무 느려요”라고 하기보다 항목 이름, 테스트 시간, 네트워크 유형, 문제가 발생한 대상을 함께 전달하면 원인을 파악하기 쉽습니다.
4. 경로 계층: 시간대와 대상별 차이로 경로 문제 확인
요점: 클라이언트의 지연 시간 수치 하나만으로는 접속 구간, 중계 경로, 서버 출구, 대상 사이트 중 어느 구간이 혼잡한지 구분하기 어렵습니다. 경로 문제는 비교 자료를 바탕으로 확인해야 합니다. 같은 서버가 특정 시간대에만 느려지는지, 같은 네트워크에서 여러 서버가 모두 불안정한지, 대상을 바꾸면 문제가 사라지는지 살펴보세요.
- 서버를 고정하고 시간대를 비교하세요. 시간대를 바꿔 같은 요청을 반복하세요. 저녁에 계속 느려지고 다른 시간대에 회복된다면 시간대와 관련된 혼잡 가능성을 보여 주는 단서일 뿐, 어느 구간에서 발생하는지는 아직 알 수 없습니다.
- 대상을 고정하고 경로를 비교하세요. 이미 보유한 서버끼리 비교하세요. 같은 대상에 일부 서버만 느리다면 해당 서버들의 공통 조건을 기록해 서비스 제공업체에 추가 확인을 요청하세요.
- 대기와 전송을 구분하세요. 첫 응답이 오기까지 오래 걸리지만 이후 전송은 정상이라면 DNS 조회와 연결 수립을 확인하는 편이 좋습니다. 전송이 시작된 뒤 반복해서 멈춘다면 혼잡, 패킷 손실, 대상 측 속도 제한 가능성을 살펴보세요.
- 웹페이지 테스트와 미디어 테스트를 구분하세요. 동영상 앱의 화질 자동 조정과 버퍼링은 체감에 영향을 줍니다. 한 번 재생이 원활했다고 해서 경로 용량이 충분하다고 단정하지 마세요.
기록을 남기는 대신 연결을 반복해서 끊었다가 다시 연결하지 마세요. 재연결하면 새 세션이 만들어질 수도 있고, 일시적 혼잡을 우연히 피할 수도 있습니다. 서버, 대상, 네트워크를 고정하지 않았다면 어느 요인 때문에 나아졌는지 알 수 없습니다. 서버 경로나 출구 정보는 서비스 제공업체에 확인해야 합니다. 클라이언트에서 관찰한 내용으로는 문제 범위를 단계적으로 좁힐 수 있을 뿐입니다.
5. 프로토콜 계층: 유형을 무작정 바꾸지 말고 설정부터 확인
요점: 프로토콜은 서버 측 설정과 일치해야 하며, 속도를 높이려고 다른 프로토콜로 바꾸면 안 됩니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 인증, 전송 방식, 서버 구성이 서로 다릅니다. 서비스 제공업체가 해당 연결 정보를 제공한 경우에만 비교할 수 있습니다. 비교할 때는 서버와 경로가 같은지도 기록하세요.
| 프로토콜 또는 전송 방식 | 우선 확인할 항목 | 확인 시 유의점 |
|---|---|---|
| Shadowsocks | 주소, 포트, 비밀번호, 암호화 방식 | 암호화 방식은 서버 설정과 일치해야 합니다. |
| VMess / VLESS | UUID, 전송 유형, TLS, Host, Path | Host와 Path를 입력해야 하는지는 사용하는 전송 방식에 따라 다르며 서로 대체할 수 없습니다. |
| Trojan | 비밀번호, 포트, TLS, 서버 이름 | 인증서 이름이 일치하지 않으면 구성을 확인하세요. 속도를 높이려고 검증을 끄지 마세요. |
| Hysteria2 | 인증, TLS, UDP 연결 가능 여부, 대역폭 관련 매개변수 | QUIC 기반이며 UDP를 사용합니다. 네트워크에서 UDP를 제한하면 연결이 정상적으로 설정되지 않을 수 있습니다. |
| WireGuard | 키, Endpoint, 주소, MTU | UDP 기반입니다. 경로에 맞춰 MTU를 검증해야 하며 모든 네트워크에 공통으로 적용되는 최적값은 없습니다. |
포트 번호도 원래 구성과 하나씩 대조하세요. 예를 들어 HTTPS는 보통 TCP 443을 사용하지만, 443을 입력한다고 해서 모든 프로토콜이 해당 포트를 사용할 수 있는 것은 아니며 해당 연결이 반드시 TCP를 사용한다는 뜻도 아닙니다. Hysteria2의 UDP 연결과 TCP 443 연결 가능 여부를 혼동하지 마세요. 대역폭 관련 필드에 실제 경로의 성능을 크게 웃도는 값을 넣어 속도를 높이려 하지 마세요.
작은 요청은 완료되지만 큰 응답은 자주 멈춘다면 MTU 또는 경로 MTU 문제를 확인 항목에 포함할 수 있습니다. 다만 이것만으로 원인을 진단할 수는 없습니다. 먼저 대상 사이트 차이와 로컬 네트워크 문제를 배제한 뒤 서비스 제공업체가 안내한 설정으로 통제된 테스트를 하세요. 값을 바꾸기 전에 기존 값을 기록하고, 매번 매개변수 하나만 변경하세요. 실패하면 원래대로 되돌리고, 이른바 범용 최적화 값을 일괄 적용하지 마세요.
6. 로컬 네트워크 계층: Wi-Fi와 셀룰러 네트워크 교차 확인
요점: 같은 서버와 구성에서 특정 로컬 네트워크만 느리다면 해당 네트워크의 무선 품질, 업로드 사용량, 전송 제한을 우선 확인하세요. Wi-Fi 신호 막대 수가 실제 사용 가능한 용량을 의미하지는 않으며, 공유기 가까이에서도 간섭이 발생할 수 있습니다. 셀룰러 네트워크는 위치, 신호 품질, 요금제 상태, 기지국 부하의 영향을 받습니다.
- 서버와 대상을 고정하고 기존 Wi-Fi에서 먼저 한 세트의 테스트를 완료하세요. 기기와 다른 기기에서 진행 중인 대용량 업로드나 백업은 일시 중지하세요.
- 셀룰러 네트워크로 전환한 다음 Shadowrocket이 다시 연결될 때까지 기다리고 같은 요청을 보내세요. 네트워크 전환으로 인한 재연결 대기 시간과 웹페이지 응답 시간을 따로 기록하고 데이터 사용량도 확인하세요.
- 셀룰러 네트워크는 정상인데 Wi-Fi에서 문제가 계속되면 공유기 가까이에서 다시 테스트하세요. 가능하다면 같은 공유기의 서로 다른 무선 대역에서도 각각 확인하세요.
- 웹 인증이 필요한 Wi-Fi라면 먼저 네트워크 로그인을 완료하세요. 로그인 페이지 처리가 끝나지 않았다면 VPN 표시만으로 인터넷 출구가 사용 가능하다고 볼 수 없습니다.
- Settings → On Demand에서 요청 시 연결 조건을 확인해 네트워크 전환 후의 자동 연결 동작이 테스트에 영향을 주지 않도록 하세요. 설정을 바꾸기 전에 기존 값을 기록하고 테스트가 끝나면 복원하세요.
DNS도 따로 살펴봐야 합니다. 일반적인 DNS 조회는 UDP 또는 TCP 53을 사용할 수 있으며, 암호화된 DNS는 전송 방식이 다릅니다. 처음 방문할 때마다 오래 기다리지만 연결이 설정된 뒤에는 전송이 정상이라면 현재 구성의 DNS 설정, 조회 성공 여부, 재시도 발생 여부를 확인하세요. 한 번 DNS를 바꾼 뒤 잠시 빨라졌다는 이유만으로 모든 속도 문제가 DNS 때문이라고 단정하지 마세요.
7. 오류가 발생하면 원문으로 실패 단계부터 확인
요점: 오류는 특정 단계가 실패했다는 의미이지, 원인을 바로 알려 주는 것은 아닙니다. 아래는 네트워크 진단이나 연결 로그에서 볼 수 있는 일반적인 원문 예시입니다. 실제 전체 메시지는 기기에 기록된 내용을 기준으로 확인하세요. 발생 시각, 대상, 해당 서버를 저장하고 구독 주소, 비밀번호, UUID, 키는 함께 공개하지 마세요.
오류: connection refused
가능한 원인과 해결 방법: 연결이 명시적으로 거부된 경우입니다. 포트에서 서비스가 대기하지 않거나 연결이 적극적으로 거부되었을 수 있습니다. 먼저 서버 주소와 포트를 확인한 다음 서비스 제공업체에 해당 접속 지점의 대기 상태를 문의하세요.
오류: i/o timeout
가능한 원인과 해결 방법: 네트워크 읽기 또는 쓰기 작업이 제한 시간 안에 완료되지 않았다는 뜻입니다. 이 메시지만으로는 로컬 네트워크 문제인지 원격 서버 문제인지 판단할 수 없습니다. 서버를 고정한 채 Wi-Fi와 셀룰러 네트워크를 바꿔 테스트하고 전체 로그로 어느 단계에서 시간 초과가 발생했는지 확인하세요.
오류: TLS handshake failed
가능한 원인과 해결 방법: TLS 핸드셰이크가 완료되지 않았습니다. 이름, 인증서, 기기 시간, 연결 중단 등이 원인일 수 있습니다. 원래 TLS 설정과 시스템 시간을 확인하고 다른 네트워크에서도 비교하세요. 일반적인 해결책으로 인증서 검증을 끄지 마세요.
오류가 없지만 계속 느린 경우에도 성공 기록과 실패 기록을 함께 보관하는 것이 중요합니다. 연결을 설정한 뒤 발생하는 멈춤은 인증 실패나 TLS 핸드셰이크 실패와는 다른 문제입니다. 마지막 한 줄만 캡처해 프로토콜을 바꿔야 한다고 판단하지 말고 앞뒤 요청과 재현 조건을 함께 살펴보세요.
8. 자주 묻는 질문과 점검을 마칠 때의 기준
지연 시간은 낮은데 동영상이 계속 버퍼링되는 이유는 무엇인가요?
서버를 그대로 둔 채 같은 대상의 지속 전송 성능을 비교하고 재생 화질과 버퍼링 상태도 확인하세요. 짧은 지연 시간 테스트로는 지속 처리량이나 서버에서 동영상 콘텐츠 서버까지의 전체 성능을 확인할 수 없습니다.
Proxy로 전환하면 빨라지는데 계속 Proxy를 사용해야 하나요?
먼저 Config로 돌아가 해당 대상에 적용된 규칙과 정책을 확인하세요. DOMAIN-SUFFIX, GEOIP, IP-CIDR, FINAL은 요청이 향하는 경로에 영향을 줍니다. 두 모드의 속도 차이는 규칙을 점검할 단서이지, 모드를 계속 바꿔도 된다는 충분한 이유는 아닙니다.
Wi-Fi에서만 느린데 구독을 다시 가져와야 하나요?
서버를 고정하고 Wi-Fi와 셀룰러 네트워크에서 각각 반복 테스트하세요. 같은 구성이 셀룰러 네트워크에서 안정적으로 작동한다면 구독을 먼저 삭제하지 말고 Wi-Fi 연결과 공유기를 확인하세요. 구독을 업데이트해도 무선 간섭은 해결되지 않습니다.
Hysteria2로 바꾸면 항상 더 빨라지나요?
그렇다고 보장할 수 없습니다. 서비스 제공업체가 Hysteria2 설정을 제공하는지 확인하고 현재 네트워크에서 필요한 UDP 통신이 가능한지 테스트하세요. 비교할 때 대상과 시간대를 고정하고 서버 경로의 차이를 기록하세요. 프로토콜 이름만으로 결과를 예측하지 마세요.
점검을 마칠 때는 적어도 재현 가능한 설명을 남기세요. 예를 들어 “같은 서버와 구성을 유지하고 같은 위치에서 테스트했을 때 Wi-Fi에서는 계속 멈추지만 셀룰러 네트워크에서는 요청 세 번이 모두 완료됨”처럼 기록할 수 있습니다. 이 기록은 로컬 네트워크나 접속 경로를 우선 확인할 근거일 뿐이며 추가 검증이 필요합니다. “연결은 됐는데 느림”이라는 막연한 설명보다 후속 문제 해결에 유용합니다.
- 테스트 변경 사항 복원: 기존 Global Routing, On Demand 조건, 임시 프로토콜 설정을 원래대로 되돌리고 평소 사용하는 구성이 올바른지 확인하세요.
- 필요한 정보 전달: 테스트 시간대, 네트워크 유형, 서버 항목 이름, 대상, 오류 메시지를 전달하세요. 인증 정보와 구독 토큰은 가려야 합니다.
- 문제 담당 범위별로 대응: 로컬 네트워크 문제는 공유기와 접속 조건을 확인하고, 서버 접속 지점이나 경로 문제는 서비스 제공업체에 문의하며, 규칙 문제는 Config에서 확인하세요.