Shadowrocket 연결 시간 초과·실패 해결: 지연 테스트, 프로토콜 설정, 시스템 시간 점검 순서

이 글의 핵심

Shadowrocket에서 연결 시간이 초과되더라도 서버가 반드시 오프라인인 것은 아닙니다. 지연 시간이 표시되어도 웹 요청이 성공한다는 뜻은 아닙니다. 이미 이용 중인 서비스와 구독이 있는 사용자를 대상으로 기본 네트워크, 지연 테스트, 프로토콜 설정, 시스템 시간, 실제 요청 순서로 원인을 좁혀 봅니다. 한 번에 한 가지 조건만 바꾸고 오류 원문과 테스트 시간을 기록하면, 무작정 재설치하거나 설정 전체를 한꺼번에 변경하는 대신 재현 가능한 문제 기록을 남길 수 있습니다.

1. 먼저 문제 범위를 확인하고 현재 상태를 기록하세요

먼저 구독 업데이트 실패, 노드 테스트 실패, 연결 후 특정 웹페이지가 열리지 않는 경우를 구분하세요. 각각 다른 단계에서 발생할 수 있습니다. 구독 업데이트는 설정 데이터를 가져오는 과정이고, 노드 테스트는 선택한 방식으로 연결을 시험하는 과정입니다. 웹페이지 접속에는 라우팅, DNS, 프로토콜 핸드셰이크, 대상 사이트가 추가로 관여합니다. 단순히 ‘시간 초과’라는 이유만으로 모두 같은 문제라고 볼 수는 없습니다.

시작하기 전에 Home에서 현재 선택된 노드 이름, Global Routing 옵션, 오류가 발생한 동작을 기록하세요. Config의 기존 설정은 그대로 두고 규칙을 먼저 지우지 마세요. Settings → On Demand가 켜져 있다면 그 상태도 적어 두세요. 수동으로 연결을 끊어 비교해야 할 때는 기존 조건에 따라 연결이 다시 시작되지 않는지 먼저 확인합니다.

기본 네트워크 확인: 연결을 잠시 끊고 현재 Wi-Fi 또는 셀룰러 네트워크에서 평소 직접 접속하는 페이지가 열리는지 확인합니다. Wi-Fi에 웹 로그인 인증이 필요하다면 먼저 인증을 완료하세요.
테스트 대상을 고정하세요: 이미 보유한 노드 하나를 선택하고, 이후 점검과 테스트도 같은 노드로 진행해 서로 다른 설정의 결과가 섞이지 않도록 합니다.
원래 결과를 기록하세요: 테스트 시간 초과인지, 연결 스위치가 켜진 상태를 유지하지 못하는지, 특정 앱의 요청만 실패하는지 구분하고 오류 전문을 보관합니다.
한 번에 하나만 변경하세요: 설정을 바꾼 뒤 같은 동작으로 다시 테스트합니다. 개선되지 않으면 해당 설정을 원래대로 되돌린 다음 다음 항목을 확인하세요.

2. 지연 테스트 이해하기: 숫자가 표시되어도 연결이 가능한 것은 아닙니다

결과를 해석하기 전에 테스트 방식을 확인하세요. TCP 핸드셰이크 테스트는 주소와 포트에 접근할 수 있는지 확인하지만 전체 프록시 프로토콜의 인증 과정은 검증하지 않습니다. 노드를 통해 HTTP 요청을 보내는 테스트는 테스트 대상 자체를 포함해 더 많은 요소의 영향을 받습니다. 두 방식에서 측정한 시간은 의미가 다르므로 직접 비교하기 어렵고, 지연 시간을 다운로드 속도로 볼 수도 없습니다.

Home에서 같은 노드로 현재 테스트를 반복하고 결과가 일정한지 기록하세요. 앱에서 다른 테스트 방식을 선택했다면 그 방식도 함께 적습니다. 아래의 3회 테스트는 문제 해결을 위한 기록 방법이며 앱에서 정한 횟수가 아닙니다. 지속적인 실패와 일시적인 변동을 구분하기 위한 것입니다.

3회

같은 노드와 테스트 방식으로 연속 테스트하고 결과를 각각 기록

2가지

포트 접근 가능 여부와 노드를 통한 요청 결과를 따로 확인

1개

각 테스트에서는 네트워크, 노드 설정, 테스트 대상 중 하나만 변경

결론: 포트에 접근할 수 있다면 다음으로 프로토콜 핸드셰이크를 확인하세요

TCP 테스트에 계속 응답이 오는데 노드를 통한 요청은 계속 실패한다면 인증 정보, TLS, 전송 설정을 먼저 확인하세요. 지연 시간만 보고 노드를 바꾸는 데 집중하지 마세요. TCP 테스트 성공은 해당 테스트에서 TCP 연결이 수립되었다는 뜻일 뿐, 서버가 현재 프로토콜 설정을 받아들였다는 의미는 아닙니다.

