Shadowrocket 연결 시간 초과 및 연결 실패 해결: 지연 시간 테스트·프로토콜 설정·시스템 시간

핵심 내용

Shadowrocket에 본인이 이용하는 서비스 제공업체의 설정을 가져온 사용자를 위한 안내입니다. 지연 시간 테스트 시간 초과, 프로토콜 핸드셰이크 실패, 웹 요청 실패를 구분한 뒤 서버 설정, 라우팅, 시스템 시간을 차례로 확인하세요. 한 번에 하나의 항목만 변경하고, 같은 요청의 변경 전후 결과를 기록하세요. 테스트 수치만으로 연결 전체가 정상이라고 판단할 수는 없습니다.

1. 먼저 증상을 기록하고 테스트 실패와 요청 실패를 구분하세요

Home에서 현재 선택된 서버를 확인한 뒤 Connectivity Test를 실행하세요. 테스트 방식과 표시된 결과, 사용 중인 네트워크를 기록합니다. 테스트 방식을 선택할 수 있다면 TCP 테스트와 실제 요청 테스트를 구분해 기록하세요. 테스트 결과는 특정 탐지 절차를 반영할 뿐, 모든 웹사이트와 프로토콜, 네트워크 환경에서의 연결 상태를 보여 주지는 않습니다.

TCP 테스트는 지정된 주소와 포트에 TCP 연결을 설정하는 과정을 주로 확인합니다. 결과가 밀리초 단위로 표시되더라도 비밀번호가 올바르거나 TLS 검증이 통과했거나 대상 웹사이트에 접속할 수 있다는 뜻은 아닙니다. Hysteria2는 UDP 기반 QUIC을 사용하고 WireGuard도 UDP를 사용하므로, TCP 탐지만으로 실제 통신 상태를 확인할 수는 없습니다.

확인된 증상	알 수 있는 점	다음 확인 항목
TCP 테스트에는 시간이 표시되지만 웹페이지가 열리지 않음	TCP 연결은 성공했어도 이후 과정에서 실패할 수 있음	인증, TLS, 라우팅, DNS 확인
테스트는 시간 초과되지만 실제 요청은 사용 가능	탐지 방식이나 대상이 실제 요청과 다를 수 있음	테스트 방식을 기록하고 프로토콜 설정은 바로 변경하지 않기
같은 설정이 Wi-Fi에서만 실패	해당 네트워크 경로와 관련된 문제일 수 있음	셀룰러 네트워크로 전환한 뒤 같은 요청 다시 실행
특정 웹사이트 하나만 실패	연결 전체의 문제라고 단정하기 어려움	해당 요청의 DNS, 적용된 규칙, 대상 서비스 상태 확인

결론: 실제 요청으로 테스트 결과를 재확인하세요

같은 서버와 설정을 유지한 채 접속 가능한 HTTPS 페이지를 하나 골라 다시 테스트하세요. 다음에 무엇을 변경할지는 테스트 결과와 실제 요청 상태를 함께 확인한 뒤 판단하는 것이 좋습니다.

2. 정해진 순서대로 다시 테스트하고 여러 설정을 한꺼번에 바꾸지 마세요

먼저 Shadowrocket 연결을 끈 상태에서 iPhone이 현재 네트워크를 사용할 수 있는지 확인하세요. 공용 Wi-Fi에서 웹 인증이 필요하다면 먼저 인증을 완료한 뒤 연결을 켜세요. 그런 다음 아래 순서대로 점검합니다. 이미 사용 중인 구독과 서버 설정은 본인이 이용하는 서비스 제공업체의 안내를 기준으로 확인하세요.

기준 상태 기록

Home에서 선택된 서버, Connectivity Test 결과, Global Routing의 현재 값을 기록하고 Wi-Fi 또는 셀룰러 네트워크 중 무엇을 사용 중인지 적어 두세요. 설정을 한꺼번에 삭제하지 마세요.
주소 확인

Home에서 해당 서버의 편집 화면을 열어 주소와 포트를 확인하세요. 주소 앞뒤에 공백이 들어가지 않았는지 살펴보세요. 일반 서버 주소란에 구독 링크를 넣으면 안 되며, 임의로 https://나 경로를 추가하지 마세요.
설정값 확인

