Shadowrocket에서 시간 초과가 발생해도 노드가 반드시 사용할 수 없는 것은 아닙니다. 이 안내는 iPhone / iPad, Mac, Windows, Android, Linux에 적용됩니다. ‘로컬 네트워크 → 테스트 범위 → 프로토콜 설정 → 시스템 시간 → 규칙 및 DNS’ 순서로 원인을 확인하세요. 화면 조작은 iPhone / iPad의 Home, Config, Settings를 기준으로 설명하며, 다른 플랫폼에서는 해당하는 설정을 확인하면 됩니다. 사용자가 서비스 제공업체와 구독을 이미 이용 중인 경우를 전제로 하며, 구독 주소는 이용 중인 서비스 제공업체에서 확인하세요.
1. 노드 시간 초과와 로컬 네트워크 문제 구분하기
먼저 Shadowrocket 연결을 끄고, 브라우저에서 평소 직접 접속할 수 있는 페이지를 엽니다. 로컬 네트워크가 작동하지 않으면 지연 시간 테스트 결과로 원격 서비스 상태를 판단할 수 없습니다. 공용 Wi-Fi는 먼저 네트워크 로그인이 필요할 수 있습니다. Wi-Fi 아이콘이 표시된다고 해서 인터넷을 온전히 사용할 수 있는 것은 아닙니다.
테스트할 때는 한 번에 조건 하나만 바꾸세요. 먼저 같은 네트워크, 같은 노드, 같은 대상을 기준으로 삼은 다음 Wi-Fi와 모바일 네트워크를 바꿔 비교합니다. 구독 업데이트, 프로토콜 변경, Config 교체를 동시에 하지 마세요. 문제가 해결돼도 어떤 변경이 효과가 있었는지 알 수 없습니다.
-
로컬 네트워크 확인
Home에서 연결을 끄고 브라우저로 직접 접속할 수 있는 페이지가 열리는지 확인합니다. 로그인이 필요한 Wi-Fi라면 먼저 인증을 완료하세요.
-
실패 범위 기록
Home에서 테스트할 노드를 선택하고, 특정 노드만 실패하는지, 같은 그룹의 노드가 실패하는지, 모든 노드가 실패하는지 기록합니다. Wi-Fi와 모바일 네트워크 중 어떤 연결을 사용했는지도 함께 적어 두세요.
-
실제 연결 상태 확인
연결을 켠 뒤 Home에서 Connectivity Test를 실행하고, 브라우저에서도 같은 대상에 접속합니다. 테스트 결과와 페이지 로드 여부를 기록하고, 연결 스위치 상태만으로 판단하지 마세요.
-
네트워크를 바꿔 재테스트
노드와 Config는 그대로 두고 다른 사용 가능한 네트워크로 바꿔 같은 테스트를 반복합니다. 한 네트워크에서만 실패한다면 해당 네트워크의 DNS, 접속 제한, UDP 통신 가능 여부를 먼저 확인하세요.
2. 지연 시간 테스트에 값이 표시되는데도 웹페이지가 열리지 않는 이유
지연 시간은 테스트 방식과 함께 해석해야 합니다. TCP 연결 테스트는 지정한 주소와 포트까지의 일부 과정만 확인하므로 비밀번호가 올바른지, 프록시를 통해 대상 웹사이트에 접속할 수 있는지는 알 수 없습니다. 실제 요청을 보내는 테스트는 더 많은 과정을 확인하지만, 해당 시점의 테스트 대상에 대한 결과일 뿐 모든 웹사이트의 접속을 보장하지는 않습니다.
| 확인된 증상 | 우선 판단할 사항 | 다음 조치 |
|---|---|---|
| 특정 노드만 시간 초과, 다른 노드는 정상 | 해당 엔드포인트 또는 설정에 문제가 있을 가능성이 큽니다. | 해당 노드의 주소, 포트, 서비스 상태를 확인하세요. 전체 Config를 초기화하지 마세요. |
| Wi-Fi에서 모든 노드가 실패하고 모바일 네트워크에서는 정상 | 로컬 네트워크 경로에 차이가 있을 수 있습니다. | Wi-Fi 로그인 상태, DNS, UDP 통신 가능 여부를 확인하세요. |
| 포트 테스트에는 지연 시간이 표시되지만 실제 요청은 실패 | 연결 이후 인증, TLS 또는 대상 접속 단계에서 실패했을 수 있습니다. | 실패한 요청의 로그를 확인하고 인증 정보, SNI, 시스템 시간을 점검하세요. |
| 웹페이지는 정상인데 일부 테스트만 실패 | 현재 연결 경로에 맞지 않는 테스트 대상이나 방식일 수 있습니다. | 테스트 유형을 기록하고 실제 서비스 요청으로 교차 확인하세요. |
| 특정 웹사이트 하나만 실패 | 대상 웹사이트, 규칙 또는 DNS 문제일 수 있습니다. | Global Routing의 Proxy와 Config를 비교하고 해당 도메인에 적용된 규칙을 확인하세요. |
요점: 재현 가능한 비교 조건을 먼저 유지하세요
같은 노드가 네트워크를 바꾸자 정상화된다면 기존 네트워크부터 확인하세요. 같은 네트워크에서 특정 노드 하나만 실패한다면 해당 노드부터 점검합니다. 이 기준으로 범위를 좁히면 앱을 반복해서 재설치하는 것보다 원인을 찾기 쉽습니다.
Hysteria2처럼 UDP에 의존하는 전송 방식은 TCP 포트 테스트 한 번으로 사용 가능 여부를 판단할 수 없습니다. 반대로 TCP 테스트가 성공해도 UDP 통신이 원활하다는 뜻은 아닙니다. 테스트 방식과 실제 프로토콜을 따로 기록해 두 결과를 혼동하지 마세요.
3. 프로토콜별 주소, 포트, 인증 설정 확인
Home에서 해당 노드의 편집 화면을 열고 각 항목을 서비스 제공업체가 안내한 원본 정보와 대조하세요. 구독에서 가져온 노드도 원격 설정 변경으로 만료될 수 있습니다. 먼저 업데이트가 정상적으로 완료됐는지 확인한 뒤 설정을 점검하세요. 경험에 따라 포트를 모두 443으로 바꾸거나, 오류를 없애려고 인증서 검증을 끄지 마세요.
- Shadowsocks: 주소, 포트, Password, 암호화 방식을 확인하세요. 비밀번호가 맞더라도 암호화 방식이 다르면 정상적으로 통신할 수 없습니다. 서비스 제공업체가 추가 플러그인 설정을 요구한다면 해당 값도 일치해야 합니다.
- VMess: UUID와 서버에서 요구하는 인증 설정 및 전송 방식을 확인하세요. WebSocket을 사용한다면 Host, Path, TLS 설정도 점검해야 합니다. UUID만 복사해서는 충분하지 않습니다.
- VLESS: UUID와 전송 방식, 서비스 제공업체가 안내한 TLS, REALITY 또는 Flow 설정을 확인하세요. 서로 다른 보안 모드의 항목을 섞어 사용하지 마세요.
- Trojan: Password, 포트, TLS 설정을 확인하세요. SNI에는 서비스 제공업체가 안내한 호스트 이름을 입력하고, 프로토콜 접두사·포트·경로는 포함하지 마세요. 연결 주소와 SNI는 서로 다를 수 있지만 임의로 바꾸면 안 됩니다.
- Hysteria2: 인증 정보, TLS, 서비스 제공업체가 요구하는 난독화 설정을 확인하세요. 현재 네트워크에서 필요한 UDP 통신이 허용되는지도 확인해야 합니다. TCP 연결이 가능하다는 것만으로는 충분하지 않습니다.
- WireGuard: 로컬 개인 키, 피어 공개 키, Endpoint, 터널 주소 등의 설정을 확인하세요. WireGuard는 TLS의 SNI 필드를 사용하지 않으므로 Trojan 문제 해결 절차를 그대로 적용하지 마세요.
TLS의 SNI와 WebSocket의 Host는 서로 다른 개념입니다. SNI는 TLS 핸드셰이크에서 서버를 식별하는 데 사용되며, Host는 HTTP 요청 헤더에 속합니다. 두 값이 같을 때도 있지만 각각 서비스 제공업체의 안내를 기준으로 설정해야 합니다. 노드 이름은 로컬에서 표시되는 라벨일 뿐이며, 이름을 바꿔도 인증이나 연결 실패가 해결되지는 않습니다.
4. 오류 메시지 원문으로 실패 단계 확인
실패 당시의 로그 또는 시스템 오류 상세 정보를 확인하고, 오류 원문과 발생 시각을 먼저 기록하세요. 아래는 네트워크 및 TLS 계층에서 흔히 볼 수 있는 오류입니다. 구체적인 접두사는 플랫폼과 연결 단계에 따라 달라질 수 있습니다. 화면에 Timeout만 표시된다면 앞서 진행한 네트워크 비교 테스트 결과와 함께 판단하세요.
오류: connection timed out
원인 및 해결 방법: 대기 시간 안에 예상한 응답을 받지 못한 상태입니다. 주소, 포트, 네트워크 경로 또는 원격 서비스 상태가 원인일 수 있습니다. 같은 노드로 네트워크를 바꿔 다시 테스트한 다음, 이용 중인 서비스 제공업체에 엔드포인트가 여전히 유효한지 확인하세요.
오류: connection refused
원인 및 해결 방법: 대상 또는 중간 네트워크 장비가 연결 요청을 거부한 상태입니다. 포트와 프로토콜을 확인하세요. 대기 시간을 늘리는 것만으로 해결되지는 않습니다. 포트가 맞다면 서비스 제공업체에 서버의 리스닝 서비스를 확인해 달라고 요청하세요.
오류: certificate has expired or is not yet valid
원인 및 해결 방법: 기기의 시간이 잘못됐거나 서버 인증서의 유효 기간이 실제로 지났을 수 있습니다. 먼저 시스템 시간을 맞춘 뒤 다시 시도하세요. 계속 실패하면 서비스 제공업체에 인증서를 확인해 달라고 요청하세요. 인증서 검증을 건너뛰는 방식으로 계속 사용하지 마세요.
오류: no such host
원인 및 해결 방법: 호스트 이름을 조회하지 못했거나 사용할 수 있는 레코드를 찾지 못한 상태입니다. 주소 철자를 확인하고 로컬 네트워크가 작동하는지 점검하세요. 조회에 실패한 도메인이 노드 도메인인지 대상 웹사이트 도메인인지도 구분해야 합니다.
로그의 EOF를 비밀번호 오류로 단정하지 마세요. EOF는 연결이 종료됐다는 의미이며, 인증 정보 불일치, 전송 설정 오류, 원격 서버의 조기 종료 등 여러 상황에서 발생할 수 있습니다. 앞뒤의 TLS, DNS 조회, 연결 정보를 함께 확인한 뒤 어떤 항목을 바꿀지 결정하세요.
5. 시스템 시간과 자동 설정 확인
시스템 시간이 정확하지 않으면 인증서 유효 기간 판정에 영향을 줄 수 있으며 일부 인증 절차에도 문제가 생길 수 있습니다. 중요한 것은 화면에 표시된 시간대가 아니라 기기의 현재 시간이 정확한지 여부입니다. 시간대를 수동으로 바꾸는 것은 시간 동기화를 대신할 수 없습니다. 자동 설정을 선택한 뒤 날짜, 연도, 시각이 실제로 정상화됐는지 확인하세요.
- iPhone / iPad: 시스템의 “설정 → 일반 → 날짜 및 시간 → 자동으로 설정”을 켜세요. 옵션을 변경할 수 없다면 기기 관리 또는 시스템 제한을 확인한 뒤 Shadowrocket에서 연결을 다시 설정하세요.
- Mac: “시스템 설정 → 일반 → 날짜 및 시간”을 열고 날짜와 시간 자동 설정을 활성화한 다음 현재 시간이 정확한지 확인하세요.
- Windows: “설정 → 시간 및 언어 → 날짜 및 시간”을 열고 시간 자동 설정을 켠 뒤 시스템의 지금 동기화 기능을 사용하세요.
- Android: 시스템 설정에서 “날짜 및 시간”을 검색하고 시간 자동 설정을 켜세요. 메뉴 이름은 기기에 따라 다를 수 있습니다. 시간대 자동 설정도 함께 확인하세요.
- Linux: 시스템의 날짜 및 시간 설정에서 네트워크 시간 동기화를 활성화하세요. 그래픽 설정 화면이 없다면 기기 관리자에게 시간 동기화 서비스 상태를 확인해 달라고 요청하세요.
6. 연결은 됐지만 웹페이지가 열리지 않을 때: Global Routing, DNS, On Demand 확인
노드는 사용할 수 있지만 웹페이지가 열리지 않는다면 Home → Global Routing을 확인하세요. Proxy는 프록시가 적용된 트래픽을 선택한 프록시로 전달하고, Direct는 직접 연결하며, Config는 현재 설정의 규칙에 따라 트래픽을 분기합니다. Scene은 선택한 시나리오 설정을 적용하므로 해당 시나리오의 내용도 확인해야 합니다. 문제를 확인하는 동안 Proxy와 Config를 잠시 비교한 뒤 원래 사용하던 설정으로 되돌리세요.
- Proxy는 정상이고 Config는 실패: Config에서 현재 활성화된 설정과 규칙의 적용 순서를 확인하세요. DOMAIN-SUFFIX는 도메인 접미사를 기준으로 일치하며, GEOIP와 IP-CIDR은 IP 조건으로 일치합니다. FINAL은 앞선 규칙에 일치하지 않은 연결에 적용됩니다.
- Proxy와 Config 모두 실패: 엔드포인트, 프로토콜, DNS를 다시 확인하세요. FINAL만 바꾸지 마세요. 노드 도메인을 조회하지 못하면 연결을 시작할 수 없으며, 대상 도메인 조회 실패는 터널이 이미 연결된 뒤에 발생할 수도 있습니다.
- 연결을 끈 뒤 자동으로 다시 켜짐: Settings → On Demand와 기존 조건을 확인하세요. 문제를 살펴보는 동안 자동 실행을 잠시 끄면 자동 재연결을 수동 조작이 적용되지 않은 것으로 오해하는 일을 막을 수 있습니다. 확인을 마치면 필요한 설정을 다시 켜세요.
- 절전 모드에서 깨어나거나 네트워크를 바꾼 뒤 실패: 복구 전후의 네트워크 유형을 기록하고 연결을 수동으로 끊었다가 다시 연결하세요. 특정 조건에서만 문제가 발생한다면 해당 조건에 연결된 On Demand 설정을 확인하세요.
규칙은 위에서 아래로 평가되며 먼저 일치한 규칙이 이후 처리에 영향을 줍니다. Config에 해당 도메인 규칙이 있는지만 보지 말고, 앞선 규칙이 먼저 적용되는지도 확인하세요. 특정 웹사이트 하나만 실패한다면 대상 도메인과 실제로 적용된 정책을 기록하는 편이 Config 전체를 교체하는 것보다 원인을 파악하는 데 도움이 됩니다.
7. 자주 묻는 질문과 문의 전 기록할 정보
구독 업데이트도 시간 초과됩니다. 모든 노드를 사용할 수 없게 된 건가요?
그렇지 않습니다. 구독 다운로드와 노드 연결은 서로 다른 요청 경로를 사용합니다. 먼저 기존 노드를 사용할 수 있는지 확인한 뒤 구독 주소가 유효한지, 만료 또는 접근 제한이 있는지 점검하세요. 주소는 이용 중인 서비스 제공업체에서 확인할 수 있습니다. 업데이트가 완료되면 노드 설정이 바뀌었는지 비교하세요.
지연 시간은 짧은데 동영상이 계속 버퍼링되는 이유는 무엇인가요?
지연 시간은 한 번의 테스트에서 측정한 응답 시간이며 지속적인 전송 속도를 의미하지 않습니다. 같은 대상을 기준으로 다른 기존 노드와 다른 네트워크를 비교하세요. 해당 웹사이트에서만 문제가 발생하는지도 확인하고, 지연 시간이 가장 짧다는 이유만으로 노드를 선택하지 마세요.
인증서 검증을 끄면 연결되는데, 해결된 것으로 봐도 되나요?
그것만으로 문제가 해결됐다고 볼 수 없습니다. 인증서 검증을 다시 켜고 시스템 시간, SNI, 서버 인증서를 확인하세요. 서비스 제공업체가 별도의 신뢰 설정을 안내했다면 인증서 출처와 올바른 설정을 문의하고, 오류를 계속 무시한 채 사용하지 마세요.
구독 링크 전체와 로그를 함께 보내야 하나요?
구독 링크 전체, 비밀번호, UUID, 개인 키를 공개하지 마세요. 이용 중인 서비스 제공업체에 문의할 때는 문제 발생 시각, 플랫폼, 네트워크 유형, 프로토콜, 오류 원문, 필요한 부분만 포함한 민감 정보 제거 로그를 전달하세요. 스크린샷을 공유하기 전에는 인증 정보를 가리세요.
마지막으로 발생 시각과 시간대, 기기 플랫폼, Wi-Fi 또는 모바일 네트워크, 특정 노드 또는 전체 노드의 실패 여부, 현재 Global Routing 설정, 오류 원문, 네트워크 변경 후 비교 결과를 간단히 기록하세요. 초기화나 재설치가 필요하다면 기존 Config를 먼저 백업하세요. 재설치로는 서버 중단, 잘못된 인증 정보, 만료된 인증서를 해결할 수 없습니다.