같은 설정이 Wi-Fi에서는 실패하고 셀룰러 네트워크에서는 성공한다면 우선 네트워크 경로나 해당 네트워크의 제한을 의심할 수 있지만, 구체적인 원인이 확정된 것은 아닙니다. 두 네트워크에서 모두 실패하더라도 서버가 중지되었다고 단정할 수 없습니다. 주소 오류, 만료된 인증 정보, DNS 조회 문제, 프로토콜 불일치도 하나씩 확인해야 합니다.

3. 주소·포트·프로토콜 설정 확인하기: 추측한 값으로 바꾸지 마세요

Home에서 현재 노드의 편집 화면을 열고 서비스 제공자가 전달한 원본 설정과 항목별로 비교하세요. 먼저 유형이 일치하는지 확인한 다음 주소와 포트를 보고, 마지막으로 인증, TLS, 전송 항목을 점검합니다. 구독을 성공적으로 가져왔다는 것은 클라이언트가 데이터를 받고 해석했다는 뜻이지, 모든 노드에 연결할 수 있다는 뜻은 아닙니다.

점검 항목	확인할 내용	잘못 판단하기 쉬운 점
주소 및 포트	도메인 또는 IP 주소가 원본 설정과 일치하는지, 포트 숫자가 빠지지 않았는지 확인합니다. 원본 설정의 포트가 443이라면 443을 그대로 사용하세요.	443은 흔히 쓰이는 포트의 예일 뿐 모든 노드에 적용되는 해결책은 아닙니다. 연결에 실패했다고 443으로 바꾸지 마세요.
Shadowsocks	암호화 방식과 비밀번호를 확인하세요. 설정에 추가 플러그인 매개변수가 있다면 이 값도 일치해야 합니다.	주소와 포트가 올바르더라도 암호화 방식이나 비밀번호가 일치하지 않으면 사용할 수 없습니다.
VMess / VLESS	UUID, 해당 프로토콜에 적용되는 옵션, 전송 유형, 경로, Host 등 관련 항목을 확인하세요.	한 프로토콜의 설정 항목 조합을 다른 프로토콜에 그대로 적용하지 마세요.
Trojan	비밀번호, TLS 설정, 서버에서 요구하는 SNI를 확인하세요.	연결 주소와 인증서에 연결된 도메인은 다를 수 있습니다. 주소만 보고 SNI를 추측하지 마세요.
Hysteria2	인증 정보, TLS, 해당되는 혼란 방지 설정을 확인하고 네트워크 경로에서 필요한 UDP 통신이 허용되는지도 살펴보세요.	일반 TCP 테스트 결과만으로 QUIC 기반 연결의 사용 가능 여부를 판단할 수 없습니다.
WireGuard	키, 상대방 주소와 포트, 터널 주소, 설정에 지정된 라우팅 범위를 확인하세요.	UDP를 기반으로 동작하므로 TCP 포트 테스트만으로 핸드셰이크와 실제 트래픽을 검증할 수 없습니다.

도메인을 사용한다면 조회 결과로 얻은 주소가 올바른지도 확인해야 합니다. DNS 조회를 우회하려고 도메인을 임의로 IP 주소로 바꾸지 마세요. 서버 진입 지점 선택이 달라지고 TLS 호스트 이름 검증에 영향을 줄 수 있습니다. WebSocket을 사용하는 설정에서는 경로, Host, TLS의 SNI가 각각 다른 역할을 하므로 모두 도메인처럼 보인다는 이유로 서로 바꿔 쓸 수 없습니다.

비밀번호, UUID, 키를 복사할 때 앞뒤 공백, 줄바꿈, 잘림이 없는지 확인하세요. 스크린샷을 보고 문자를 추측하지 마세요.
서비스 제공자가 설정 변경을 확인해 준 경우 기존 설정을 먼저 보관한 다음 해당 구독을 업데이트하세요. 업데이트 후 실제로 선택된 노드도 다시 확인합니다.
구독 업데이트가 실패하면 링크가 유효한지, 현재 네트워크에서 접근할 수 있는지 먼저 확인하세요. 유일하게 사용할 수 있는 설정을 먼저 삭제하지 마세요.
TLS 오류를 가리기 위해 인증서 검증을 끄지 마세요. 먼저 시스템 시간, SNI, 인증서 상태를 확인하세요.

4. iPhone 시스템 시간을 확인한 다음 TLS 오류를 살펴보세요