서비스 제공업체의 안내에 따라 Type, 인증 정보, TLS, 전송 설정을 하나씩 확인하세요. 저장한 뒤 연결을 새로 설정하고 웹 요청도 다시 실행하세요. 이전 연결의 결과를 그대로 판단에 사용하지 않도록 합니다.
네트워크 전환

설정값은 그대로 두고 Wi-Fi와 셀룰러 네트워크를 번갈아 사용해 보세요. 한 네트워크에서만 시간 초과가 발생한다면 네트워크별 차이를 기록하세요. 일시적으로 연결된다는 이유만으로 비밀번호가 다시 검증되었다고 판단해서는 안 됩니다.
시간 확인

iPhone에서 설정 → 일반 → 날짜 및 시간으로 이동해 ‘자동으로 설정’과 현재 날짜, 시간, 시간대를 확인하세요. 설정을 바로잡은 뒤 다시 연결하고 같은 HTTPS 요청을 테스트하세요.

3. 주소, 포트, 프로토콜 설정을 하나씩 확인하세요

Home에서 서버 편집 화면을 열고 프로토콜 유형이 서비스 제공업체가 안내한 유형과 정확히 일치하는지 확인한 다음 각 항목을 대조하세요. 포트는 서버가 지정한 수신 대기 지점입니다. 포트가 443이라고 해서 HTTPS나 TLS 서비스를 사용할 수 있다는 뜻은 아닙니다. 흔히 쓰이는 포트라는 이유만으로 원래 포트를 임의로 바꾸지 마세요.

프로토콜	중점 확인 항목	자주 하는 실수
Shadowsocks	서버, 포트, 암호화 방식, 비밀번호, 서버에서 요구하는 플러그인 설정	비밀번호만 복사하고 암호화 방식이나 플러그인 설정을 빠뜨림
VMess	UUID, 암호화 설정, 서버에서 요구하는 전송 방식과 TLS 설정	UUID를 다른 인증 항목에 입력하거나 전송 설정을 빠뜨림
VLESS	UUID, 전송 방식, 서버에서 요구하는 TLS, Reality 또는 flow 설정	같은 UUID라면 어떤 전송 방식과 보안 설정에도 사용할 수 있다고 생각함
Trojan	비밀번호, TLS, 서버 이름, 전송 설정	주소에 연결된다는 이유로 인증서에 해당하는 서버 이름을 확인하지 않음
Hysteria2	인증 정보, TLS 서버 이름, 서버에서 요구하는 난독화 설정	TCP 탐지 결과만으로 UDP 경로도 반드시 사용할 수 있다고 판단함
WireGuard	로컬 개인 키, 피어 공개 키, Endpoint, 인터페이스 주소, 라우팅 범위	개인 키와 피어 공개 키를 혼동하거나 UDP 연결 가능 여부를 확인하지 않음

TLS 서버 이름과 실제 연결 주소는 다를 수 있습니다. 연결 주소는 요청을 보낼 위치를 정하고, 서버 이름은 TLS 협상과 인증서 신원 확인에 사용됩니다. WebSocket을 사용하는 경우 Host와 Path도 애플리케이션 계층 요청에 관여합니다. 값이 같을 수도 있지만, 비슷해 보인다는 이유만으로 서로 바꿔 쓰면 안 됩니다.

비밀번호와 UUID: 복사할 때 줄바꿈, 따옴표, 끝부분 공백이 들어갔는지 확인하세요. 인증 정보를 전체 공개된 곳에 붙여 넣지 마세요.
Path: /connect는 경로 형식의 예시일 뿐입니다. 실제 값은 서버 설정을 따라야 하며 대소문자와 앞의 슬래시도 확인하세요.
주소와 포트: 도메인을 사용한다면 DNS 조회도 필요합니다. IP 주소로 바꾸는 것이 보편적인 해결책은 아니며, 특히 TLS 서버 이름까지 함께 삭제해서는 안 됩니다.
구독 업데이트: 서비스 제공업체가 서버 주소나 설정을 변경할 수 있습니다. 직접 수정한 내용은 따로 기록해 두고, 본인의 구독을 업데이트한 뒤 선택된 항목을 다시 확인하세요. 만료된 설정값을 반복해서 사용하지 마세요.

