Shadowrocket 속도가 느릴 때 점검하는 방법: 노드·경로·프로토콜·로컬 네트워크 4단계 분석

시작 전: ‘느리다’를 재현 가능한 현상으로 바꾸기

Shadowrocket이 연결됨으로 표시된다는 것은 시스템 VPN 터널이 설정되었다는 뜻일 뿐, 모든 요청의 처리량이 같다는 의미는 아닙니다. 웹페이지 첫 화면 대기, 동영상 버퍼링, 파일 전송 지연, 앱의 간헐적인 로딩은 각각 DNS 응답, 연결 핸드셰이크, 지속 대역폭, 패킷 손실과 지터에 해당할 수 있습니다. 점검 전 어떤 현상인지 먼저 구분하고 단순히 ‘느리다’고만 기록하지 마세요.

반복해서 접속할 수 있는 웹페이지 하나, 직접 관리하거나 장기간 안정적인 파일 소스 하나, 동일한 앱 동작 하나를 테스트 대상으로 정하세요. 매회 최소 60초 동안 테스트하고 3회 연속 실행한 뒤 첫 번째 결과와 뒤의 두 결과가 비슷한지 기록합니다. 첫 번째만 느리고 이후 회복되면 DNS, TLS 핸드셰이크 또는 캐시 차이일 가능성이 높고, 세 번 모두 느리면 처리량이나 경로 문제에 가깝습니다.

테스트 조건 고정

1. Home에서 기존 노드 하나를 선택하고 테스트 중에는 반복해서 전환하지 마세요.
2. 현재 Global Routing 상태를 확인하고 결과를 기록합니다. 규칙 영향을 확인할 때는 Proxy를 비교 기준으로 사용하고, 평소 설정은 Config로 유지합니다.
3. 진행 중인 대용량 파일 동기화, 시스템 업데이트 및 대역폭을 계속 사용하는 작업을 종료합니다.
4. 현재 Wi-Fi와 셀룰러 중 어떤 네트워크를 사용하는지, 테스트 시간, 노드 이름, 프로토콜 유형, 연속 3회 결과를 기록합니다.
5. 테스트 후 원래 Global Routing으로 되돌려 임시 비교 설정을 장기 설정으로 사용하지 않도록 합니다.

요청은 실제로 여러 단계를 거칩니다. Home의 지연 시간 테스트는 탐색 요청의 왕복 시간을 주로 반영하며 전체 다운로드 속도는 아닙니다. 지연 시간이 낮은 노드도 지속 전송에서는 부하, 혼잡 또는 패킷 손실의 영향을 받을 수 있고, 반대로 지연 시간이 조금 높은 노드가 더 안정적인 지속 처리량을 보일 수도 있습니다. 따라서 지연 시간 수치는 1차 선별에만 사용하고 단독 결론으로 삼지 마세요.

1단계: 단일 노드 부하인지 판단하기

노드 계층의 문제는 보통 같은 네트워크, 같은 시간, 같은 테스트 대상에서 특정 기존 노드 하나만 3회 연속 느리고 동일한 구성의 다른 노드는 안정적인 형태로 나타납니다. 비교 대상은 사용자가 이미 보유한 노드 항목이어야 하며, 이름이나 지역 표시 또는 한 번의 지연 시간만으로 결론을 내리면 안 됩니다.

먼저 Home에서 현재 노드의 지연 시간 테스트를 실행한 뒤 다른 기존 노드를 선택해 같은 작업을 반복합니다. 전환 후 연결 상태가 안정될 때까지 기다리고 테스트 대상을 다시 열어 이미 캐시된 페이지를 사용하지 마세요. 두 노드가 같은 프로토콜을 사용하면 결과를 노드 부하로 판단하기 쉽지만, 프로토콜도 다르면 우선 ‘노드 또는 프로토콜 분리 필요’로 기록하고 3단계에서 계속 확인합니다.

노드 계층의 실제 점검 순서

• 규칙에 따라 서로 다른 테스트 요청이 다른 정책으로 전송되는 상황을 배제하려면 Global Routing → Proxy를 짧은 비교 기준으로 유지합니다.
• 사용자가 보유한 노드 2~3개를 선택하고 각 노드에서 동일한 테스트를 3회씩 완료합니다. 테스트 중간에는 구독을 새로 고치지 마세요.
• ‘첫 화면을 여는 데 걸린 시간’과 ‘지속 전송의 안정성’을 따로 기록하고 하나의 평가로 합치지 마세요.
• 완료 후 Config로 전환해 규칙 모드에서 결과가 달라지는지 확인합니다.

