이미 서비스 제공업체와 구독을 이용 중이며 연결은 되지만 속도가 느린 경우를 대상으로 합니다. 먼저 Home의 노드와 Global Routing을 기록하고, 테스트 대상을 고정한 뒤 노드, 경로, 프로토콜, 로컬 네트워크 순서로 비교하세요. 한 번에 변수 하나만 바꾸고, 첫 화면이 뜨기까지 걸리는 시간과 지속 전송 속도, 오류 로그를 따로 확인하면 지연 시간 수치를 다운로드 속도로 오해하지 않을 수 있습니다.
1. 연결 경로와 ‘느림’의 구체적인 증상부터 확인
Shadowrocket은 Apple 플랫폼용 유료 앱으로, 주로 iPhone과 iPad에서 사용하며 App Store에서만 받을 수 있습니다. App Store 페이지에서 개발자 Shadow Launch Technology Limited와 앱 ID 932747118를 확인할 수 있습니다. 앱은 일회성 구매 방식이며, 시스템 요구 사항과 유니버설 구입 지원 여부는 App Store 페이지를 기준으로 확인하세요. 앱 구매와 네트워크 서비스 요금제는 별개입니다. 이 글은 이미 이용 중인 연결을 점검하는 방법만 안내하며, 노드나 구독을 제공·판매·추천하지 않습니다.
‘연결됨’은 터널이 만들어졌다는 뜻일 뿐, 대상 요청이 현재 선택된 노드를 사용한다는 의미는 아닙니다. Home → Global Routing의 Proxy, Direct, Config, Scene 설정에 따라 실제 경로가 달라집니다. Proxy는 프록시 경로, Direct는 직접 연결, Config는 현재 구성에 따른 처리, Scene은 설정된 시나리오에 따른 처리를 뜻합니다. 점검을 시작하기 전에 현재 선택 항목을 기록하세요. Config를 사용 중이라면 Config에서 활성화된 구성 파일과 관련 정책 선택 항목도 함께 기록해야 합니다.
증상을 나눠 기록하면 프로토콜을 바로 바꾸는 것보다 원인을 찾기 쉽습니다. 처음 페이지를 열 때만 오래 걸리고 이후 전송은 안정적이라면 DNS, 연결 수립 또는 대상 서버의 첫 바이트 응답과 관련이 있을 수 있습니다. 다운로드가 계속 느려진다면 경로 혼잡, 서버 부하, 로컬 무선 네트워크 품질을 확인하세요. 특정 사이트만 느리다면 먼저 해당 요청에 적용된 규칙과 대상 서비스 상태를 확인해야 합니다.
- 첫 화면 대기 시간: 같은 페이지에서 접속을 시작한 시점부터 주요 콘텐츠가 표시될 때까지 걸린 시간을 기록하세요. 첫 방문과 재방문을 구분해야 합니다. 캐시가 결과에 영향을 줄 수 있습니다.
- 지속 전송: 접근 권한이 있는 동일한 파일을 사용해 최소 30초 동안 확인하세요. 순간 최고 속도를 안정적인 전송 속도로 간주하지 마세요.
- 연결 실패: 발생 시각, 대상 도메인, 로그 원문을 기록하세요. 다른 사람에게 전달하기 전 구독 인증 정보, 비밀번호, 개인적인 접속 내용을 삭제하세요.
2. 노드 점검: 지연 시간이 짧아도 처리량이 높다는 뜻은 아닙니다
Home의 연결 또는 지연 시간 테스트는 접속 불가 항목을 가려내는 데 유용하지만, 이것만으로 대역폭이 충분하다고 판단할 수는 없습니다. 짧은 요청이 빠르게 완료되어도 서버의 외부 연결, 장시간 연결 전송, 대상 웹사이트까지의 경로가 정상이라는 뜻은 아닙니다. 한 번 시간 초과가 발생했다고 노드가 작동하지 않는다고 단정하지 말고, 같은 조건으로 다시 테스트하세요.
- Home에서 현재 노드의 이름, 유형, 연결 상태를 기록하세요. 정책 그룹을 사용하는 경우 사용 가능한 요청 기록을 확인해 실제로 선택된 아웃바운드를 확인해야 합니다. Home의 선택 표시만으로 판단하지 마세요.
- 네트워크, 대상 파일, Global Routing 설정을 그대로 둔 채 현재 노드를 세 번 테스트하세요. 그런 다음 이미 이용 중인 구독에 포함된 다른 사용 가능한 노드로 바꿔 같은 테스트를 반복하세요.
- 지연 시간, 첫 화면 대기 시간, 안정적인 전송 속도를 각각 기록하세요. 속도 단위를 통일해야 합니다.
1 MB/s = 8 Mbps이므로 화면에 표시된 단위가 다르면 숫자만으로 비교할 수 없습니다. - 특정 노드에서만 계속 문제가 발생한다면 해당 노드의 서버 주소, 포트, 인증 정보를 먼저 확인하세요. 구독 관리 기록을 확인해 구독이 업데이트되었는지 살펴보고, 임시로 수동 변경한 설정을 오래 유지하지 않도록 합니다.
결론: 지연 시간이 비슷하다면 같은 대상을 지속 전송해 비교하세요
기존 노드 두 개의 지연 시간이 비슷한데 한 노드에서만 세 차례 전송 테스트 내내 멈춤 현상이 반복된다면, DNS와 규칙, 프로토콜을 한꺼번에 바꾸기보다 해당 노드의 테스트 결과부터 정리하세요.
3. 경로 점검: 시간대와 대상을 비교해 경로 차이 찾기
같은 노드도 시간대에 따라 속도가 달라질 수 있습니다. 접속 네트워크에서 서버까지의 경로 혼잡, 서버 외부 연결 부하, 대상 측 속도 제한 등이 원인일 수 있습니다. 노드 이름에 표시된 지역만으로 실제 라우팅 경로를 알 수 없으며, 한 웹사이트에서 측정한 속도를 전체 경로의 성능으로 일반화할 수도 없습니다. 앱에서 증상을 기록할 수는 있지만 원격 대역폭이나 통신 사업자의 경로를 직접 개선할 수는 없습니다.
| 비교 방법 | 기록할 증상 | 다음 단계 |
|---|---|---|
| 같은 노드·같은 대상, 다른 시간대 | 특정 시간대에만 계속 속도가 느려지는지 확인 | 다른 시간대에 다시 테스트하고, 시각과 결과를 이용 중인 서비스 제공업체에 전달하세요 |
| 같은 노드·같은 네트워크, 다른 대상 | 특정 사이트나 파일 제공처만 느린지 확인 | 먼저 적용된 규칙을 확인한 뒤 대상 서비스가 정상인지 살펴보세요 |
| 같은 대상·같은 네트워크, 이미 이용 중인 다른 노드 | 특정 아웃바운드에서만 장시간 멈추는지 확인 | 정상과 이상 결과를 모두 남겨 비교하고 노드 상태를 확인하세요 |
| 같은 노드·같은 대상, 다른 접속 네트워크 | Wi-Fi와 셀룰러 네트워크에서 차이가 뚜렷한지 확인 | 로컬 네트워크와 접속 경로를 점검하세요 |
예를 들어 ‘같은 대상이 Wi-Fi에서 세 차례 연속 멈췄지만 셀룰러 네트워크로 바꾸자 계속 전송됐다’고 기록할 수 있습니다. 이는 원인을 좁히기 위한 단서일 뿐, 원격 서비스 품질에 대한 결론은 아닙니다. Wi-Fi, 라우터, 인터넷 회선의 외부 연결, 서버까지의 경로가 모두 달라졌으므로 범위를 더 좁혀야 합니다. 이 사례는 기록 방법을 보여 주는 예시이며, 이 사이트에서 직접 측정한 결과가 아닙니다.
4. 프로토콜 점검: 전송 조건을 확인하고 설정을 무작정 바꾸지 않기
프로토콜은 단독으로 속도를 높이는 스위치가 아닙니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 조건이 서로 다르며, 실제 속도는 서버 구현, 암호화 처리, 하위 전송 계층, 혼잡 제어, 네트워크 제한의 영향도 받습니다. 서비스 제공업체가 여러 프로토콜을 지원하더라도 외부 연결과 경로까지 함께 달라졌다면 속도 차이를 프로토콜 탓으로만 돌릴 수 없습니다.
| 프로토콜 또는 전송 방식 | 확인할 조건 | 점검 범위 |
|---|---|---|
| Shadowsocks | 서버, 포트, 비밀번호, 암호화 방식을 동일하게 설정하세요. UDP 지원 여부는 서버와 구성에 따라 달라집니다 | 인증 정보나 방식이 잘못됐다면 먼저 연결 설정을 바로잡으세요. 반복 속도 테스트로 확인을 대신하지 마세요 |
| VMess / VLESS | 사용자 ID, 전송 유형, TLS와 관련 전송 매개변수가 서버 설정과 일치해야 합니다 | 프로토콜 이름만 바꾸고 맞지 않는 필드를 그대로 두지 마세요 |
| Trojan | 비밀번호, 포트, TLS 서버 이름, 인증서 검증 조건을 확인하세요 | TLS 실패는 핸드셰이크 문제입니다. 인증을 끄는 방식으로 문제를 덮지 마세요 |
| Hysteria2 | QUIC 기반으로 UDP 경로를 사용할 수 있어야 합니다. 인증 정보와 서버 요구 사항을 확인하세요 | 네트워크에서 UDP를 제한하면 연결되지 않을 수 있으며, 다른 프로토콜보다 빠르다고 보장할 수 없습니다 |
| WireGuard | UDP 엔드포인트, 키, 주소, 라우팅 범위를 확인하세요 | 핸드셰이크가 정상이어도 대상 라우팅을 확인하세요. 다른 구성의 MTU를 임의로 적용하지 마세요 |
TLS를 사용하는 경우 443 포트가 흔하지만 모든 노드에서 고정으로 사용하는 것은 아닙니다. 이미 이용 중인 서비스 제공업체가 안내한 포트를 사용해야 합니다. Hysteria2의 대역폭 매개변수도 기기 속도를 보장하는 값이 아니며, 값을 무작정 높이면 혼잡이 심해질 수 있습니다. 서버 안내나 테스트 근거가 없다면 구독에 지정된 매개변수를 그대로 두세요.
로그 예시: connection refused
원인 및 해결: 대상 엔드포인트나 중간 장비가 연결을 거부한 상태입니다. 서버 주소, 포트, 서비스 상태를 확인한 뒤 다시 테스트하세요. 일반적인 대역폭 부족으로 취급하지 마세요.
로그 예시: i/o timeout
원인 및 해결: 제한된 시간 안에 작업이 완료되지 않았다는 뜻입니다. 로그 주변 내용을 확인해 DNS, 연결 시도, 데이터 읽기 중 어느 단계에서 발생했는지 파악한 다음, 같은 노드에서 접속 네트워크를 바꿔 비교하세요.
위 문구는 네트워크 오류에서 나타날 수 있는 로그 일부이며, 실패할 때마다 똑같이 표시된다는 뜻은 아닙니다. 실제 로그의 앞뒤 내용을 보존하고 특히 실패가 발생한 단계를 확인하세요. ‘시간 초과’라는 문구만으로 프로토콜을 바꿔야 하는지 판단할 수 없습니다.
5. 로컬 네트워크 점검: Wi-Fi, 셀룰러 네트워크, DNS를 나눠 확인
로컬 연결 문제는 구독 업데이트, 노드 테스트, 웹페이지 접속에 모두 영향을 줄 수 있습니다. 기기가 Wi-Fi에 연결된 상태에서 셀룰러 데이터를 꺼도 셀룰러 네트워크로 전환해 테스트한 것이 아닙니다. 비교 테스트를 하려면 시스템 Settings → Wi-Fi에서 현재 Wi-Fi 연결을 끊고 실제로 셀룰러 네트워크를 사용 중인지 확인하세요. 테스트 파일로 인한 데이터 사용량도 유의해야 합니다.
- 로컬 기준 확인: 기기 위치를 고정하고 다른 대용량 작업은 일시 중지하세요. 직접 접속할 수 있는 같은 대상을 이용해 일반 접속도 느린지 확인합니다. 똑같이 느리다면 먼저 라우터와 인터넷 회선 상태를 점검하세요.
- 무선 간섭 확인: 라우터 가까이에서 다시 테스트하고, 가능하면 2.4 GHz와 5 GHz를 비교하세요. 주파수 대역이 속도를 보장하지는 않습니다. 거리, 장애물, 혼잡한 채널이 결과에 영향을 줍니다.
- 접속 네트워크 전환: 같은 노드, 모드, 대상을 유지하고 셀룰러 네트워크로 바꿔 세 번 반복 테스트하세요. 차이가 계속된다면 구성을 바로 다시 만들기보다 접속 네트워크에서 서버까지의 경로를 추가로 확인하세요.
- DNS와 전송 구분: 도메인을 처음 열 때만 오래 기다린다면 Config의 현재 구성에서
[dns]설정과 DNS 로그를 확인하세요. 연결된 뒤에도 속도가 계속 느리다면 DNS만 바꿔서는 처리량 문제가 해결되지 않는 경우가 많습니다. - 자동 연결 확인: Settings → On Demand에서 활성화된 조건을 기록하세요. 테스트 중 연결이 자동으로 다시 시작된다면 해당 조건이 원인인지 확인합니다. 임시로 끌 때는 원래 값을 기록해 두고 테스트 후 복원하세요.
결론: 실제 접속 네트워크를 고정한 뒤 설정을 비교하세요
기기가 Wi-Fi와 셀룰러 네트워크 사이를 자동으로 전환하면 두 번의 테스트 결과를 공정하게 비교할 수 없습니다. 먼저 시스템에서 현재 사용 중인 네트워크를 확인한 다음 Shadowrocket 설정을 조정할지 결정하세요.
6. 규칙 및 재확인: 요청이 의도한 아웃바운드를 사용하는지 확인
Config 모드에서는 일반적으로 규칙이 순서대로 적용됩니다. DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR은 IP 주소 범위를, GEOIP는 IP 위치 데이터베이스를 기준으로 매칭하며, FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. 도메인 조회, 규칙 순서, 정책 그룹 선택에 따라 최종 경로가 달라질 수 있습니다. Home에서 선택된 노드를 바꿔도 특정 정책으로 고정된 요청의 경로까지 바뀌는 것은 아닙니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY이 코드는 규칙 문법을 보여 주는 예시일 뿐입니다. example.com은 예시 도메인이므로 기존 구성을 그대로 덮어쓰는 데 사용하지 마세요. no-resolve는 해당 IP 규칙을 위해서만 도메인을 조회하는 일을 피하는 옵션이지, 일반적인 속도 향상 설정이 아닙니다. 현재 구성의 복사본을 보관한 뒤 문제가 있는 대상에 적용된 규칙과 실제 아웃바운드를 확인하세요. 잠시 Proxy로 바꾸었을 때 증상이 달라진다면 원래 구성의 경로를 더 확인해야 한다는 뜻이지만, 규칙 자체가 잘못되었다고 단정할 수는 없습니다.
지연 시간은 짧은데 동영상은 왜 계속 버퍼링되나요?
짧은 요청의 지연 시간과 지속 전송 처리량은 서로 다른 지표입니다. 같은 동영상이나 파일 제공처를 같은 접속 네트워크에서 세 번 테스트한 다음, 이미 이용 중인 다른 노드와 비교하세요. 대상 요청의 실제 아웃바운드가 규칙에 따라 다른 정책으로 고정되어 있지 않은지도 확인해야 합니다.
Proxy로 바꾸니 빨라졌는데 계속 사용해도 되나요?
먼저 차이를 기록하고 Config로 돌아가 대상에 적용된 규칙과 정책 그룹을 확인하세요. Proxy는 조건을 통제한 비교 테스트에 쓸 수 있지만 다른 요청의 라우팅 방식도 바꿉니다. 테스트가 끝나면 원래 모드로 복원한 뒤 해당 대상에 맞게 구성을 수정하세요.
구독을 업데이트하면 속도 문제가 해결되나요?
서버 주소, 포트, 구성이 변경된 경우에만 업데이트로 오래된 정보를 바로잡을 수 있습니다. Home에서 이미 이용 중인 구독을 업데이트하고 대상 항목이 바뀌었는지 확인하세요. 업데이트에 성공해도 경로 혼잡까지 해소된 것은 아닙니다.
모든 프로토콜이 느린데 앱을 재설정해야 하나요?
먼저 같은 노드에서 Wi-Fi와 셀룰러 네트워크를 비교하고 직접 접속할 수 있는 대상도 확인하세요. 로컬 구성에 문제가 있다는 점이 분명할 때만 구성을 복원하는 방안을 고려하세요. 초기화 전에는 구성과 필요한 기록을 보관해 원인을 파악할 근거가 사라지지 않도록 합니다.
문의 전 최소한의 재현 기록을 남기세요
- 기기, 접속 네트워크, 테스트 시각, Home → Global Routing의 선택 항목을 적으세요.
- 노드 유형, 대상 접속 유형, 세 차례 테스트 결과, 속도 단위를 적으세요. 비밀번호, 키, 전체 구독 링크는 보내지 마세요.
- 문제가 발생하기 전후의 설정 변경을 하나씩 적으세요. 예: ‘같은 노드에서 Wi-Fi를 셀룰러 네트워크로 변경’. ‘다 해 봤다’고만 적지 마세요.
- 임시로 변경한 모드, On Demand 조건, 테스트 구성을 원래대로 복원한 다음 평소 이용하는 대상에서 다시 확인하세요.
단계별 점검의 목표는 모든 문제에 통하는 설정 하나를 찾는 것이 아닙니다. 문제가 로컬 접속, 서버까지의 경로, 서버 전송 조건, 규칙 또는 대상 응답 중 어디에서 발생하는지 확인하는 것이 중요합니다. 근거가 충분해진 뒤 해당 단계만 최소한으로 수정하세요. 원격 서비스 상태와 관련된 문제라면 개인정보를 가린 기록을 이용 중인 서비스 제공업체에 전달해 확인을 요청하세요.