4. 오류 메시지로 범위를 좁히고 모든 실패를 같은 방법으로 처리하지 마세요

연결 실패 전후에 표시된 로그를 기록하고, 가장 먼저 나타난 오류와 해당 대상을 우선 확인하세요. 다음은 네트워크나 TLS 로그에 나타날 수 있는 오류 문구입니다. 실패할 때마다 같은 문구가 표시되는 것은 아니며, 오류 한 줄만으로 서버 측 문제가 원인이라고 단정할 수도 없습니다.

오류: i/o timeout

원인과 해결 방법: 제한 시간 내에 특정 읽기 또는 쓰기 작업이 끝나지 않았다는 뜻입니다. DNS 조회, 네트워크 경로 또는 원격 응답과 관련되었을 수 있습니다. 먼저 오류가 가리키는 대상을 확인한 다음 설정값을 유지한 채 네트워크를 바꿔 같은 요청을 다시 테스트하세요.

오류: connection refused

원인과 해결 방법: 대상이나 중간 장치가 연결 요청을 명시적으로 거부했습니다. 포트에서 수신 대기 중인 서비스가 없거나 연결을 적극적으로 거부할 때 흔히 나타납니다. 서비스 제공업체가 안내한 주소와 포트를 확인한 뒤 해당 접속 지점의 상태를 문의하세요.

오류: certificate has expired or is not yet valid

원인과 해결 방법: 기기 시간과 인증서 유효 기간이 맞지 않거나 원격 인증서가 실제로 만료되었을 수 있습니다. 먼저 iPhone의 시간을 바로잡으세요. 시간이 정확해도 문제가 계속되면 서비스 제공업체에 인증서 확인을 요청하세요. 검증을 건너뛰는 방식으로 문제를 해결하려고 하지 마세요.

오류: no such host

원인과 해결 방법: 도메인을 사용할 수 있는 주소로 확인하지 못했습니다. 먼저 도메인 철자를 확인하고, 서버 도메인과 대상 웹사이트 도메인 중 어느 쪽의 DNS 조회가 실패했는지 구분하세요. 그런 다음 현재 설정의 DNS와 기본 네트워크를 확인합니다.

같은 오류가 반복되어도 대기 시간만 늘리지 마세요. 먼저 실패 지점을 파악하세요. 서버 도메인을 확인할 수 없다면 주소와 DNS를 점검하고, TLS 협상 단계까지 도달했다면 시간, 서버 이름, 인증서를 확인하세요. 인증 오류라면 프로토콜 설정을 다시 살펴봐야 합니다. 오류가 발생한 단계에 따라 확인 방법도 달라집니다.

도메인 조회네트워크 연결프로토콜 핸드셰이크사용자 인증대상 요청

5. 연결이 설정되었다면 Global Routing과 DNS를 확인하세요

Home → Global Routing으로 돌아가 현재 선택된 항목을 기록하세요. Proxy, Direct, Config, Scene은 요청의 라우팅 방식을 결정하며 서로 다른 연결 프로토콜을 뜻하지 않습니다. 시스템에 VPN 연결됨으로 표시되는 것은 주로 시스템 터널이 설정되었다는 의미입니다. 모든 요청이 선택한 서버를 거쳐 대상에 도달했다고 볼 수는 없습니다.

Proxy: 프록시 경로를 비교 테스트할 때 사용합니다. 잠시 전환한 뒤 요청을 다시 실행하세요. 로컬 네트워크 리소스에 접근하는 방식이 달라질 수 있으므로 테스트 후에는 원래 설정으로 되돌리세요.
Direct: 요청이 직접 연결 경로를 사용합니다. 이 모드에서 웹페이지가 열린다고 해서 서버 인증과 전달이 정상이라고 볼 수는 없습니다.
Config: 현재 선택된 설정에 따라 규칙을 적용합니다. Config에서 실제로 활성화된 파일을 확인한 뒤 Rule 섹션을 살펴보세요. 선택되지 않은 파일만 확인해서는 안 됩니다.
Scene: 설정된 Scene에 따라 라우팅 방식이 결정됩니다. 문제를 확인할 때는 Scene에서 실제로 사용하는 설정도 살펴보세요. 항상 Proxy나 Direct와 동일하다고 간주해서는 안 됩니다.