2단계: 시간대별 경로와 경로 혼잡 확인

경로 계층의 문제는 시간대와 관련된 특징이 뚜렷한 경우가 많습니다. 예를 들어 낮에는 안정적이지만 저녁 특정 시간대에 속도가 떨어지거나, 평일과 주말의 결과가 다를 수 있습니다. 노드 자체는 바뀌지 않아도 로컬 네트워크에서 노드 진입점까지의 경로가 특정 시간에 혼잡해질 수 있습니다. 이런 문제에서 그때그때 설정을 바꾸면 일시적인 회복을 특정 옵션의 효과로 오해하기 쉽습니다.

간단한 기록만으로 충분합니다. 아침, 낮, 저녁에 한 번씩 같은 네트워크, 같은 노드, 같은 대상, 같은 Global Routing으로 테스트하세요. 이틀 연속 기록했을 때 느린 현상이 비슷한 시간대에 집중되고 Wi-Fi와 셀룰러 결과가 다르다면 로컬 접속 경로를 우선 확인할 가치가 있습니다. 두 접속 방식 모두 같은 시간에 느려진다면 공통 경로나 노드 진입점 부하에 가까울 수 있습니다.

현상으로 시간대 문제 구분

• 매일 비슷한 시간대에 느려짐: 테스트 기록을 유지하고 매 회차 프로토콜과 규칙을 바꾸지 마세요.
• Wi-Fi는 느리고 셀룰러는 정상: 라우터와의 거리, 무선 대역, 신호 차단, 같은 네트워크 기기의 사용량을 우선 확인하세요.
• 두 네트워크 모두 느림: 다른 기존 노드로 한 번 비교해 공통 노드 진입점 문제인지 판단하세요.
• 속도 테스트는 정상인데 특정 웹사이트만 느림: 규칙 매칭, DNS 결과, 대상 사이트 자체의 응답을 확인하고 전체 경로의 문제로 바로 단정하지 마세요.

최고값과 안정값도 구분해야 합니다. 시작 후 몇 초 동안 최고치가 나타났다가 계속 내려가면 혼잡 제어, 패킷 손실 또는 서버 측 속도 제한의 결과일 수 있습니다. 처음부터 끝까지 안정적이지만 상한이 낮다면 고정 대역폭 조건에 가깝습니다. 최고 숫자 하나만 옮겨 적는 것보다 그래프의 추세를 기록하는 편이 유용합니다.

3단계: 프로토콜 특성과 구성 불일치 구분

Shadowrocket은 Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard 등의 프로토콜을 처리할 수 있지만 ‘프로토콜 이름’만으로 속도가 결정되지는 않습니다. 실제 결과에는 전송 계층, 암호화 방식, TLS, UDP 사용 가능 여부, MTU, 서버 구성, 로컬 네트워크 품질도 영향을 줍니다. 프로토콜을 비교할 때는 사용자의 서비스 제공자가 이미 제공하고 올바르게 구성한 항목을 사용해야 합니다.

Shadowsocks의 성능은 사용한 암호화 방식, 서버 처리 능력, TCP 또는 UDP 트래픽에 영향을 받습니다. VMess와 VLESS는 서로 다른 전송 방식을 조합할 수 있으며 추가 캡슐화와 TLS 핸드셰이크가 첫 연결 시간에 영향을 줄 수 있습니다. Trojan은 TLS over TCP 환경에서 자주 사용되며 패킷 손실이 발생하면 재전송이 두드러질 수 있습니다. Hysteria2는 QUIC과 UDP를 기반으로 하므로 네트워크의 UDP 지원 여부와 패킷 손실에 따라 결과가 달라집니다. WireGuard 역시 UDP에 의존하며 MTU가 적절하지 않으면 작은 요청은 정상인데 대용량 전송이 멈추는 현상이 나타날 수 있습니다.

서버 관련 매개변수를 임의로 변경하지 마세요

프로토콜 매개변수는 서버 측과 일치해야 합니다. 포트, 비밀번호, UUID, 키, Server Name, Public Key 또는 전송 경로 중 하나라도 다르면 연결 실패나 반복 재시도가 발생할 수 있습니다. 속도 문제를 점검할 때는 이러한 항목을 무작위로 바꾸기보다 먼저 가져온 항목이 서비스 제공자의 원래 구성과 일치하는지 확인해야 합니다.

