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

이 글 미리보기

이 글은 Shadowrocket에 이미 등록된 서버의 시간 초과와 연결 실패를 점검합니다. 사용자가 직접 이용 중인 서비스 제공업체와 구독이 있다는 전제에서, 기본 네트워크, 테스트 의미, 프로토콜 설정, TLS와 기기 시간, DNS, 라우팅과 로그 순으로 확인하세요. 한 번에 설정 하나만 바꾸면 문제 원인이 기기 네트워크인지, 구성인지, 서버인지 구분하기 쉽습니다. 테스트 결과가 연결 품질을 보장하지 않으며, 연결을 켰다고 요청이 성공한 것도 아닙니다.

1. 테스트 조건과 기본 네트워크 확인

연결 실패는 요청이 완료되지 않았다는 결과이지, 특정한 한 가지 오류를 가리키는 이름은 아닙니다. 기본 구성, 테스트 방식, 연결 시간 제한은 현재 앱에 표시된 값을 기준으로 확인하세요. 점검을 시작하기 전에 기존 값을 기록하고, 서버와 DNS, Global Routing을 동시에 변경하지 않는 것이 좋습니다. 그래야 접속이 복구되어도 어떤 변경이 영향을 줬는지 알 수 있습니다.

기본 네트워크 점검은 기기 자체가 인터넷에 연결되는지 확인하는 과정입니다. 먼저 Home에서 연결을 끄고 평소 접속할 수 있는 페이지를 열어 보세요. 여전히 접속되지 않으면 Wi-Fi 로그인을 완료하거나 셀룰러 데이터 권한을 확인한 뒤 Shadowrocket을 점검합니다. VPN 상태 아이콘은 시스템 터널이 연결되었음을 나타낼 뿐, 원격 서버가 연결을 수락했다는 뜻은 아닙니다.

기존 값 기록

Home에서 선택된 서버와 Global Routing의 현재 값을 기록하고 Config에서 사용 중인 구성 파일을 확인하세요. 문제가 발생한 시간과 네트워크 유형도 적어 두되, 비밀번호나 구독 인증 정보는 평문으로 기록하지 마세요.
직접 연결 확인

Home에서 연결을 끄고 브라우저로 기본 네트워크를 확인하세요. 공용 Wi-Fi에 로그인 페이지가 표시되면 먼저 인증을 완료하세요. 인증이 안 된 상태를 서버 시간 초과로 오해하지 않도록 주의합니다.
자동 연결 일시 중지

Settings → On Demand에서 현재 설정을 기록한 다음, 점검하는 동안 자동 연결을 일시적으로 꺼 두세요. 연결을 수동으로 끈 뒤 시스템이 다시 연결하는 상황을 방지할 수 있습니다. 점검이 끝나면 원래 설정으로 복원하세요.
한 항목씩 재테스트

Home으로 돌아가 이미 등록된 서버 하나만 선택해 연결한 뒤 같은 대상에 접속해 보세요. 다음으로 서버와 구성은 그대로 두고 Wi-Fi와 셀룰러 네트워크만 바꿔 재테스트합니다.

2. 지연 테스트와 실제 요청의 차이

지연 테스트는 특정 방식으로 탐지하는 데 걸린 시간이며, 앱에서 실제로 접속한 결과와는 다릅니다. Home → Connectivity Test의 테스트 방식과 옵션은 현재 앱에 표시된 내용을 기준으로 확인하세요. 먼저 사용 중인 탐지 유형을 파악한 뒤 수치를 해석해야 합니다. TCP 연결만 테스트하면 프록시 인증, TLS 핸드셰이크, 대상 웹사이트의 응답, UDP 데이터 전송까지 확인할 수 없습니다.

테스트 시간 초과는 탐지 대상도 함께 살펴봐야 합니다. 테스트가 특정 주소에 의존한다면 그 주소에 일시적으로 접속할 수 없어 여러 서버가 동시에 실패로 표시될 수 있습니다. 실제 접속은 되는데 탐지만 실패한다면 테스트 주소와 방식을 먼저 확인하고, 기존 구성을 바로 삭제하지 마세요.

443

HTTPS에서 흔히 사용하는 포트이며 모든 프록시 서버의 기본 포트는 아닙니다

일반 DNS에서 흔히 사용하는 포트이며, 이름 확인이 된다고 프록시 인증까지 성공한 것은 아닙니다

항목 1개

한 번에 변수 하나만 바꾸고 같은 대상으로 재테스트하세요

