Shadowrocket 속도 저하 해결 방법: 서버·회선·프로토콜·로컬 네트워크 점검

1. 먼저 어느 단계에서 느려지는지 확인

Shadowrocket(Shadowrocket)에서 연결이 켜져 있다는 표시는 연결 상태만 알려 줄 뿐, 대상 웹사이트까지의 전체 경로가 원활하다는 뜻은 아닙니다. 웹페이지를 열 때는 보통 DNS 조회, 연결 설정, TLS 핸드셰이크, 콘텐츠 전송이 이어집니다. 어느 한 단계만 지연되어도 페이지가 한참 동안 표시되지 않을 수 있습니다. 먼저 증상을 기록한 뒤 설정을 바꾸세요. 그래야 DNS 조회 대기를 대역폭 부족으로 오해하지 않습니다.

지연 시간은 다운로드 속도가 아닙니다. 지연 시간 테스트 한 번은 특정 탐색 과정에 걸린 시간일 뿐, 실제 서비스의 지속적인 처리량을 의미하지 않습니다. 한 번의 테스트 실패만으로 서버를 사용할 수 없다고 단정할 수도 없습니다. 동영상 재생 시작, 웹페이지 첫 화면, 파일 전송은 각각 따로 살펴보고 하나의 수치로 전체 사용 경험을 판단하지 마세요.

2. 기준 조건 설정: 먼저 Global Routing 확인

Home에서 현재 서버와 Global Routing을 확인합니다. Proxy, Direct, Config, Scene은 서로 다른 라우팅 방식이지 속도 설정이 아닙니다. 규칙의 영향을 확인하려면 Proxy와 Config를 잠시 비교해 보세요. Proxy에서는 대상 접속이 정상으로 돌아오지만 Config에서는 여전히 느리다면 규칙과 정책이 어디로 연결되는지 먼저 확인해야 합니다. 그렇다고 Proxy를 계속 사용해야 한다는 뜻은 아닙니다.

1. 현재 설정 기록

   Home에서 선택된 서버와 Global Routing을 기록하고, Config에서 선택된 구성을 확인합니다. 기존 값을 기록해 두고 테스트가 끝나면 복원하세요.

2. 테스트 대상 고정

   Safari에서 반복 접속할 수 있는 웹페이지 하나와 테스트가 허용된 파일 리소스 하나를 선택합니다. 매 테스트에서 대상을 동일하게 유지하고 다른 대용량 작업은 일시 중지하세요.

3. 라우팅 비교

   Home → Global Routing에서 서버를 그대로 둔 채 Proxy를 잠시 선택한 다음, Config로 되돌려 다시 테스트합니다. 대상에 예상한 정책이 적용됐는지 기록하세요.

4. On Demand 연결 확인

   Settings → On Demand에서 자동 연결 조건을 확인합니다. 연결을 끊은 상태로 기준 테스트를 해야 한다면 테스트 중 자동으로 다시 연결되지 않도록 관련 조건을 잠시 비활성화하세요.

5. 설정 복원 및 재확인

   비교 테스트가 끝나면 기존 Global Routing과 On Demand 설정을 복원합니다. 같은 대상을 다시 방문해 동일한 문제가 재현되는지, 다른 연결 상태로 바뀐 것은 아닌지 확인하세요.

Direct는 현재 네트워크에서 직접 접속할 수 있는 대상을 확인할 때 유용합니다. 원래 직접 접속할 수 없는 대상을 로컬 네트워크 장애의 근거로 삼아서는 안 됩니다. Scene의 결과는 해당 장면의 설정에도 좌우되므로 방식 이름만 보고 실제 라우팅을 판단할 수 없습니다. 규칙이 관련된 경우 Config에서 규칙 순서와 실제 요청에 적용된 결과를 확인하세요. DOMAIN-SUFFIX, IP-CIDR, GEOIP, FINAL은 각각 용도가 다르며 DNS를 변경한다고 잘못된 정책 선택이 자동으로 수정되지는 않습니다.

3. 서버 단계: 같은 네트워크에서 서버만 바꿔 보기

여기서 서버는 서비스 제공업체가 제공한 개별 서버 항목을 뜻합니다. Wi-Fi, 테스트 대상, 라우팅 모드는 그대로 두고 기존 서버 항목 두 개를 바꿔 가며 비교하세요. 프로토콜과 관련 매개변수가 동일한 항목을 선택하는 것이 좋습니다. 그렇지 않으면 서버 부하뿐 아니라 프로토콜 차이까지 결과에 반영되어 서버 부하만의 영향이라고 볼 수 없습니다.