사용자가 같은 서비스에서 목표 위치가 비슷하면서 프로토콜이 다른 항목을 보유하고 있다면 로컬 네트워크와 테스트 대상을 고정해 비교할 수 있습니다. 각 프로토콜에서 같은 테스트를 3회 실행하고 첫 응답과 지속 처리량을 따로 기록하세요. 프로토콜만 주요 변수일 때 이 비교가 의미를 가집니다.

4단계: 로컬 Wi-Fi, 셀룰러, 시스템 연결 조건 확인

로컬 네트워크는 가장 쉽게 간과되는 계층입니다. Wi-Fi 신호 막대가 많아도 무선 환경에 간섭이 없다는 뜻은 아닙니다. 같은 공간의 다른 기기가 계속 업로드하면 지연 시간이 높아지고 다운로드 속도가 낮아질 수 있습니다. 가장 직접적인 판단 방법은 노드, 프로토콜, 테스트 대상을 유지한 채 Wi-Fi와 셀룰러만 전환하는 것입니다.

셀룰러 네트워크는 안정적인데 Wi-Fi가 크게 변동한다면 먼저 라우터 가까이에서 다시 테스트하고 같은 네트워크의 대용량 작업을 일시 중지하세요. 가까이 이동한 뒤 회복되면 신호 감쇠나 무선 간섭에 가깝고, 거리와 관계없이 다른 기기의 전송을 멈춘 뒤 회복되면 로컬 네트워크 대역폭 점유에 가깝습니다. 반대로 Wi-Fi는 정상이고 셀룰러가 느리다면 현재 위치의 신호 품질과 이동통신망 혼잡을 고려해야 합니다.

1. Home에서 같은 노드를 유지하고 구성을 새로 고치거나 전환하지 마세요.
2. Wi-Fi로 3회 테스트를 완료하고 각 회차의 첫 응답과 지속 성능을 기록합니다.
3. Wi-Fi를 끄고 셀룰러 네트워크 상태가 안정될 때까지 기다린 뒤 같은 대상으로 3회 테스트합니다.
4. 차이가 뚜렷하면 원래 네트워크로 돌아가 한 번 더 테스트해 단기 변동을 배제합니다.
5. 두 네트워크 모두 느리다면 노드 계층 또는 경로 계층으로 돌아가 계속 확인합니다.

On Demand로 인해 연결이 전환되는지 확인

Settings → On Demand로 이동해 네트워크 조건에 따라 자동으로 연결하는 규칙이 활성화되어 있는지 확인합니다. On Demand는 주로 연결 시점을 결정하며 대역폭을 직접 늘리지는 않지만, 조건이 반복해서 일치하면 네트워크 전환 시 연결이 다시 설정될 수 있습니다. Wi-Fi를 벗어나 셀룰러로 전환하거나 특정 Wi-Fi에 다시 연결한 뒤에만 느려진다면 On Demand를 잠시 끄고 비교한 다음 원래 설정으로 되돌리세요.

Global Routing도 기록에 포함해야 합니다. Proxy는 현재 프록시 정책을 통해 모든 요청을 보내므로 짧은 비교에 적합하고, Direct는 직접 연결 테스트에 사용합니다. Config는 규칙에 따라 매칭하고, Scene은 구성된 장면에 따라 처리합니다. Proxy와 Config의 결과가 다르면 프로토콜을 계속 바꾸기보다 규칙과 DNS를 확인해야 합니다.

규칙, DNS, 구독 업데이트: 혼동하기 쉬운 현상 구분

4단계 점검을 완료한 뒤 속도 문제가 특정 도메인이나 앱에서만 발생한다면 Config의 규칙 매칭을 확인하세요. Shadowrocket은 구성 순서대로 규칙을 처리하며 앞의 규칙이 먼저 매칭됩니다. DOMAIN-SUFFIX는 도메인 접미사를 매칭하고, GEOIP는 IP 지리 정보를 기준으로 매칭하며, IP-CIDR은 주소 대역을 매칭하고, FINAL은 앞에서 매칭되지 않은 요청을 처리합니다.

DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