TCP 탐지는 성공했지만 웹페이지가 열리지 않는 경우: 지연 수치만 보지 말고 인증, TLS, 전송 설정과 실제로 적용된 정책을 먼저 확인하세요.
서버 하나만 실패하고 나머지는 정상인 경우: 해당 서버의 주소와 포트, 서버 상태부터 확인하세요. 모든 설정을 먼저 초기화하지 마세요.
같은 구성에서 특정 네트워크만 실패하는 경우: 해당 네트워크의 DNS, 포트, UDP 연결 가능성을 확인하고 네트워크를 바꿨을 때의 차이를 기록하세요.
여러 서버와 직접 연결이 모두 실패하는 경우: 기기의 기본 네트워크부터 해결하세요. 구독을 반복해서 업데이트해도 이 단계의 문제는 해결되지 않는 경우가 많습니다.

3. 주소, 포트, 프로토콜 설정 확인

서버 설정은 클라이언트와 서버 간의 약속이므로 프로토콜마다 공통으로 적용되는 정답은 없습니다. Home에서 해당 서버의 편집 화면을 열고 서비스 제공업체가 준 원래 설정과 항목별로 대조하세요. 주소, 포트, 인증 정보를 원래 값 그대로 유지하고, 경험에 따라 포트를 모두 443으로 바꾸지 마세요. 주소 입력란에 URL 경로나 불필요한 공백이 섞여 있지 않은지도 확인합니다.

프로토콜	우선 확인할 항목	자주 혼동하는 상황
Shadowsocks	주소, 포트, 비밀번호, 암호화 방식과 원래 구성에서 요구하는 추가 설정	포트에 연결할 수 있어도 비밀번호나 암호화 방식이 다르면 실제 프록시 요청은 실패할 수 있습니다.
VMess	UUID, 암호화 설정, 전송 방식, 해당 TLS 및 전송 설정	UUID가 맞더라도 WebSocket 경로나 Host가 틀릴 수 있습니다. 기기 시간도 확인하세요.
VLESS	UUID, 전송 방식, 원래 구성에서 사용하는 TLS, REALITY 또는 Flow 설정	다른 서버의 보안 설정을 현재 구성에 그대로 적용하지 마세요.
Trojan	비밀번호, TLS, Server Name, 인증서 검증	주소에 연결되더라도 인증서 이름이나 인증 정보가 일치하지 않으면 요청을 완료할 수 없습니다.
Hysteria2	인증, TLS, 포트, UDP 연결 가능성	QUIC 기반이므로 TCP 포트 탐지에 성공해도 해당 연결이 작동한다는 뜻은 아닙니다.
WireGuard	키, Peer, Endpoint, Allowed IPs, 터널 주소	UDP 통신과 핸드셰이크를 확인해야 합니다. TCP 탐지만으로는 판단할 수 없습니다.

구독 업데이트는 서비스 제공업체가 배포한 구성을 동기화하는 기능이지, 모든 연결 오류를 해결하는 방법은 아닙니다. 구독이 유효한지 확인한 뒤 Home에서 해당 구독을 업데이트하고, 업데이트 후에도 이전에 실패한 항목이 선택되어 있는지 확인하세요. 구독으로 생성된 항목을 직접 수정했다면 변경 사항을 기록해 두세요. 다음 업데이트에서 수정 내용이 덮어써질 수 있습니다. 문제 해결을 위해 같은 구독을 여러 번 추가하지 마세요.

4. TLS, Server Name, 기기 시간 확인

TLS 검증은 서버 인증서와 연결 신원을 확인하며, 인증서 이름과 유효기간, 신뢰 체인을 점검합니다. Server Name은 일반적으로 TLS의 서버 이름 표시와 이름 검증에 사용됩니다. 구체적인 값은 기존 구성에 따르세요. WebSocket의 Host와 서로 바꿔 쓸 수 있는 항목이 아닙니다. 인증서 검증은 유지하고, 검증 건너뛰기를 일반적인 해결책으로 사용하지 마세요.

기기 시간은 인증서 유효기간 판단에 영향을 주며 일부 프로토콜의 인증에도 영향을 줄 수 있습니다. iPhone 또는 iPad에서 시스템의 ‘설정 → 일반 → 날짜 및 시간’을 열어 자동 설정과 실제 시간을 확인하세요. 기기가 관리 정책의 적용을 받는다면 먼저 관련 요구 사항을 확인합니다. 시간을 맞춘 뒤 연결을 다시 설정하면 되며, 프로토콜이나 DNS까지 동시에 바꿀 필요는 없습니다.

인증서 오류를 처리할 때 확인할 점

기기 시간이 올바른데도 인증서가 만료되었거나 이름이 일치하지 않는다면, 서비스 제공업체에 인증서와 Server Name을 확인하세요. 도메인 주소를 IP 주소로 바꿔도 인증서 문제가 자동으로 해결되지는 않습니다. IP에 연결할 때도 기존 구성에서 요구하는 Server Name을 유지해야 할 수 있습니다.