iPhone의 날짜, 시간 또는 시간대가 크게 잘못되어 있으면 인증서 유효 기간 판단이나 시간 검증이 필요한 인증 과정에 영향을 줄 수 있습니다. 인증서에는 유효 시작 시각과 만료 시각이 포함됩니다. 기기의 시계가 크게 어긋나면 주소와 비밀번호가 올바르더라도 핸드셰이크 단계에서 실패할 수 있습니다. 모든 시간 초과의 원인이 되는 것은 아니지만, 간단히 확인할 수 있으므로 점검할 만한 항목입니다.

iPhone의 시스템 ‘설정’ → ‘일반’ → ‘날짜 및 시간’을 열고 ‘자동으로 설정’이 켜져 있는지 확인하세요.
표시된 날짜, 현지 시간, 시간대가 적절한지 확인하세요. 스위치를 변경할 수 없다면 기기 관리 또는 사용 제한을 살펴보고, 관리 설정을 함부로 제거하지 마세요.
Shadowrocket으로 돌아가 연결을 끊은 뒤 같은 노드에 다시 연결하고 동일한 테스트를 실행하세요.
TLS 관련 오류가 계속되면 오류 원문과 발생 시간을 서비스 제공자에게 전달하고 서버 인증서, 인증서 체인, 도메인 설정을 확인해 달라고 요청하세요.

시스템 시간이 정확한지는 확인해야 할 항목 중 하나일 뿐, 만료된 인증서나 인증서 이름 불일치, 서버 설정 오류를 자동으로 해결하지 않습니다. 아래는 흔히 볼 수 있는 네트워크 오류 문구를 해석하는 방법입니다. 실제 로그에 해당 문구가 있을 때만 참고하세요. 구체적인 문구는 시스템과 실패 단계에 따라 다를 수 있습니다.

오류: Connection refused

원인 및 해결 방법: 대상 또는 중간 장치가 연결을 명시적으로 거부한 상태입니다. 포트에서 수신 대기 중이지 않거나 정책상 거부되었을 수 있습니다. 주소와 포트를 먼저 확인한 뒤 서비스 제공자에게 수신 상태와 접근 정책을 확인해 달라고 요청하세요.

오류: Operation timed out

원인 및 해결 방법: 제한 시간 내에 작업이 완료되지 않았다는 뜻입니다. 이 문구만으로 패킷 손실, 경로 제한, 서버 무응답 중 무엇이 원인인지 알 수 없습니다. 테스트와 실제 요청 중 어느 단계에서 실패했는지 기록하고 다른 네트워크에서도 비교해 보세요.

오류: certificate has expired

원인 및 해결 방법: 인증서 유효 기간 검증에 실패했습니다. 먼저 기기 시간을 바로잡으세요. 시간이 정확하다면 서비스 제공자에게 인증서 갱신 상태와 실제로 전달되는 인증서 체인을 확인해 달라고 요청하세요.

5. 연결 후에도 열리지 않는 경우: Global Routing과 규칙 매칭 확인

연결 스위치가 켜져 있다고 모든 요청이 현재 노드를 거치는 것은 아닙니다. Home → Global Routing에서 전체 라우팅 방식을 선택합니다. Proxy는 프록시 라우팅, Direct는 직접 연결, Config는 현재 설정에 따른 처리, Scene은 설정된 장면에 따른 라우팅 방식을 사용합니다. 문제를 확인할 때는 노드 이름만 보지 말고 현재 선택된 항목을 먼저 기록하세요.

규칙의 영향을 분리해야 한다면 테스트 범위를 확인한 뒤 잠시 Proxy를 사용해 같은 대상으로 요청을 보내고 원래 옵션으로 되돌릴 수 있습니다. 이 동안 다른 요청의 라우팅도 달라지므로 영향을 이해한 뒤 진행하세요. Proxy에서는 성공하고 Config에서는 실패한다면 비밀번호를 계속 바꾸기보다 Config에서 현재 활성화된 설정과 요청에 실제로 적용된 정책을 확인하세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT
FINAL,PROXY

이 내용은 매칭 순서만 설명하며 완전한 설정은 아닙니다. DOMAIN-SUFFIX는 도메인 접미사를 매칭하고, GEOIP는 IP의 지리적 위치를 기준으로 판단하며, IP-CIDR은 주소 범위를 매칭하고, FINAL은 앞서 매칭되지 않은 요청을 처리합니다. 규칙은 순서대로 확인합니다. 예시에 나온 192.0.2.0/24는 문서용 예시 네트워크이므로 실제 서비스 라우팅을 변경할 때 기준으로 삼지 마세요. 사용 전에 정책 이름이 본인의 설정에서 유효한지도 확인해야 합니다.