• 특정 항목 하나만 계속 느린 경우: 해당 항목의 주소, 포트, 발생 시간을 기록한 뒤 서비스 제공업체에 서버 부하, 유지보수, 속도 제한 여부를 확인하세요.
• 모든 항목이 동시에 느린 경우: 공통 회선, 로컬 네트워크, 대상 서비스를 추가로 점검하세요. 모든 매개변수를 한꺼번에 바꾸지는 마세요.
• 같은 항목의 속도가 오락가락하는 경우: 비슷한 조건에서 시간을 달리해 다시 테스트하세요. 저녁 시간대의 속도 저하는 혼잡 가능성을 보여 줄 뿐, 어느 구간에서 혼잡이 발생했는지 확정할 수는 없습니다.
• 항목을 바꾼 뒤 정상으로 돌아온 경우: 원래 항목으로 한 번 더 전환해 테스트하세요. 대상 캐시, 일시적인 회복, 백그라운드 작업 종료가 결과에 영향을 줬을 가능성을 확인할 수 있습니다.

구독에 포함된 항목은 서비스 제공업체가 변경할 수 있습니다. 주소나 포트가 바뀌었다고 의심되면 Home에서 기존 구독을 업데이트하고 서버 정보가 동기화됐는지 확인하세요. 구독 링크는 이용 중인 서비스 제공업체에서 받습니다. 구독 업데이트는 구성 동기화 문제를 해결할 뿐 서버 대역폭을 늘리지는 않으며, 업데이트 성공이 회선 정상의 증거도 아닙니다.

4. 회선 단계: Wi-Fi와 셀룰러 네트워크 교차 확인

회선에는 기기에서 서버까지, 서버에서 대상 서비스까지의 전송 경로가 포함됩니다. 로컬 접속 네트워크를 바꾸면 그중 일부만 달라집니다. 따라서 셀룰러 네트워크에서 정상으로 돌아왔다면 접속 네트워크나 해당 경로와 관련된 문제일 수 있지만, 이것만으로 라우터 고장을 단정할 수는 없습니다. 셀룰러 네트워크를 사용할 수 없는 iPad는 직접 제어할 수 있는 다른 Wi-Fi 네트워크나 개인용 핫스팟과 비교해 보세요.

위 내용은 테스트 방법이며 실제 측정 결과가 아닙니다. 각 조합은 세 차례 반복하고 시간과 실패 횟수를 기록하는 것이 좋습니다. 대용량 파일 테스트는 데이터를 많이 사용할 수 있으므로 셀룰러 네트워크에서는 먼저 요금제 한도를 확인하세요. 두 서버 모두 기존 Wi-Fi에서만 느리다면 무선 환경, 라우터, 해당 접속 회선을 중점적으로 살펴보세요. 특정 서버가 두 네트워크에서 모두 느리다면 그 서버와 대상까지의 경로를 계속 확인해야 합니다.

특정 웹사이트만 느리고 다른 대상은 정상이라면 대상의 CDN 연결, 출구 IP 제한, 앱 자체의 속도 제한도 고려해야 합니다. ‘지리적으로 더 가깝다’는 이유만으로 판단하지 마세요. 실제 라우팅, 네트워크 간 연결 품질, 부하가 모두 결과에 영향을 줍니다.

5. 프로토콜 단계: 매개변수를 확인한 뒤 전송 조건 점검

프로토콜 이름이 속도를 보장하지는 않습니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 연결 방식이 서로 다릅니다. 실제 성능은 서버 구성과 네트워크 조건에 따라 달라집니다. 서비스 제공업체가 이미 제공하고 매개변수가 완전한 구성끼리만 비교하세요. 테스트를 위해 항목의 Type을 다른 프로토콜로 바꿔도 서버가 해당 프로토콜을 자동으로 지원하지는 않습니다.

• 주소와 포트: 서비스 제공업체가 안내한 값을 사용하세요. HTTPS에서 흔히 사용하는 443 포트가 모든 프록시 서비스에 공통으로 적용되는 것은 아닙니다. 연결이 느리다고 해서 무조건 443으로 바꾸지 마세요.
• TLS와 SNI: Trojan 등의 구성에서는 인증서에 설정된 이름과 SNI를 확인해야 합니다. 인증서 검증 실패는 연결 문제입니다. 속도를 높이기 위한 방법으로 Allow Insecure를 켜서는 안 됩니다.
• 전송 매개변수: 서비스 제공업체가 WebSocket 등의 전송 방식을 사용하는 경우 경로, Host 등의 매개변수가 서버 설정과 일치해야 합니다. 서버 주소가 DNS로 조회된다고 해서 해당 매개변수까지 올바른 것은 아닙니다.
• UDP 조건: Hysteria2는 QUIC 기반이고 WireGuard는 UDP를 사용합니다. 일부 접속 네트워크에서 UDP를 제한하면 연결에 실패하거나 불안정해질 수 있으므로 서비스 제공업체가 제공한 다른 사용 가능한 구성과 비교하세요.

로그에 오류가 표시되면 처리량을 테스트하기 전에 먼저 오류를 해결하세요. 아래는 네트워크 진단에서 흔히 볼 수 있는 오류 일부입니다. 구체적인 접두어나 전체 문구는 실제 로그를 기준으로 확인하세요. 모든 속도 저하 상황에서 반드시 표시되는 고정 메시지는 아닙니다.