시스템 날짜, 시간, 시간대를 확인하고 수동 설정으로 큰 오차가 생기지 않았는지 살펴보세요.
서버 편집 화면의 TLS와 Server Name이 원래 구성과 일치하는지 확인하세요. 다른 항목의 값을 가져다 쓰지 마세요.
WebSocket을 사용하는 경우 Host와 경로를 각각 확인하세요. 경로의 대소문자와 앞쪽 슬래시가 서버 설정과 일치해야 합니다.
다시 연결한 뒤 이번 오류를 확인해 TLS 오류가 인증 오류나 대상 요청 오류로 바뀌었는지 살펴보세요.

5. DNS와 Global Routing 단계별 확인

DNS는 도메인을 주소로 변환하며, 프록시 서버 주소나 대상 웹사이트를 확인하는 과정에 영향을 줄 수 있습니다. 기본 DNS 동작은 현재 Config와 앱 설정을 기준으로 확인하세요. 원래 구성은 그대로 두고 로그에 이름 확인 오류가 표시될 때 DNS를 점검하는 것이 좋습니다. 확인 없이 여러 DNS 주소를 추가하면 변수가 늘어나며 시간 초과의 원인이 해결됐다는 근거가 되지 않습니다.

기본 네트워크 서버 이름 확인 연결 및 인증 라우팅 정책 대상 응답

Global Routing은 요청에 적용할 라우팅 방식을 결정합니다. Proxy는 현재 선택된 프록시 경로를 임시로 확인할 때, Direct는 직접 연결할 때 사용합니다. Config는 현재 구성의 규칙을 적용하고, Scene은 설정된 시나리오에 따라 처리합니다. 현재 값은 Home에 표시된 내용을 기준으로 확인하세요. Proxy로 잠시 전환한 뒤 접속이 되었다면 Config의 정책이나 규칙을 점검할 필요가 있을 수 있습니다. 그렇다고 모든 DNS와 프로토콜 설정이 올바르다는 뜻은 아닙니다.

서버 도메인 이름 확인에 실패한 경우: 먼저 직접 연결 상태에서 기본 네트워크를 확인하세요. 현재 DNS 설정과 로그에 표시된 조회 오류를 살펴본 다음, 서비스 제공업체에 주소가 여전히 유효한지 확인합니다.
일부 웹사이트만 실패하는 경우: Home → Global Routing의 현재 값을 확인한 뒤 Config에서 사용 중인 파일의 규칙과 정책이 어디로 연결되는지 살펴보세요.
Config는 실패하지만 Proxy는 정상인 경우: 규칙 순서를 먼저 확인하세요. DOMAIN-SUFFIX, IP-CIDR, GEOIP는 서로 다른 결과에 매칭됩니다. FINAL은 최종 정책으로 규칙 맨 아래에 두어야 합니다.
Scene을 바꾼 뒤에만 실패하는 경우: 해당 Scene의 조건과 실제 적용되는 정책을 확인하세요. Home에 표시된 서버 이름만 확인해서는 충분하지 않습니다.

문제 해결 후에는 Global Routing을 원래 값으로 복원하고 실제 대상으로 다시 테스트하세요. 임시 Proxy 전환은 비교를 위한 조건일 뿐, Config에 지정된 DIRECT, PROXY, REJECT 정책을 확인하는 일을 대신할 수 없습니다. 규칙에서 요청을 명시적으로 거부하면 서버를 바꿔도 거부 결과는 달라지지 않습니다.

6. 로그 오류로 문제 범위 좁히기

로그는 연결 실패가 어느 단계에서 발생했는지 파악하는 데 도움이 됩니다. Settings → Log에서 관련 기록을 확인하세요. 기록 기능과 상세 수준은 현재 앱에 표시된 내용을 기준으로 설정하고, 문제가 재현되는 동안 필요한 기록만 켜는 것이 좋습니다. 먼저 시간을 기록한 다음 요청을 한 번 보내 오래된 로그를 현재 결과로 착각하지 않도록 하세요. 다음은 네트워크 하위 계층에서 반환될 수 있는 오류 원문이며, 고정된 팝업 문구가 아닙니다. 실제 로그의 앞뒤 문구는 다를 수 있습니다.

오류: i/o timeout

원인과 해결: 연결이나 읽기·쓰기가 제한 시간 안에 완료되지 않았다는 뜻입니다. 이 문구만으로는 패킷 손실, 차단, 서버 무응답을 구분할 수 없습니다. 로그에서 실패 단계를 확인해 주소와 포트를 점검한 뒤 같은 구성으로 네트워크를 바꿔 재테스트하세요.

오류: connection refused