특정 도메인 하나만 실패: 해당 요청의 도메인, 조회 결과 주소, 적용된 정책을 확인하고 대상 사이트 자체의 문제인지 살펴보세요.
노드를 통한 모든 요청이 실패: 규칙 변경 범위를 넓히지 말고 프로토콜 설정과 핸드셰이크 점검으로 돌아가세요.
웹페이지는 열리지만 특정 서비스만 실패: 해당 서비스가 UDP, 추가 도메인, 다른 포트에 의존하는지 확인하세요. 일반적인 웹페이지 테스트로 모든 전송 조건을 검증할 수는 없습니다.

6. 자주 묻는 질문과 문제 기록 정리

지연 시간이 표시되는데 왜 연결할 수 없나요?

먼저 어떤 테스트에서 나온 값인지 확인하세요. TCP 핸드셰이크만 성공했다면 인증 정보, TLS, 전송 유형, 경로를 계속 점검하세요. 그런 다음 현재 노드로 실제 요청을 보내 확인합니다. 포트에 접근할 수 있다는 사실만으로 프로토콜 인증에 성공한 것은 아닙니다.

모든 노드에서 시간이 초과되면 구독을 먼저 다시 가져와야 하나요?

먼저 연결을 끊고 기본 네트워크를 확인한 다음 같은 노드로 Wi-Fi와 셀룰러 네트워크를 바꿔 비교하세요. 서비스 제공자가 설정을 업데이트했거나 링크 데이터에 오류가 있다고 확인된 경우에만 구독을 업데이트하고, 비교할 수 있도록 기존 설정을 보관하세요.

연결을 끊어도 다시 자동으로 연결되어 점검하기 어렵다면 어떻게 하나요?

Settings → On Demand와 기존 트리거 조건을 확인하세요. 수동으로 비교해야 한다면 On Demand를 잠시 끄고 테스트를 마친 뒤 원래 상태로 복구할 수 있습니다. 이 설정은 연결이 시작되는 시점을 제어할 뿐, 잘못된 주소나 비밀번호를 고쳐 주지는 않습니다.

시스템 시간을 바꿨는데도 인증서 오류가 계속되면 어떻게 하나요?

인증서 검증은 켜 둔 상태에서 노드의 SNI가 서비스 제공자의 요구 사항과 일치하는지 확인하세요. 오류 원문과 정확한 발생 시각을 전달하고 서비스 제공자에게 인증서 유효 기간, 인증서 체인, 진입 도메인을 확인해 달라고 요청하세요. 도메인을 계속 바꿔 입력하지 마세요.

문제를 문의할 때는 단순히 ‘작동하지 않음’이라고 쓰는 것보다 실패 단계를 구분할 수 있는 정보를 제공하는 것이 효과적입니다. 아래 순서대로 기록을 정리하세요. 노드 이름은 가려도 되지만 인증 정보는 공개적인 문제 해결 자료에 포함하면 안 됩니다.

환경: 기기 유형, 시스템 정보, Wi-Fi 또는 셀룰러 네트워크, 문제가 시작된 현지 시각과 시간대.
테스트: 테스트 방식, 같은 노드에서 실행한 세 번의 결과, 네트워크를 바꾼 뒤 달라졌는지 여부.
설정: 프로토콜 유형, 포트, 현재 Global Routing 옵션, On Demand 활성화 여부.
증상: 오류 원문 전체, 실패한 단계, 모든 요청이 실패하는지 특정 대상만 실패하는지 여부.
개인 정보: 구독 링크의 token, 비밀번호, UUID, 개인 키 및 기타 인증 정보를 가리고 설정 전체를 공개하지 마세요.

이 순서대로 점검하면 문제를 기본 네트워크, 서버 접근 가능 여부, 프로토콜 핸드셰이크, 기기 시간, 요청 라우팅 중 한 단계로 좁힐 수 있습니다. 문제가 발생한 단계가 확인된 뒤 관련 설정만 변경하세요. 테스트가 성공하면 임시 변경 사항을 원래대로 복구해 진단 중 설정한 라우팅 상태가 일상적인 설정으로 남지 않도록 합니다.

App Store 정식 앱 확인

Shadowrocket은 Apple 플랫폼용 유료 클라이언트이며 App Store에서만 받을 수 있습니다. 구매 전에 개발자 Shadow Launch Technology Limited와 앱 ID 932747118을 확인하세요. 앱은 일회성 구매 방식이며, 클라이언트 구매와 네트워크 회선 요금제는 별개입니다. 시스템 요구 사항은 App Store 페이지에 표시된 내용을 확인하세요. 처음 설정하는 방법은 시작하기 가이드에서 확인할 수 있습니다.

정식 앱 확인 페이지로 이동 사용법 보기