Config 모드에서는 Rule 섹션의 규칙을 순서대로 적용합니다. 앞부분의 DOMAIN-SUFFIX, IP-CIDR 또는 GEOIP 규칙이 요청 경로를 먼저 결정할 수 있으며, FINAL은 앞선 규칙과 일치하지 않는 요청을 처리하므로 규칙 맨 마지막에 두어야 합니다. 같은 대상이 Proxy에서는 연결되지만 Config에서는 실패한다면 비밀번호부터 바꾸지 말고 적용된 규칙과 해당 정책을 먼저 확인하세요.

6. 마지막으로 시스템 시간을 바로잡고 점검 기록을 보관하세요

iPhone에서 설정 → 일반 → 날짜 및 시간으로 이동해 ‘자동으로 설정’을 확인하세요. 날짜, 시간 또는 시간대가 잘못 표시되면 먼저 올바르게 설정하고 기기의 실제 시간이 맞는지 확인합니다. 인증서 검증은 특정 시각을 기준으로 하므로 시간대 표시만 바꿔서는 기기 시계가 바로잡히지 않습니다. VMess처럼 시간 기반 인증을 사용하는 프로토콜도 시계 오차가 크면 영향을 받을 수 있습니다.

시간이 정상인데도 연결되지 않는다면 최소한의 문제 기록을 정리해 본인이 이용하는 서비스 제공업체에 전달하세요. 발생 시각과 시간대, 네트워크 유형, 프로토콜, 테스트 방식, 민감 정보를 가린 오류 문구, 네트워크 전환 후 결과를 포함합니다. 비밀번호, 개인 키, 전체 UUID 또는 전체 구독 링크는 보내지 마세요.

지연 시간은 표시되는데 웹페이지가 열리지 않는 이유는 무엇인가요?

먼저 해당 수치가 어떤 테스트에서 나온 것인지 확인하세요. Home → Global Routing으로 돌아가 모드를 기록한 뒤 Proxy로 비교 요청을 실행합니다. 그래도 실패한다면 프로토콜 인증과 TLS 설정을 확인하세요. TCP 연결 성공에는 이후 인증과 대상 접근 과정이 포함되지 않습니다.

Wi-Fi에서만 시간 초과가 발생하고 셀룰러 네트워크에서는 정상이라면 비밀번호를 다시 입력해야 하나요?

현재 비밀번호는 그대로 두세요. Wi-Fi 웹 인증을 완료했는지 확인한 다음 같은 서버와 요청으로 다시 테스트합니다. Hysteria2와 WireGuard를 사용한다면 해당 네트워크에서 UDP를 사용할 수 있는지도 확인하세요. 같은 설정을 반복해서 입력하는 것보다 네트워크별 차이를 서비스 제공업체에 전달하는 편이 원인 파악에 도움이 됩니다.

구독 업데이트에 성공하면 모든 서버에 연결할 수 있다는 뜻인가요?

아닙니다. 업데이트 성공은 구독 내용을 가져와 처리했다는 뜻일 뿐입니다. Home으로 돌아가 특정 서버를 선택한 뒤 테스트 결과와 실제 요청을 각각 확인하세요. 구독에 포함된 주소와 인증 설정도 서비스 제공업체의 확인이 필요할 수 있습니다.

먼저 시스템 VPN 설정을 삭제하거나 다시 구매해야 하나요?

시간 초과 문제를 점검할 때 이 두 가지를 첫 단계로 삼지 마세요. 시스템 터널이 설정된다면 먼저 주소, 프로토콜, 라우팅, 시간을 확인하세요. 시스템 권한이나 터널 설정 자체가 실패하는 경우에만 첫 연결 가이드를 참고해 권한 설정 과정을 확인하세요.

결론: 한 번에 하나씩 바꾸고 다시 테스트해 해결 여부를 확인하세요

항목 하나를 수정한 뒤 다시 연결하고 같은 요청을 여러 차례 실행해 기존 오류가 더 이상 나타나지 않는지 확인하세요. 그런 다음 임시로 변경했던 라우팅과 On Demand 조건을 복원합니다. 한 번 성공했다고 해서 원래 문제가 발생했던 환경에서 다시 확인하는 절차를 생략할 수는 없습니다.