Shadowrocket 연결 시간 초과 해결: 지연 시간 테스트, 프로토콜 설정 및 시스템 시간 점검

연결 시간 초과나 실패가 발생하면 지연 시간 테스트, 프로토콜 설정, iPhone 시스템 시간 순서로 확인해 흔한 원인을 좁혀 보세요.

이 글의 핵심 내용

서비스 제공업체에서 받은 설정을 가져왔지만 Shadowrocket에서 연결 시간 초과가 발생하는 경우를 위한 안내입니다. 테스트 실패와 실제 요청 실패를 구분한 뒤 네트워크 비교, 프로토콜 설정, 시스템 시간 점검으로 원인을 좁혀 보세요. 한 번에 한 항목만 변경하고 원래 설정을 보관하세요. 점검이 끝나면 기존 라우팅 및 On Demand 설정을 복원하세요.

1. 지연 시간 초과와 요청 실패 구분하기

Shadowrocket의 지연 시간 값은 해당 테스트 방식의 결과일 뿐, 모든 연결이 정상이라는 뜻은 아닙니다. TCP 핸드셰이크에 성공해도 프록시 인증, TLS 핸드셰이크, 대상 사이트 접속까지 성공한다고 볼 수 없습니다. 다른 방식의 테스트가 시간 초과되더라도 실제 요청이 모두 실패한다고 단정할 수 없습니다. 결과값만 적기보다 어떤 방식으로 테스트했는지도 기록하세요.

점검을 시작하기 전에 연결 스위치를 끄고 현재 Wi-Fi 또는 셀룰러 네트워크에서 일반 웹페이지가 열리는지 확인하세요. Wi-Fi에서 로그인 인증 페이지가 필요한 경우 먼저 인증을 완료해야 합니다. 기본 네트워크에 문제가 있다면 서버 설정을 반복해서 수정해도 해결되지 않습니다.

기본 네트워크 지연 시간 테스트 프로토콜 설정 시스템 시간 실제 요청

2. 재현 가능한 연결 테스트 먼저 하기

Home에서 SERVER 목록의 기본 서버 표시를 확인하세요. 그룹을 펼쳤거나 특정 항목을 보았다는 이유만으로 실제 연결에 해당 항목이 사용된다고 판단하면 안 됩니다. 테스트 중에는 서버, 네트워크, 라우팅 모드를 동시에 바꾸지 마세요. 무엇이 결과에 영향을 주었는지 구분하기 어려워집니다.

  1. 현재 상태 기록하기

    Home에서 기본 서버, 현재 Global Routing 값, 연결 스위치 상태를 기록하세요. Settings → On Demand에서 연결 시 자동 연결이 켜져 있는지 확인하세요. 자동 재연결이 발생한다면 기존 값을 기록한 뒤 잠시 꺼 두세요.

  2. 지연 시간 테스트 실행하기

    Home → Connectivity Test에서 테스트 방식과 결과를 기록하세요. 같은 항목을 2~3회 반복해 지속적인 시간 초과인지 일시적인 실패인지 확인하세요. 한 번의 결과만으로 설정을 삭제하지 마세요.

  3. 실제 요청 확인하기

    기본 서버를 선택하고 연결 스위치를 켜세요. 필요하면 Global Routing을 잠시 Proxy로 설정한 다음, 접속이 확인된 HTTPS 페이지를 열어 보세요. Config의 분할 라우팅 규칙이 미치는 영향을 줄일 수 있습니다.

  4. 기본 네트워크 바꿔 보기

    서버와 라우팅 모드는 그대로 두고 Wi-Fi와 셀룰러 네트워크만 전환하세요. 전환할 때마다 네트워크가 안정될 때까지 기다린 후 다시 연결해 같은 페이지에 접속하세요.

  5. 비교 결과 저장하기

    네트워크 유형, 테스트 결과, 실제 접속 결과, 오류 원문을 각각 기록하세요. 테스트가 끝나면 기존 Global Routing 및 On Demand 상태를 복원해 임시 설정이 평소 사용에 영향을 주지 않도록 하세요.

Proxy는 프록시 경로를 확인할 때 사용합니다. Direct는 요청을 직접 보내므로 서버가 정상이라고 판단하는 근거가 될 수 없습니다. Config는 현재 설정에 따라 요청을 처리합니다. Scene을 사용 중이라면 해당 Scene의 적용 조건도 확인하세요. 모드를 잠시 바꾸는 것은 원인을 찾기 위한 방법이지 장기적인 해결책이 아닙니다.

3. 프로토콜 설정 항목별로 확인하기