6. 로컬 네트워크 단계: Wi-Fi, DNS, 백그라운드 트래픽 확인

교차 테스트 결과 문제가 로컬 네트워크에 있는 것으로 보이면 먼저 되돌릴 수 있는 조치를 해 보세요. 라우터 가까이에서 다시 테스트하거나 다른 기기의 대용량 전송을 잠시 중지하는 편이 모든 네트워크 설정을 초기화하는 것보다 원인을 파악하기 쉽습니다. 무선 신호가 강해도 간섭이 적다는 뜻은 아니며, 인터넷 회선의 출구에서 대기열이 없다는 뜻도 아닙니다. 같은 Wi-Fi를 사용하는 다른 기기의 대량 업로드도 웹페이지 로딩을 지연시킬 수 있습니다.

1. 접속 품질 확인: 서버를 그대로 둔 채 라우터 가까이에서 다시 테스트하세요. 라우터가 여러 주파수 대역을 제공한다면 직접 제어할 수 있는 조건에서 각각 테스트하고 연결한 네트워크를 기록하세요.
2. 다른 트래픽 일시 중지: 사진 동기화, 시스템 업데이트, 다른 기기의 대용량 파일 전송을 잠시 중지한 뒤 같은 대상에 접속하세요. 테스트가 끝나면 원래 작업을 다시 시작합니다.
3. 직접 연결 기준 확인: On Demand가 자동으로 다시 연결하지 않는지 확인한 뒤 연결을 끊고 현재 네트워크에서 정상적으로 접속할 수 있는 웹페이지를 엽니다. 이 상태에서도 느리다면 먼저 로컬 접속 문제를 해결하세요.
4. DNS 조회와 처리량 구분: 첫 연결에서만 대기 시간이 눈에 띄게 긴 경우에 DNS 설정을 중점적으로 확인하세요. HTTPS 테스트에서 도메인 대신 웹사이트 IP 주소를 바로 사용하지 마세요. 인증서, SNI, 가상 호스트가 도메인 이름에 의존할 수 있습니다.
5. 재연결 확인: Wi-Fi와 셀룰러 네트워크를 전환한 뒤 현재 연결이 안정될 때까지 기다렸다가 테스트를 새로 시작하세요. 기존 연결이 끊겼다고 해서 새 네트워크에서 서버를 사용할 수 없다는 뜻은 아닙니다.

MTU는 가장 먼저 조정할 항목이 아닙니다. 작은 요청은 정상인데 큰 데이터 전송이 반복해서 중단된다면 후속 점검 항목으로 고려할 수 있습니다. 다만 패킷 손실이나 대상 측 속도 제한도 같은 증상을 일으킬 수 있습니다. 해당 설정을 실제로 제공하고 서비스 제공업체가 명확한 매개변수 근거를 제시한 경우에만 변경하세요. 매번 기존 값을 기록하고 인터넷에서 찾은 ‘일반적인 값’을 일괄 적용하지 마세요.

7. 결과 정리 및 정상 복구 확인

점검의 목표는 한 번의 속도 테스트에서 수치가 나아지는 것이 아니라, 원래 사용하던 환경에서 같은 작업을 안정적으로 완료하는 것입니다. 기존 Config와 On Demand를 복원한 뒤 자주 사용하는 웹페이지와 실제 앱을 확인하세요. Config로 되돌렸을 때 다시 느려진다면 서버를 계속 바꾸기보다 규칙 적용 결과와 정책 선택을 다시 살펴보세요.

• 환경: iPhone 또는 iPad, 접속 네트워크 유형, 발생 시간대, 특정 대상에서만 문제가 발생하는지 기록하세요.
• 구성: Global Routing, 사용 중인 프로토콜, 서버 포트, 선택된 구성을 기록하세요. 비밀번호, 키, 구독 인증 정보는 공개하지 마세요.
• 비교 결과: ‘기존 서버가 두 네트워크에서 모두 느림’ 또는 ‘같은 서버가 기존 Wi-Fi에서만 느림’처럼 적으면 ‘속도가 안 나옴’이라고만 쓰는 것보다 원인 파악에 도움이 됩니다.
• 증거: 실제 오류 문구와 테스트 횟수를 보관하세요. 로그를 공유하기 전에 인증 매개변수, 전체 구독 링크, 개인 접속 기록을 확인하고 가리세요.
• 복원: 임시 변경 사항을 되돌리고 원래 대상을 다시 테스트하세요. 반복해서 재현되는 문제가 남아 있다면 검증되지 않은 설정을 계속 추가하는 대신 이용 중인 서비스 제공업체에 문의하세요.

규칙과 DNS를 더 확인하려면 Global Routing 및 규칙 라우팅 안내와 DNS 문제 해결 안내를 참고하세요. 각 항목은 서로 다른 단계에 해당하므로 확인된 근거에 따라 하나씩 점검하고, 한 번의 테스트에서 모든 설정을 바꿀 필요는 없습니다.