위 내용은 매칭 순서를 설명한 것이며 기존 구성을 그대로 교체하라는 뜻이 아닙니다. 특정 도메인이 Config에서는 느리지만 Proxy로 전환하면 회복된다면 먼저 DIRECT, 적합하지 않은 정책, 너무 앞에 있는 포괄 규칙에 매칭되었는지 확인하세요. 두 상태 모두 느리다면 규칙은 주요 변수가 아닙니다.

DNS 문제는 보통 ‘주소를 입력한 뒤 오래 기다리지만 페이지 로딩이 시작되면 빠른’ 형태로 나타납니다. 이는 지속 대역폭 문제와 다릅니다. 구성의 DNS 설정을 확인할 때는 기존 구성 설명을 기준으로 하고 여러 DNS 항목을 동시에 바꾸지 마세요. 도메인 규칙과 IP 규칙의 결과는 해석된 주소의 영향을 받을 수 있으므로 DNS와 규칙을 함께 관찰해야 합니다.

구독 업데이트와 속도 테스트는 분리하기

구독 업데이트는 서비스 제공자가 제공하는 노드 목록과 구성 내용을 가져오는 작업이며 속도 최적화 작업이 아닙니다. 테스트 중 구독을 새로 고치면 노드 항목이나 매개변수가 바뀌어 전후 결과를 직접 비교할 수 없게 됩니다. 먼저 고정된 구성으로 테스트를 완료한 뒤 업데이트 문제를 별도로 처리하세요.

구독 형식을 수동으로 확인해야 한다면 예시 주소는 https://example.com/sub?token=xxxx와 같은 형태입니다. 도메인과 토큰은 모두 예시 값입니다. 실제 링크는 사용자의 서비스 제공자가 제공하며 접근 정보가 포함되는 경우가 많으므로 공개하거나 전달하지 마세요.

결론 도출: 최소한의 변경으로 한 번의 점검 사이클 완성

효율적인 점검의 목표는 순간적으로 가장 빠른 조합을 찾는 것이 아니라 느려지는 계층을 특정하는 것입니다. 노드 계층에서는 단일 항목의 이상 여부를 보고, 경로 계층에서는 시간대와 경로를 확인하며, 프로토콜 계층에서는 전송 특성과 매개변수 일치를 살핍니다. 로컬 네트워크 계층에서는 Wi-Fi, 셀룰러, 시스템 연결 조건을 확인합니다. 네 계층은 서로 연관되어 있지만 변수를 통제하면 범위를 단계적으로 좁힐 수 있습니다.

1. 기준선 고정: 같은 대상, 같은 노드, 같은 프로토콜, 같은 Global Routing으로 3회 연속 테스트합니다.
2. 노드만 변경: 단일 노드 부하인지 판단하고 한 번의 지연 시간으로 지속 테스트를 대신하지 않습니다.
3. 시간대만 변경: 아침, 낮, 저녁에 같은 조건으로 기록해 일정한 시간 패턴이 있는지 확인합니다.
4. 프로토콜만 변경: 이미 보유하고 매개변수가 올바른 항목을 사용해 첫 응답과 지속 처리량을 각각 기록합니다.
5. 접속 방식만 변경: Wi-Fi와 셀룰러 네트워크를 비교해 로컬 네트워크가 주요 변수인지 확인합니다.
6. Config로 돌아가기: Proxy는 정상인데 Config에서만 문제가 발생하면 규칙 순서, DNS, 정책 매칭을 다시 확인합니다.

테스트가 끝나면 현상을 설명할 수 있는 조정만 남기고 비교를 위해 임시로 바꾼 설정은 복원하세요. 구독 내용, 서버 매개변수, 노드 상태에 문제가 집중된다면 테스트 시간, 네트워크 유형, 프로토콜, 반복 결과를 정리해 서비스 제공자에게 문의합니다. 문제가 로컬 Wi-Fi에서만 발생한다면 라우터 환경과 로컬 네트워크 사용량을 계속 확인하세요.

Shadowrocket은 Apple 플랫폼의 유료 상용 클라이언트이며 iPhone과 iPad가 주요 사용 기기입니다. Mac, Apple TV, Apple Vision의 호환성과 시스템 요구 사항은 App Store 페이지 표기를 기준으로 확인하세요. 앱은 일회성 구매 방식이며 개발자는 Shadow Launch Technology Limited, 앱 ID는 932747118입니다. 클라이언트 구매와 사용자가 별도로 이용하는 네트워크 서비스는 서로 독립된 항목입니다.