Home에서 해당 서버의 편집 화면을 열고 서비스 제공업체에서 받은 원본 정보와 항목별로 비교하세요. 먼저 Type, 주소, 포트를 확인한 다음 인증 및 전송 옵션을 살펴보세요. 도메인, SNI, Host는 서로 다른 항목입니다. 흔한 예시에서 443을 사용하더라도 자신의 포트를 443으로 바꾸지 마세요.

1–65535
포트 번호 범위. 실제 값은 서비스 제공업체 설정을 따르세요.
443
HTTPS에서 흔히 사용하는 포트입니다. 프록시 포트가 항상 이 값인 것은 아닙니다.
6개 유형
아래 표에서 확인하는 프로토콜 설정 항목
Type우선 확인할 항목혼동하기 쉬운 조건
Shadowsocks주소, 포트, 암호화 방식, 비밀번호암호화 방식은 서버와 일치해야 합니다. 플러그인 설정은 서버에서 요구하는 경우에만 입력하세요.
VMessUUID, 전송 방식, 서버에서 요구하는 인증 옵션WebSocket을 사용하는 경우 Path와 Host도 확인하세요. TLS 설정은 서버와 일치해야 합니다.
VLESSUUID, 전송 방식, Flow(해당하는 경우)다른 설정의 TLS 또는 전송 옵션을 그대로 적용하지 마세요.
Trojan비밀번호, 포트, TLS, 서버 이름주소에 연결할 수 있어도 비밀번호가 틀리거나 인증서 이름이 일치하지 않으면 실패할 수 있습니다.
Hysteria2인증 정보, TLS, 난독화 설정(해당하는 경우)UDP 경로에 의존합니다. TCP 포트만 테스트해서는 전체 연결 상태를 확인할 수 없습니다.
WireGuard키, Endpoint, 인터페이스 주소, Allowed IPsUDP를 사용합니다. 키가 일치하지 않거나 라우팅 범위가 잘못되면 데이터가 전송되지 않을 수 있습니다.

판단 기준: 다른 네트워크에서도 재현되는지 확인한 뒤 설정 변경

같은 설정이 한 네트워크에서만 실패한다면 먼저 서비스 제공업체에 해당 네트워크에서 포트와 UDP에 접속할 수 있는지 문의하세요. 두 네트워크 모두에서 실패한다면 서비스 상태와 프로토콜 항목을 확인하세요. 포트, 비밀번호, TLS 옵션을 한꺼번에 변경하지 마세요.

구독으로 서버를 관리 중이라면 가져온 항목을 수동으로 수정해도 다음 업데이트 때 서비스 제공업체의 설정으로 덮어써질 수 있습니다. 먼저 민감한 정보를 가린 상태로 기록한 뒤 해당 구독을 업데이트하고, 업데이트가 성공했으며 항목이 의도한 대로 변경되었는지 확인하세요. 구독을 가져오는 데 성공해도 포함된 모든 서버가 정상이라는 뜻은 아닙니다. 구독 업데이트에 실패해도 저장된 서버가 즉시 사용할 수 없게 되는 것은 아닙니다.

4. 오류 원문으로 실패 단계 파악하기

오류 로그는 서로 다른 네트워크 계층에서 발생할 수 있으며, 연결 유형에 따라 표현도 달라집니다. 아래는 자주 볼 수 있는 오류 예시입니다. 실제로 표시된 경우에만 원인 판단에 활용하세요. 오류 전체 내용과 발생 시간을 기록하고 모든 실패를 ‘시간 초과’로 뭉뚱그리지 마세요.

오류: i/o timeout

원인 및 해결: 특정 단계에서 제한 시간 안에 예상한 응답을 받지 못했다는 뜻입니다. 이 문구만으로 인증 문제인지 네트워크 문제인지 단정할 수 없습니다. 앞뒤 로그를 확인해 실패 단계를 파악한 다음, 같은 설정으로 기본 네트워크를 바꿔 재현 여부를 확인하세요.

오류: connection refused

원인 및 해결: 대상 호스트나 중간 장비가 연결을 거부한 상태입니다. 해당 포트에서 서비스가 대기 중이지 않거나 접속이 차단된 경우가 많습니다. 먼저 포트를 확인한 뒤 서비스 제공업체에 대기 중인 서비스와 접속 정책을 점검해 달라고 요청하세요.

오류: no such host

원인 및 해결: 필요한 도메인 이름 확인 결과를 가져오지 못한 상태입니다. 주소를 잘못 입력했거나 이름 확인 경로에 문제가 있을 수 있습니다. 원본 서버 도메인과 대조하고 현재 네트워크의 이름 확인 상태를 점검하세요. 출처를 알 수 없는 IP 주소로 임의 변경하지 마세요.

