Shadowrocket 연결 후 속도가 느리다고 해서 곧바로 앱이나 프로토콜을 원인으로 단정할 수는 없습니다. 이미 이용 중인 서비스 제공업체와 구독이 있다는 전제에서, 먼저 테스트 조건을 통일한 다음 노드, 회선, 프로토콜, 로컬 네트워크를 차례로 비교합니다. 지연 시간, 처리량, 연결 실패를 구분하고 재확인할 수 있도록 기록하면 설정을 점검할지, 접속 네트워크를 바꿔 볼지, 서비스 제공업체에 문의할지 판단하는 데 도움이 됩니다.
먼저 기준을 정하세요: 지연 시간이 짧아도 다운로드가 빠른 것은 아닙니다
지연 시간 테스트는 특정 방식으로 측정한 응답 시간을 보여 주고, 처리량은 일정 시간 동안 전송할 수 있는 데이터 양을 나타냅니다. 측정하는 대상이 서로 다릅니다. 노드 목록에서 응답이 빠르다고 해서 대상 웹사이트까지의 경로, 지속 전송 성능, 저녁 시간대 부하까지 더 좋다고 볼 수는 없습니다. 한 번 시간 초과가 발생했다고 노드를 계속 사용할 수 없다고 단정해서도 안 됩니다.
Home에서 현재 연결 상태와 선택한 노드, Global Routing을 먼저 확인하세요. 테스트 방식을 기록하고, 서로 다른 방식으로 측정한 수치를 한데 모아 순위를 매기지 마세요. 앱에서 연결 권한을 승인받았다고 해서 원격 서비스에 대한 실제 요청까지 정상적으로 완료된 것은 아닙니다.
- 다른 기기나 앱의 대용량 전송을 일시 중지하고, 같은 대상 페이지나 테스트 리소스를 사용하세요.
- Global Routing, 노드, 접속 네트워크를 동일하게 유지하세요. 각 조건에서 3회 반복해 범위를 기록하고, 가장 빠른 결과만 적지 마세요.
- ‘처음 열릴 때까지 대기’, ‘전송 시작 후 속도 저하’, ‘전송 중 멈춤’, ‘페이지가 전혀 열리지 않음’을 구분해 기록하세요.
- 한 번에 변수 하나만 바꾸세요. 전환한 뒤 연결을 새로 설정하고 같은 요청을 다시 실행해야 기존 연결의 영향을 배제할 수 있습니다.
대용량 파일 테스트는 데이터를 많이 사용할 수 있습니다. 셀룰러 네트워크에서는 먼저 요금제 잔여량을 확인하세요. 여기서 안내하는 테스트 횟수는 문제를 점검하기 위한 방법이지 성능 기준이나 속도 보장이 아닙니다.
1단계: 기존 노드를 비교해 특정 노드의 문제부터 확인
Home에서 기존 노드의 지연 시간 테스트를 실행하고, 같은 테스트 방식으로 연속 측정한 결과를 기록한 다음 실제 요청으로 확인하세요. 한 노드에서만 계속 시간 초과가 발생하고 다른 노드로는 같은 대상에 접속된다면 해당 노드의 주소, 포트, 인증 정보, 서버 상태를 먼저 점검하세요. 모든 노드에서 문제가 생기면 공통 원인을 확인하고, 근거 없이 설정을 하나씩 바꾸지 마세요.
| 관찰된 현상 | 의미 | 다음 단계 |
|---|---|---|
| 특정 노드에서 연속으로 시간 초과 발생 | 해당 엔드포인트나 그 경로에 문제가 집중됐을 가능성이 있습니다 | 서비스 제공업체가 안내한 주소와 포트, 서비스 유효 상태를 확인하세요 |
| 지연 시간은 안정적이지만 지속 전송이 느림 | 탐지 연결은 가능해도 처리량은 제한될 수 있습니다 | 같은 리소스의 지속 전송 성능을 비교하세요 |
| 모든 노드에서 동시에 속도 저하 | 공통 회선이나 로컬 네트워크 문제일 수 있습니다 | 노드를 고정한 채 Wi-Fi와 셀룰러 네트워크를 전환하세요 |
| 특정 웹사이트만 느림 | 대상 서비스나 특정 라우팅 경로의 문제일 수 있습니다 | 해당 요청에 적용된 규칙과 실제 아웃바운드 경로를 확인하세요 |
노드 이름에 표시된 지역이나 태그만으로 실제 경로를 확인할 수는 없습니다. 이름이 다른 두 노드도 같은 출구를 공유할 수 있습니다. 노드 태그는 식별 정보로만 보고, 회선이 서로 독립적이라는 증거로 간주하지 마세요. 구독을 업데이트해야 한다면 기존 Subscribe 항목의 업데이트 기능을 사용하세요. 구독 주소는 서비스 제공업체에서 확인하고, 업데이트 후 선택된 노드가 바뀌었는지도 점검하세요.
요약: 반복 테스트에 사용할 기준 노드를 하나 정하세요
기존 노드 중 같은 요청을 안정적으로 완료하는 노드를 하나 골라 비교 기준으로 삼으세요. 설정을 하나 바꿀 때마다 같은 대상으로 다시 확인하고, 기준 노드까지 함께 느려졌다면 공통 원인부터 살펴보세요.
2단계: 시간대별 회선 상태를 기록해 혼잡과 대상 사이트 문제 구분
클라이언트에서 노드까지, 노드에서 대상 서비스까지 어느 구간에서든 병목이 생길 수 있습니다. 특정 시간대에 모든 요청이 느려진다면 공유 경로의 부하와 관련이 있을 수 있습니다. 특정 사이트만 느리다면 대상 사이트의 속도 제한, 콘텐츠 전송 경로, 서비스 장애도 고려해야 합니다. 한 번의 속도 테스트만으로 어느 구간이 혼잡한지 판단할 수는 없습니다.
기기, 노드, 대상을 동일하게 유지하고 문제가 발생한 시간대와 비교적 한산한 시간대에 각각 기록을 남기세요. 다른 리소스를 사용하면 파일 크기, 캐시 적중 여부, 원격 측의 제한이 결과에 영향을 주므로 비교의 의미가 줄어듭니다. 여러 속도 테스트를 동시에 실행하지 마세요. 같은 대역폭을 두고 서로 경쟁하게 됩니다.
- 시간: 서비스 제공업체가 운영 기록과 대조할 수 있도록 현지 시간과 시간대를 적으세요.
- 접속 방식: Wi-Fi 또는 셀룰러 네트워크 중 무엇을 사용했는지, 테스트 중 접속 방식을 전환했는지 적으세요.
- 대상: 노드 태그, 프로토콜 유형, 대상 호스트 이름을 기록하세요. 비밀번호나 전체 구독 주소는 기록하지 마세요.
- 측정 항목: 지연 시간, 시간 초과 횟수, 페이지가 응답하기 시작할 때까지 걸린 시간, 지속 전송 속도를 각각 기록하세요.
- 단위: 측정값이 Mbps인지 MB/s인지 확인하세요. 10진 단위로 환산하면 8 Mbps는 약 1 MB/s에 해당하며, 실제 전송 속도는 프로토콜 오버헤드의 영향도 받습니다.
같은 조건에서 특정 시간대에만 반복적으로 느려진다면 기록을 서비스 제공업체에 전달하고 엔드포인트 부하와 경로 상태를 문의하세요. DNS를 반복해서 변경하거나 같은 구독을 다시 가져와도 원격 구간의 혼잡이 바로 해소되지는 않습니다. 속도 테스트 대상은 정상이지만 실제 이용 사이트에 문제가 있다면 해당 서비스 요청을 기준으로 점검하세요.
3단계: 프로토콜과 전송 매개변수 확인—추측으로 설정을 바꾸지 마세요
Home → Add Server에서 직접 입력하거나 기존 노드의 상세 정보를 확인할 때 프로토콜 유형, 포트, 인증 정보, 전송 방식, TLS 매개변수가 서비스 제공업체의 안내와 일치해야 합니다. 포트 번호는 엔드포인트 설정의 일부입니다. 예를 들어 서비스 제공업체가 443을 명시한 경우에만 해당 값을 입력하세요. HTTPS에 자주 쓰이는 포트라는 이유만으로 모든 노드의 포트를 바꾸면 안 됩니다.
| 프로토콜 | 우선 확인할 항목 | 속도 문제 점검 시 유의 사항 |
|---|---|---|
| Shadowsocks | 주소, 포트, 암호화 방식, 비밀번호 | 방식이나 비밀번호가 일치하지 않으면 요청이 실패할 수 있습니다. 포트 연결 여부만 확인해서는 충분하지 않습니다. |
| VMess / VLESS | UUID, 전송 방식, TLS, 서비스 제공업체가 지정한 Host 및 경로 | 유형만 바꾼다고 서로 대체되는 것은 아닙니다. 전송 매개변수는 서버 설정과 일치해야 합니다. |
| Trojan | 비밀번호, TLS, Server Name | 도메인이나 인증서 검증에 실패하면 설정을 바로잡으세요. 연결을 위해 검증을 끄면 안 됩니다. |
| Hysteria2 | 인증 정보, TLS, UDP 연결 가능 여부 | QUIC 기반이므로 접속 네트워크에서 UDP가 제한되면 연결에 실패하거나 불안정할 수 있습니다. |
| WireGuard | 키, 엔드포인트, 주소, 라우팅 관련 설정 | UDP 기반입니다. 서버에 트래픽이 도달했는지와 응답 경로가 정상인지도 확인해야 합니다. |
Hysteria2는 패킷 손실이나 지연 시간이 큰 일부 환경에서 유리할 수 있지만, 효과는 종단 간 경로와 서버 설정에 따라 달라집니다. 모든 네트워크에서 더 빠르다고 볼 수는 없습니다. 대역폭 매개변수를 임의로 입력하거나 다른 프로토콜의 포트, 인증 정보, 전송 설정을 그대로 복사하지 마세요.
오류: connection refused
원인: 대상 엔드포인트나 경로상의 장치가 연결을 명시적으로 거부한 상태입니다. 포트에서 서비스가 대기 중이지 않거나 접속 정책이 제한될 수 있습니다.
해결: 주소와 포트를 확인하세요. 같은 엔드포인트에서 오류가 계속되면 서비스 제공업체에 서비스 상태를 문의하세요.
오류: i/o timeout
원인: 읽기 또는 쓰기 단계가 제한 시간 안에 완료되지 않았습니다. 이 오류만으로 혼잡, 필터링, 서버 무응답을 구분할 수는 없습니다.
해결: 오류가 발생한 단계를 기록하고, 노드를 고정한 채 접속 네트워크를 전환한 다음 기존 기준 노드로 다시 테스트하세요.
위 오류 문구는 연결 로그에 나타날 수 있는 예시이며, 모든 프로토콜에서 같은 문구가 표시되는 것은 아닙니다. 마지막 한 줄만 잘라내기보다 실제 로그의 앞뒤 내용을 함께 보관하는 편이 도움이 됩니다. 제출 전에 인증 정보와 개인 접속 기록을 삭제하세요.
분기 경로 확인: 느린 요청이 테스트 노드를 실제로 거치는지 확인
Home → Global Routing에서 Proxy, Direct, Config 설정에 따라 요청의 아웃바운드 경로가 달라집니다. 노드를 비교할 때는 사용 목적과 데이터 사용량을 확인한 뒤 Proxy를 임시로 사용할 수 있습니다. 테스트가 끝나면 원래 설정으로 되돌리세요. Config의 경우 Config에서 활성화한 구성과 일치한 규칙을 함께 확인해야 합니다. Direct 결과는 노드 처리량 테스트 결과로 볼 수 없습니다.
Scene을 사용한다면 해당 장면과 연결된 설정도 확인하세요. 노드 목록에서 선택된 상태만 보고 실제 아웃바운드 경로를 판단하지 마세요. 규칙은 순서대로 적용되므로 노드를 계속 바꾸기보다 대상 요청에 어떤 규칙이 적용됐는지 확인하는 편이 효과적입니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY아래 설명은 규칙의 의미를 안내하기 위한 것이며 기존 설정을 덮어쓰라는 뜻은 아닙니다. DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR는 IP 주소 대역을, GEOIP는 IP 지리 정보를 기준으로 매칭합니다. FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 예시의 example.com은 설명용 도메인입니다. 실제 설정에서는 사용자 지정 정책 이름을 사용할 수도 있습니다.
- 대상 요청에
DIRECT가 적용되면 프록시 노드를 바꿔도 해당 요청의 아웃바운드 경로는 대체로 달라지지 않습니다. - 대상 요청에
REJECT가 적용되면 회선 속도가 느린 것으로 여기지 말고 거부 규칙을 확인하세요. - 도메인 조회 단계에서 주로 지연된다면 조회 오류와 사용 중인 DNS에 연결할 수 있는지 확인하세요. DNS 문제를 대역폭 부족과 동일하게 봐서는 안 됩니다.
- 설정을 변경하기 전에 복구할 수 있는 사본을 보관하세요. 관련 항목만 하나씩 조정하고, 테스트와 확인이 끝나면 불필요한 변경 사항을 되돌리세요.
4단계: 로컬 네트워크를 바꿔 Wi-Fi와 연결 실행 조건 점검
노드와 대상을 고정한 뒤 Wi-Fi에서 셀룰러 네트워크로 전환하고, 다시 연결해 테스트하세요. 셀룰러 네트워크에서는 정상이고 Wi-Fi에서만 문제가 생긴다면 해당 Wi-Fi의 무선 품질, 라우터, 상위 회선, 네트워크 정책 등으로 원인 범위를 좁힐 수 있습니다. 다만 이 결과만으로 특정 장비의 고장이라고 단정할 수는 없습니다. 전환 과정에서 노드나 Global Routing도 바뀌었다면 먼저 조건을 원래대로 맞추세요.
- 로컬 네트워크 기준 확인: 직접 접속이 허용된 대상에서 프록시 연결 전후를 비교하세요. 프록시를 사용하지 않아도 느리다면 접속 네트워크부터 점검하세요.
- 무선 품질 확인: 라우터 가까이에서 다시 테스트하고 업로드 대역폭을 많이 사용하는 작업을 일시 중지하세요. 업로드가 포화돼도 응답 시간이 늘어날 수 있습니다.
- 인증 확인: 공용 Wi-Fi에서 웹 인증이 필요하다면 먼저 해당 네트워크에 인증한 다음 연결을 다시 시도하세요.
- 연결 실행 설정 확인: Settings → On Demand에서 실행 조건을 확인하세요. 테스트 중 연결이 다시 실행됐다면 발생 시각을 기록하고 설정에 따른 동작인지 확인하세요.
- 연결 동시 사용 여부 확인: 시스템 VPN 설정에서 현재 실제로 활성화된 연결을 확인하세요. 연결 상태 전환을 같은 터널이 계속 느려진 것으로 잘못 판단하지 않도록 주의하세요.
자주 묻는 질문과 문의 시 준비할 내용
지연 시간은 짧은데 동영상이 계속 버퍼링되는 이유는 무엇인가요?
지연 시간 측정 결과가 동영상 경로의 지속 처리량을 뜻하지는 않습니다. 노드와 Global Routing을 고정하고 같은 동영상의 로딩 상태를 비교한 뒤, 해당 요청에 실제로 적용된 규칙을 확인하세요. 특정 서비스에서만 문제가 생긴다면 대상 호스트 이름과 발생 시간대를 기록하세요.
구독을 업데이트한 뒤 느려졌습니다. 모든 노드를 다시 입력해야 하나요?
먼저 업데이트 후 선택된 노드, 프로토콜, 포트가 바뀌었는지 확인하고 업데이트 전 기록과 비교하세요. 모든 설정을 바로 삭제하지 마세요. 구독 내용이나 유효성에 의문이 있으면 서비스 제공업체에 확인하세요.
Wi-Fi에서만 Hysteria2가 불안정합니다. 어떻게 확인하나요?
해당 노드의 매개변수는 그대로 두고 셀룰러 네트워크에서 다시 연결한 뒤 같은 요청을 반복하세요. Wi-Fi에서만 문제가 생긴다면 UDP 관련 오류와 연결 시각을 기록하세요. 이렇게 하면 원인 범위를 좁힐 수 있지만, 이 현상만으로 네트워크가 UDP를 차단한다고 단정할 수는 없습니다.
휴대폰을 재시동해도 느립니다. 문의할 때 어떤 정보를 보내야 하나요?
발생 시각과 시간대, 접속 유형, 노드 태그, 프로토콜, Global Routing, 대상 호스트 이름, 3회 비교 결과를 제공하세요. 민감 정보를 가린 오류 로그도 첨부하되 비밀번호, 키, UUID, 전체 구독 링크는 보내지 마세요.
점검을 마친 뒤 원래 Global Routing과 On Demand 설정으로 되돌리고 유효한 기록은 보관하세요. 특정 노드만 문제라면 엔드포인트를, 특정 시간대에 반복되면 회선을, 특정 프로토콜에서만 발생하면 전송 조건을 우선 확인하세요. 특정 접속 네트워크에서만 문제가 생긴다면 로컬 네트워크를 계속 점검하세요. 앱을 한 번 구매하는 것과 회선 요금제는 별개입니다. 앱을 다시 구매해도 기존 회선의 대역폭이나 부하가 바뀌지는 않습니다.