원인과 해결: 대상 또는 중간 장치가 연결을 명시적으로 거부했습니다. 포트에서 서비스가 대기 중이지 않거나 거부 정책이 적용된 경우일 수 있습니다. 포트와 프로토콜을 확인하고 서비스 제공업체에 해당 서비스가 실행 중인지 문의하세요.

오류: no such host

원인과 해결: 도메인 이름을 확인할 수 있는 결과를 얻지 못했습니다. 주소 입력 오류나 이름 확인 경로 문제가 원인일 수 있습니다. 먼저 서버 주소를 확인한 뒤 현재 DNS 설정과 사용 중인 네트워크에서의 이름 확인 상태를 살펴보세요.

오류: certificate has expired or is not yet valid

원인과 해결: 인증서 유효기간이 현재 시간과 맞지 않습니다. 먼저 시스템의 자동 시간 설정을 확인하세요. 시간이 맞는데도 문제가 계속되면 서비스 제공업체에 인증서를 확인해 달라고 요청하세요. 인증서 검증을 꺼서 우회하지 마세요.

오류가 ‘이름 확인 실패’에서 ‘인증 실패’로 바뀌었다면 요청이 다른 단계까지 진행된 것입니다. 문제가 더 심각해졌다는 뜻은 아닙니다. 매번 변경한 항목과 새 오류가 발생한 단계를 기록하세요. 장시간 유휴 상태 후에만 연결이 끊긴다면 백그라운드 전환, 네트워크 변경, 재연결 후의 상태도 기록한 뒤 On Demand 같은 자동 연결 설정을 확인하세요. 모든 시간 제한을 바로 늘리지는 마세요.

7. 재테스트 결과와 전달할 정보

유효한 재테스트를 하려면 같은 대상과 구성, 명확한 네트워크 조건에서 반복 확인해야 합니다. 실패 기록과 비교 기록을 각각 한 번 이상 남기고, 연결 여부와 Global Routing 값, 오류가 발생한 단계를 적어 두세요. 한 번 측정한 지연 시간만으로 장기적인 사용 가능성을 판단하지 말고, 처리하지 않은 전체 구성을 다른 사람에게 보내지 마세요.

지연 시간은 표시되는데 왜 접속이 안 되나요?

먼저 Home → Connectivity Test에서 탐지 방식을 확인한 뒤 같은 대상에 실제로 접속해 보세요. TCP 탐지만 통과했다면 프로토콜 인증, TLS, Config의 정책을 계속 확인해야 합니다. 숫자가 표시된다고 전체 요청이 성공한 것은 아닙니다.

Wi-Fi에서는 시간 초과가 나고 셀룰러에서는 정상인데, 비밀번호를 바꿔야 하나요?

비밀번호와 프로토콜 설정은 그대로 두고 두 네트워크에서의 결과를 기록하세요. Wi-Fi 로그인 상태, DNS, UDP 연결 가능성을 확인합니다. 특히 Hysteria2 또는 WireGuard를 사용한다면 네트워크 관리자에게 UDP 통신 제한 여부를 확인하세요.

구독을 업데이트해도 연결되지 않으면 다음에 무엇을 확인해야 하나요?

Home에서 업데이트 후 유효한 항목이 선택되어 있는지 확인한 다음 주소, 포트, 프로토콜을 점검하세요. 항목 하나만 계속 실패한다면 발생 시간, 네트워크 유형, 민감 정보를 가린 오류 내용을 서비스 제공업체에 전달해 확인하세요. 같은 구독을 반복해서 추가하지 마세요.

문제 해결 정보를 전달할 때 어떤 내용을 숨겨야 하나요?

프로토콜 이름, 네트워크 유형, 오류 원문, 재현 절차는 남기고 비밀번호, UUID, 키, 구독 전체 주소와 그 안의 token은 숨기세요. 로그를 전달하기 전 서버 주소와 접속 도메인에 개인정보가 포함되어 있는지도 확인합니다.

기기 측 점검 완료: 직접 연결이 정상이고 시스템 시간이 맞으며, Wi-Fi와 셀룰러 네트워크를 비교해 확인했습니다.
구성 확인 완료: 주소, 포트, 인증, TLS, 전송 설정을 기존 서비스 구성에 맞춰 확인했으며 다른 항목의 값을 섞어 쓰지 않았습니다.
재현 가능한 근거 확보: ‘연결이 안 된다’는 설명에 그치지 않고 구체적인 시간, 오류 단계, 적용된 라우팅 방식과 민감 정보를 가린 로그를 제공합니다.
설정 복원 완료: 점검 후 On Demand, Global Routing, 임시 로그 설정을 원래대로 복원하고 평소 사용하는 방식으로 접속을 확인했습니다.