Shadowrocket에서 노드 테스트가 시간 초과되거나, 연결 스위치를 켰는데도 웹페이지가 열리지 않거나, 구독 갱신이 시간 초과되는 문제는 각각 다른 단계에서 발생할 수 있습니다. 사용자가 이미 보유한 서비스와 구독을 전제로 테스트 범위, 연결 설정, 시스템 시간, 네트워크 환경을 차례로 점검합니다. 한 번에 한 가지 조건만 바꾸고 실패 기록을 남긴 뒤 같은 대상으로 다시 테스트하세요.
1. 노드·웹페이지·구독 시간 초과 구분하기
시간 초과는 작업이 제한 시간 안에 완료되지 않았다는 뜻이며, 비밀번호가 틀렸거나 서버가 중지됐다는 의미는 아닙니다. Shadowrocket의 연결 스위치가 켜져 있으면 시스템 터널이 해당 상태라는 점만 확인할 수 있습니다. 원격 인증 성공이나 모든 웹사이트에 대한 접속까지 보장하지는 않습니다. 문제가 발생한 단계를 먼저 파악해야 관련 없는 설정을 반복해서 바꾸지 않을 수 있습니다.
위 흐름은 문제를 점검할 범위를 나누기 위한 것으로, 모든 프로토콜이 내부적으로 동일한 순서로 처리된다는 뜻은 아닙니다. 예를 들어 TLS 정보는 핸드셰이크에 영향을 줄 수 있고, 규칙은 도메인을 기준으로 먼저 판정될 수도 있습니다. 실제 원인을 찾으려면 테스트 대상과 요청 기록을 함께 살펴보세요. 빨간색 결과 하나만으로 어느 단계에서 문제가 생겼는지 단정할 수 없습니다.
- 특정 노드만 테스트에 실패하는 경우: 해당 노드의 주소와 포트, 프로토콜 설정, 현재 네트워크에서 서버에 연결할 수 있는지부터 확인하세요.
- 노드 지연 시간은 표시되지만 웹페이지가 열리지 않는 경우: 인증, DNS, Global Routing, 대상 사이트를 추가로 확인하세요. 포트에 연결할 수 있다고 해서 프록시 요청 전체가 성공하는 것은 아닙니다.
- 구독 갱신만 실패하는 경우: 구독 URL과 접속 경로, 서비스 제공자 측 상태를 먼저 확인하세요. 이 문제만으로 기존 노드가 모두 작동하지 않는다고 판단하지 마세요.
- 모든 노드가 동시에 실패하는 경우: 로컬 네트워크와 시스템 시간, 공통 설정의 출처를 먼저 점검한 뒤 서버 상태를 각각 확인하세요.
2. 테스트 조건을 고정하고 지연 결과 해석하기
Home에서 Connectivity Test를 실행하기 전에 선택한 노드와 현재 네트워크, 테스트 방식을 기록하세요. 테스트 방식에 따라 연결 수립만 확인할 수도 있고 테스트 URL에 요청을 보낼 수도 있습니다. 후자의 경우 DNS, TLS, 테스트 대상의 응답도 결과에 영향을 줍니다. 따라서 방식이 다른 테스트의 수치를 직접 비교할 수 없으며, 한 번의 결과로 대역폭을 판단할 수도 없습니다.
-
현재 상태 기록
Home에서 현재 선택된 노드를 확인하고 Global Routing 설정, Wi-Fi 또는 셀룰러 네트워크, 실패가 발생한 시간을 기록하세요. 기록에 비밀번호나 전체 구독 URL을 남기지 마세요.
-
테스트 반복
Home에서 Connectivity Test를 사용해 같은 방식으로 연속 3회 확인하고 매번 결과를 기록하세요. URL 테스트를 사용한다면 테스트 대상도 동일하게 유지하세요.
-
네트워크 전환
셀룰러 데이터 사용이 가능한 경우 Wi-Fi에서 셀룰러 네트워크로 전환한 뒤 같은 노드를 3회 테스트하세요. 이때 포트, DNS, 프로토콜은 함께 변경하지 마세요.
-
요청 확인
노드를 선택하고 연결을 켠 다음, 정상적으로 열리는 것을 확인한 HTTPS 페이지에 접속하세요. 페이지 접속 결과와 테스트 결과를 따로 기록해 서버 연결 가능 여부와 실제 요청 성공 여부를 구분하세요.
| 기록 예시 | 판단할 수 있는 내용 | 다음 단계 |
|---|---|---|
| 같은 방식으로 180ms, 210ms, 시간 초과가 차례로 나타남 | 결과가 변동하므로 가장 낮은 값만으로 안정성을 판단할 수 없음 | 설정을 그대로 유지한 채 네트워크를 전환해 다시 테스트 |
| 연결 테스트는 성공했지만 URL 테스트는 시간 초과 | 연결 수립 결과와 전체 요청 결과가 서로 다름 | 인증, 테스트 대상, DNS 확인 |
| Wi-Fi에서는 3회 모두 시간 초과, 셀룰러에서는 3회 모두 성공 | 네트워크 경로와 관련된 문제일 가능성이 높음 | Wi-Fi 로그인 상태와 네트워크 제한 확인 |
표의 수치는 기록 방법을 보여 주는 예시이며, 이 사이트의 측정 결과가 아니고 어떤 회선의 성능을 나타내지도 않습니다. 테스트 대상 자체에 연결할 수 없다면 URL 테스트도 실패합니다. 노드 문제로 오인하지 않도록 정상 작동이 확인된 다른 대상으로 교차 점검하세요.
결론: 테스트 방식을 고정한 다음 설정을 변경하세요
‘같은 노드, 같은 대상, 두 가지 네트워크’의 비교 기록을 남기세요. 특정 조건을 바꾼 뒤 결과가 일관되게 달라지는 경우에만 해당 조건을 기준으로 추가 점검하세요.
3. 주소, 포트, 인증 정보 및 전송 설정 확인
Home에서 해당 노드의 편집 화면을 열고 서비스 제공자가 전달한 원본 설정과 항목별로 비교하세요. 표시 이름을 서버 주소로 착각하지 말고, 프로토콜 이름이 같다는 이유만으로 다른 노드의 설정을 재사용하지 마세요. 포트 443은 특정 포트 번호일 뿐 TLS가 자동으로 활성화된다는 뜻이 아닙니다. 실제 포트와 TLS 사용 여부는 서버 설정에 따라야 합니다.
| 점검 항목 | 확인할 내용 | 일반적인 영향 |
|---|---|---|
| 주소 및 포트 | 서버 주소에 URL 경로가 섞여 있지 않은지 확인하세요. 포트에는 서버에서 지정한 443 또는 8443 같은 정수를 사용하고 임의로 바꾸지 마세요. | 주소 확인 실패, 연결 거부 또는 응답 대기 시간 초과 |
| Shadowsocks | 암호화 방식과 비밀번호, 설정에서 실제 사용하는 플러그인 매개변수를 확인하세요. | 기본 연결은 수립되어도 유효한 프록시 요청을 완료하지 못할 수 있음 |
| VMess / VLESS | UUID와 해당 프로토콜 옵션, 전송 방식을 확인하세요. 원본 설정에서 요구하는 항목만 입력하세요. | 인증 또는 전송 계층 설정 불일치 |
| Trojan | 비밀번호와 TLS 설정, 서버에서 요구하는 Server Name을 확인하세요. | 인증 실패 또는 TLS 핸드셰이크 실패 |
| WebSocket 전송 | Path와 Host를 확인하세요. Path의 앞부분에 있는 슬래시와 대소문자는 원본 설정 그대로 유지하세요. | 요청이 서버에 도달했지만 올바른 프록시 진입점으로 연결되지 않음 |
| Hysteria2 / WireGuard | UDP 연결 가능 여부와 인증 정보, 키, Peer 등 프로토콜 필드를 확인하세요. | 현재 네트워크에서 UDP가 제한되면 다른 TCP 요청이 정상이어도 이 연결이 작동한다고 볼 수 없음 |
비밀번호, UUID, 키를 복사할 때 앞뒤 공백과 줄바꿈이 없는지 확인하세요. TLS의 Server Name은 핸드셰이크와 인증서 신원 확인에 사용되고, WebSocket의 Host는 해당 요청의 라우팅에 사용됩니다. 둘 다 도메인이라는 이유로 서로 바꿔 쓸 수 없습니다. 연결 주소가 IP여도 서비스 제공자가 지정한 Server Name을 유지해야 할 수 있습니다.
4. 오류 메시지를 대조하고 시스템 시간 및 TLS 확인
오류 문구는 기기에 실제로 기록된 내용을 기준으로 확인하세요. 프로토콜과 하위 구현에 따라 표현이 다를 수 있습니다. 서비스 제공자에게 문의할 때는 ‘시간 초과’라고만 전달하는 것보다 전체 오류 문구와 발생 시간을 남기는 편이 원인 파악에 도움이 됩니다. 아래는 흔히 볼 수 있는 하위 단계의 오류 일부이며, 모든 실패에서 해당 문구가 나타나는 것은 아닙니다.
오류: i/o timeout
원인과 해결 방법: 읽기 또는 쓰기 작업이 제한 시간을 넘었지만, 이 문구만으로 구체적인 원인을 알 수는 없습니다. 연결 단계와 요청 단계 중 어디에서 발생했는지 기록한 뒤 같은 노드로 네트워크를 바꿔 연결 가능 여부를 확인하세요.
오류: connection refused
원인과 해결 방법: 대상 호스트 또는 경로상의 장비가 연결을 명시적으로 거부했습니다. 먼저 포트를 확인한 뒤 서비스 제공자에게 해당 포트가 수신 대기 중인지, 접근 제어가 적용되고 있는지 문의하세요.
오류: TLS handshake timeout
원인과 해결 방법: 제한 시간 안에 TLS 핸드셰이크가 완료되지 않았습니다. 포트와 TLS 설정, Server Name을 확인하고 네트워크를 전환해 핸드셰이크 트래픽이 차단되거나 연결 응답이 지나치게 느린지 점검하세요.
오류: certificate has expired or is not yet valid
원인과 해결 방법: 현재 시간이 인증서 유효 기간에 포함되지 않습니다. 먼저 기기의 날짜와 시간을 맞추세요. 그래도 실패한다면 서비스 제공자에게 서버 인증서가 만료됐거나 아직 유효하지 않은 상태인지 확인해 달라고 요청하세요.
iPhone 또는 iPad의 시스템 ‘설정 → 일반 → 날짜 및 시간’에서 ‘자동으로 설정’을 확인하세요. 표시된 날짜와 시간이 올바른지 확인한 뒤 다시 연결합니다. VMess 인증도 시간 동기화에 영향을 받으므로 기기 시간이 크게 어긋났다면 UUID를 반복해서 바꾸기 전에 시간을 먼저 맞추세요. TLS 시간 초과와 인증서 유효 기간 오류는 서로 다른 현상이며 모든 핸드셰이크 실패가 시간 문제인 것은 아닙니다.
5. 연결은 됐지만 웹페이지가 열리지 않을 때: 라우팅 및 DNS 확인
노드 테스트는 정상이지만 실제 웹페이지 접속만 실패한다면 Home으로 돌아가 Global Routing을 확인하세요. Proxy, Direct, Config, Scene은 각각 다른 라우팅 방식입니다. Direct는 프록시를 거치지 않고, Config는 현재 설정의 규칙에 따라 처리하며, Scene은 선택된 장면을 함께 확인해야 합니다. 비교를 위해 잠시 Proxy를 사용할 수 있지만 테스트가 끝나면 원래 설정으로 되돌리세요. 임시 변경을 규칙이 수정된 것으로 간주하면 안 됩니다.
- 우선 적용되는 규칙 확인: Config에서 현재 설정을 확인하세요.
DOMAIN-SUFFIX는 도메인 접미사를,GEOIP와IP-CIDR은 IP 조건을 처리하고,FINAL은 마지막 기본 규칙으로 사용됩니다. 규칙의 순서에 따라 트래픽의 출구가 달라질 수 있습니다. - 규칙에 의한 차단과 네트워크 시간 초과 구분: 대상이
REJECT규칙에 해당하면 규칙에 의해 요청이 거부된 것입니다. 이 문제를 해결하려고 노드 비밀번호를 바꾸지 마세요. 먼저 규칙이 대상 도메인에 잘못 적용됐는지 확인하세요. - DNS 문제 범위 확인: 연결 주소가 도메인이라면 먼저 서버 주소를 확인해야 합니다. 웹페이지 대상 도메인의 확인은 별도의 단계입니다. 어느 도메인에서 실패하는지 기록한 다음 설정의 DNS 항목과 리졸버 연결 가능 여부를 확인하세요.
- HTTPS 사이트에 IP 주소로 접속한 결과만으로 판단하지 않기: IP에 직접 접속하면 올바른 도메인 정보가 전달되지 않아 인증서나 사이트 라우팅이 맞지 않을 수 있습니다. 이 결과만으로 DNS가 정상인지 비정상인지 단정할 수 없습니다.
큰 페이지나 동영상, 대용량 전송만 멈추고 짧은 요청은 완료된다면 경로 MTU 문제 등을 검토하세요. WireGuard는 기존 설정에 지정된 MTU를 우선 사용해야 합니다. 조정이 필요하면 원래 값을 보관하고 서비스 제공자에게 확인한 뒤 단독으로 다시 테스트하세요. DNS, 라우팅, MTU를 한꺼번에 바꾸지 마세요.
6. 네트워크 환경, On Demand, 구독 갱신 간섭 점검
공용 Wi-Fi는 먼저 웹 로그인을 완료해야 할 수 있습니다. Shadowrocket 연결을 끄고 현재 네트워크에서 기본적인 웹 접속이 가능한지 확인하세요. 기본 네트워크 연결부터 되지 않으면 프로토콜을 바꿔도 해결되지 않습니다. 셀룰러 데이터를 사용할 때는 시스템에서 Shadowrocket의 셀룰러 데이터 사용이 허용되어 있는지, 다른 VPN 설정이나 기기 관리 정책이 연결에 영향을 주는지도 확인하세요.
Settings → On Demand에서 자동 연결 조건이 켜져 있는지 확인하세요. 점검 중 연결이 자동으로 다시 설정된다면 On Demand를 잠시 끄고 연결 스위치를 직접 조작할 수 있습니다. 재테스트가 끝나면 기록해 둔 원래 설정으로 되돌리세요. On Demand는 시스템이 연결을 시작하는 조건을 관리할 뿐, 서버 주소나 포트, 인증 정보를 수정해 주지는 않습니다.
Wi-Fi에서는 시간 초과되는데 셀룰러에서는 왜 정상인가요?
같은 노드와 테스트 대상을 유지한 채 먼저 Wi-Fi 로그인을 완료하고 다시 테스트하세요. Wi-Fi에서만 계속 실패한다면 네트워크 유형과 사용 중인 프로토콜을 기록하고 네트워크 관리자나 서비스 제공자에게 포트 및 UDP 등의 트래픽 제한 여부를 확인하세요. 모든 설정을 먼저 초기화하지 마세요.
구독 갱신이 시간 초과되면 기존 노드를 모두 삭제해야 하나요?
기존 설정은 그대로 두세요. Home에서 보유한 구독을 갱신하고 링크가 여전히 유효한지, 서비스 제공자가 구독 주소나 접속 조건을 변경했는지 확인하세요. 갱신 요청 실패가 이미 가져온 노드의 동시 작동 중지를 의미하지는 않습니다. 설정을 삭제하면 비교에 필요한 조건을 잃게 됩니다.
노드 지연 시간은 표시되는데 연결한 뒤에도 웹페이지가 열리지 않는 이유는 무엇인가요?
먼저 테스트 방식을 확인한 다음 Home에서 Global Routing을 잠시 Proxy로 바꾸고 같은 HTTPS 페이지에 다시 접속하세요. 계속 실패하면 인증, TLS, DNS를 추가로 확인하세요. 접속이 정상화되면 Config로 돌아가 원래 규칙의 적용 여부를 확인한 뒤 기존 라우팅 설정을 복원하세요.
앱을 반복해서 재설치하면 시간 초과 문제가 해결되나요?
재설치해도 서버 포트와 구독 상태, 네트워크 제한은 바뀌지 않습니다. 먼저 설정을 대조하고 두 네트워크에서 테스트한 뒤 본인 설정을 백업하세요. 앱의 로컬 상태에 문제가 있다는 점이 확인된 경우에만 점검 결과에 따라 조치하고 기존 기록을 잃지 않도록 하세요.
7. 계속 실패한다면 필요한 정보만 정리해 문의하기
위 단계를 모두 진행해도 원인을 찾지 못했다면 설정을 무작위로 계속 바꾸기보다 재현 가능한 조건으로 문제 범위를 좁히세요. 서비스 제공자에게 문의할 때는 사용 중인 프로토콜과 테스트 방식, 실패 단계를 구체적으로 설명하세요. 학교나 직장의 관리 대상 네트워크를 이용 중이라면 해당 관리자에게 네트워크 제한을 확인해야 합니다.
- 발생 시간과 시간대, 기기 모델, 실제 사용 중인 운영체제 및 앱 정보
- Wi-Fi와 셀룰러 네트워크의 비교 결과. 각 네트워크에서 같은 방식으로 테스트한 기록 3회분
- 특정 노드에서만 실패하는지 여부와 연결 테스트, URL 테스트, 실제 웹페이지 요청 각각의 결과
- 민감 정보를 가린 프로토콜 유형, 포트, TLS 상태, 전체 오류 문구. 비밀번호, 개인 키, UUID, 전체 구독 URL은 공개하지 마세요.
- 변경한 항목과 복원 여부, 특히 Global Routing, On Demand, DNS, MTU