오류: certificate has expired or is not yet valid

원인 및 해결: 인증서 유효 기간이 현재 확인 시점과 맞지 않을 수 있습니다. 기기 시계나 서버 인증서 문제일 수 있습니다. 먼저 기기 시간을 맞춘 뒤에도 문제가 재현되면 서비스 제공업체에 인증서 유효 기간을 확인해 달라고 요청하세요.

TLS 인증서 이름 오류와 인증서 유효 기간 오류는 서로 다른 문제입니다. 전자는 서버 이름, SNI, 인증서에 포함된 도메인을 확인해야 하고, 후자는 시간 설정과 인증서 갱신을 중점적으로 살펴봐야 합니다. 인증서 검증을 꺼서 오류를 숨기지 마세요. 이렇게 하면 서버의 신원 확인이 사라질 뿐 서버 설정 자체는 해결되지 않습니다.

5. iPhone 시스템 시간 확인하기

TLS는 인증서의 유효 시작 시각과 만료 시각을 확인하며, VMess 인증에도 시간 정보가 사용됩니다. 기기의 날짜와 시간이 실제와 다르면 주소, 포트, 비밀번호가 정확해도 연결에 실패할 수 있습니다. 화면에 표시되는 시간대 차이만으로 시스템 시계 오류를 판단할 수 없으므로 날짜와 실제 시각을 함께 확인하세요.

  1. iPhone의 ‘설정’ → ‘일반’ → ‘날짜 및 시간’을 열어 ‘자동으로 설정’을 확인하세요. 이는 시스템 설정이며 Shadowrocket의 Settings와는 다릅니다.
  2. 네트워크를 사용할 수 있는 상태에서 ‘자동으로 설정’을 켜고 연도, 날짜, 시간이 올바른지 확인하세요. 관리 정책 때문에 스위치를 변경할 수 없다면 기기 관리자에게 문의하세요.
  3. Shadowrocket으로 돌아가 연결 스위치를 끈 다음 같은 서버에 다시 연결하세요. 구독을 업데이트하거나 설정을 변경하지 말고 같은 페이지에 다시 접속해 확인하세요.
  4. 시간이 올바른데도 인증서가 만료되었다는 오류가 계속되면 서비스 제공업체에 서버 인증서를 확인해 달라고 요청하세요. 시간대를 반복해서 바꿔도 인증서 유효 기간은 늘어나지 않습니다.

6. 지연 시간 복구 후 실제 라우팅 확인하기

Proxy에서는 접속되지만 Config로 되돌린 뒤 실패한다면 Config에서 현재 적용 중인 설정과 요청에 매칭된 규칙을 확인하세요. 규칙은 순서대로 적용되며, 각 조건의 위치와 FINAL 정책이 아웃바운드 선택에 영향을 줍니다. 요청이 규칙에 따라 Direct로 전송된 것을 기본 서버 연결 실패로 오해하지 마세요.

Config 규칙을 수정하기 전에 백업하고 기존 정책 이름을 보존하세요. 특정 대상 하나만 실패한다면 해당 요청 기록을 바탕으로 도메인 이름 확인과 실제 아웃바운드를 확인하세요. 한 곳의 문제 때문에 설정 전체를 지우지 마세요. 연결을 끈 뒤 다시 자동으로 켜진다면 Settings → On Demand에서 자동 연결 조건을 확인해 자동 재연결을 스위치 고장으로 오해하지 않도록 하세요.

7. 서비스 제공업체에 전달할 정보 정리하기

위 항목을 모두 확인한 뒤에도 문제가 계속되면 단순히 ‘연결되지 않음’이라고 알리기보다 문제를 재현할 수 있는 기록을 전달하세요. 비밀번호, UUID, 개인 키, 구독 링크 전체를 공개하지 마세요. 이러한 정보로 서비스에 접근할 수 있습니다. 스크린샷이나 로그를 보내기 전에도 민감한 정보가 포함되어 있는지 확인하세요.

Shadowrocket은 Apple 플랫폼에서 App Store를 통해 제공되는 상용 폐쇄형 앱이며, 주로 iPhone 및 iPad에서 사용합니다. 시스템 요구 사항은 App Store 페이지를 기준으로 확인하세요. 앱 구매와 회선 요금제는 별개입니다. 기존 구독은 서비스 제공업체에서 받아야 하며, 회선 상태, 인증 정보 유효성, 서버 인증서 문제는 해당 서비스 제공업체에 확인해야 합니다. 앱을 다시 구매하는 것은 이러한 문제를 해결하는 방법이 아닙니다.

Shadowrocket 정품 다운로드