이 글은 본인이 이용 중인 서비스와 구독이 있지만 Shadowrocket에서 연결 시간이 초과되거나 연결 후 웹사이트에 접속할 수 없는 경우를 위한 안내입니다. 같은 노드로 반복 테스트하고 네트워크별 결과를 비교한 다음, 주소·포트·인증·전송 설정을 차례로 확인하세요. 마지막으로 시스템 시간과 구독 상태를 점검합니다. 문제 해결의 목적은 실패한 단계를 찾는 것이며, 모든 문제를 노드 장애로 단정하는 것이 아닙니다.
1. 지연 시간 초과와 실제 연결 실패 구분하기
Shadowrocket의 지연 테스트 결과와 웹페이지 접속 결과는 서로 다른 지표입니다. 테스트 시간이 초과되면 해당 테스트가 제한 시간 안에 완료되지 않았다는 뜻입니다. 이 결과만으로 계정이 무효이거나 모든 웹사이트에 접속할 수 없다고 단정할 수는 없습니다. 반대로 밀리초 단위의 수치가 표시되어도 해당 테스트가 완료됐다는 의미일 뿐, 이후의 인증·TLS 핸드셰이크·목적지 접속까지 모두 성공한다는 보장은 없습니다.
먼저 Home에서 현재 선택된 노드를 확인한 다음 Connectivity Test를 실행하세요. 테스트 방식을 기록하고, 결과를 비교할 때는 같은 방식을 사용하세요. 테스트 방식을 바꾸면 결과를 직접 비교할 수 없습니다. TCP 연결 테스트와 프록시를 거쳐 목적지에 접속하는 테스트는 확인하는 단계가 다릅니다. 특히 단순 TCP 테스트 결과만으로 UDP 기반 전송의 사용 가능 여부를 판단해서는 안 됩니다.
| 확인된 현상 | 현재 판단할 수 있는 내용 | 다음 단계 |
|---|---|---|
| 같은 노드로 연속 테스트했지만 계속 시간 초과 | 테스트 경로가 계속 완료되지 않았으며, 원인은 아직 확인되지 않음 | 설정은 그대로 두고 Wi-Fi와 셀룰러 네트워크 결과 비교 |
| 테스트에 밀리초 수치가 표시되지만 웹페이지 접속 실패 | 테스트 단계가 통과됐다는 뜻일 뿐, 실제 요청 성공을 의미하지는 않음 | 인증, TLS, Global Routing, DNS 확인 |
| 노드 하나만 실패 | 해당 노드 또는 설정에 문제가 집중됐을 가능성 | 본인이 이미 보유한 다른 노드와 비교 |
| 같은 네트워크에서 모든 노드 실패 | 네트워크 또는 설정에 공통 원인이 있을 가능성 | 먼저 로컬 네트워크가 정상인지 확인한 뒤 네트워크를 바꿔 재시험 |
특정 밀리초 수치를 보편적인 정상 기준으로 삼지 마세요. 지연 시간은 이용 중인 네트워크, 서버 위치, 테스트 대상에 따라 달라집니다. 서로 다른 환경의 수치를 비교하기보다는 같은 노드와 같은 테스트 방식으로 네트워크만 바꿔 기록하면 원인을 좁히는 데 도움이 됩니다.
2. 재현 가능한 테스트 기록을 5단계로 만들기
한 번에 한 가지 조건만 바꾸세요. 구독 업데이트, 프로토콜 변경, DNS 수정, 기기 재시작을 한꺼번에 하면 접속이 복구되어도 어떤 조치가 효과가 있었는지 알기 어렵습니다. 먼저 기존 설정을 보존해 점검 중에도 사용할 수 있는 설정이 덮어써지지 않도록 하세요. 기록은 기기의 메모 앱에 남기면 되며, 전체 설정을 공개할 필요는 없습니다.
-
네트워크 확인
Home의 연결 스위치를 잠시 끄고 현재 Wi-Fi 또는 셀룰러 네트워크에서 평소 직접 접속하는 웹사이트가 열리는지 확인하세요. 공용 Wi-Fi에서 로그인이 필요하다면 네트워크 인증을 마친 뒤 테스트를 진행하세요.
-
노드 고정
Home에서 이미 보유한 노드를 선택하고 Connectivity Test를 실행하세요. 같은 테스트 방식으로 세 번 반복하고, 모두 시간 초과인지, 간헐적으로 성공하는지, 매번 수치가 표시되는지 기록하세요. 세 번의 테스트를 장기적인 사용 가능성 통계로 해석하지는 마세요.
-
네트워크 전환
노드와 설정은 그대로 두고 iPhone 시스템 설정에서 Wi-Fi와 셀룰러 네트워크를 전환한 뒤 같은 테스트를 반복하세요. 특정 네트워크에서만 실패한다면 해당 네트워크의 접속 제한과 UDP 연결 가능 여부를 먼저 확인하세요.
-
실제 접속 확인
Home의 연결 스위치를 켜고 현재 선택된 노드를 확인한 뒤 같은 목적지에 접속하세요. 규칙의 영향을 잠시 분리해 확인하려면 Global Routing을 Proxy로 바꿔 비교 테스트를 할 수 있습니다. 테스트가 끝나면 원래 사용하던 Config로 되돌리세요.
-
자동 연결 확인
수동으로 연결을 끊은 뒤 다시 자동으로 연결된다면 Settings → On Demand를 확인하세요. 기존 설정을 기록하고 On Demand를 잠시 끈 다음 수동 연결 테스트를 반복하세요. 원인을 확인한 뒤에는 평소 사용 방식에 맞게 설정을 복원하세요.
결론: 네트워크에 따라 문제가 달라지는지 먼저 확인
같은 노드가 Wi-Fi에서만 시간 초과되고 셀룰러 네트워크에서는 테스트가 완료된다면 노드 설정은 그대로 두고 Wi-Fi 네트워크 경로를 점검하세요. 곧바로 전체 설정을 다시 만들거나 인증 정보를 바꾸지 마세요.
3. 주소·포트·프로토콜별 설정 확인
Home에서 해당 노드의 편집 화면을 열고 본인의 서비스 제공자가 안내한 최신 설정과 비교하세요. 먼저 Type을 확인하고 서버 주소와 포트, 인증 및 전송 옵션을 차례로 살펴보세요. 서버 주소 입력란에 웹페이지 경로가 포함되어서는 안 됩니다. 포트는 서버에서 수신하도록 설정된 값과 일치해야 합니다. 포트 번호가 443이라고 해서 반드시 TLS를 사용한다는 뜻은 아니며, 설정이 올바르다는 의미도 아닙니다.
예를 들어 서버에서 example.com:443을 지정했다면 주소가 example.com, 포트가 443인지 확인하세요. 속도를 시험해 보겠다며 임의로 8443으로 바꾸지 마세요. 도메인과 포트는 형식 설명을 위한 예시일 뿐 실제 연결에 사용할 수 없습니다. 인증 정보에 불필요한 공백이 있거나 문자가 빠졌거나 대소문자가 달라져도 연결에 실패할 수 있습니다.
| Type | 중점적으로 확인할 항목 | 자주 혼동하는 부분 |
|---|---|---|
| Shadowsocks | 서버 주소, 포트, 암호화 방식, 비밀번호 | 비밀번호가 맞더라도 암호화 방식이 다르면 정상적으로 통신할 수 없음 |
| VMess | UUID, 암호화 설정, 전송 방식, TLS 관련 설정 | 전송 경로 및 Host가 서버 주소와 다를 수 있음 |
| VLESS | UUID, 전송 방식, 서버에서 지정한 TLS 또는 기타 보안 설정 | 주소와 UUID만으로 나머지 옵션을 추측할 수 없음 |
| Trojan | 비밀번호, 서버 포트, TLS server name | 연결 주소와 인증서에 연결된 도메인이 다를 수 있음 |
| Hysteria2 | 인증, TLS server name, UDP 연결 가능 여부, 서버에서 지정한 옵션 | TCP 테스트 성공만으로 QUIC 통신이 가능하다고 볼 수 없음 |
| WireGuard | 로컬 개인 키, 상대방 공개 키, Endpoint, 주소, Allowed IPs | 연결 상태가 표시되어도 유효한 핸드셰이크와 데이터 전송이 완료됐다고 볼 수 없음 |
TLS를 사용하는 설정이라면 연결 주소, server name, 인증서 요구 사항을 함께 확인하세요. 도메인을 IP 주소로 바꾸면 인증서 이름 확인이나 접속 경로가 달라질 수 있습니다. 설정을 바로잡는 대신 인증서 검증을 끄지 마세요. 인증서가 실제로 만료됐다면 서버 관리자가 조치해야 합니다.
4. 오류 메시지 원문으로 실패 단계 찾기
시간 초과는 현상이며, 오류 메시지 원문을 확인해야 연결이 어느 단계에서 실패했는지 구분하는 데 도움이 됩니다. 앱에서 해당 요청의 연결 기록이나 로그를 확인할 때는 오류 문구와 발생 시각을 함께 기록하세요. 아래는 하위 연결 기록에 나타날 수 있는 오류 문구의 예시입니다. 모든 장애에서 고정된 팝업으로 표시되는 것은 아니므로, 같은 문구가 없다면 실제 기록을 기준으로 판단하세요.
오류: i/o timeout
원인: 네트워크 읽기 또는 쓰기 단계에서 대기 시간이 초과된 상태입니다. 이 문구만으로 로컬 네트워크, 서버, 목적지 응답 중 무엇이 문제인지 확인할 수는 없습니다.
해결 방법: 먼저 같은 노드로 네트워크별 결과를 비교한 다음, 오류 전후의 주소와 연결 단계를 함께 살펴보세요. 대기 시간만 늘려 문제를 가리지 않도록 합니다.
오류: connection refused
원인: 목적지 포트가 연결을 명시적으로 거부한 상태입니다. 해당 포트에서 서비스가 수신 대기하지 않거나, 서비스가 중지됐거나, 네트워크 장비가 연결을 차단했을 수 있습니다.
해결 방법: 해당 기록의 목적지가 프록시 서버인지 웹사이트인지 확인하세요. 프록시 서버라면 본인의 서비스 제공자에게 주소, 포트, 서비스 상태를 문의하세요.
오류: no such host
원인: 현재 DNS 조회에서 해당 호스트 이름에 대응하는 주소를 가져오지 못한 상태입니다. 도메인 오타나 DNS 조회 문제가 원인일 수 있습니다.
해결 방법: 먼저 주소에 공백, 프로토콜 접두사, 경로가 섞여 있는지 확인한 다음 다른 네트워크에서 다시 테스트하세요. 도메인이 맞는지 확인하기 전에는 비밀번호를 반복해서 바꾸지 마세요.
오류: certificate has expired or is not yet valid
원인: 인증서 유효 기간과 현재 기기 시간이 일치하지 않는 상태입니다. 시스템 시간이 잘못됐거나 서버 인증서 관리가 필요할 수 있습니다.
해결 방법: 먼저 iPhone의 날짜와 시간을 정확하게 맞춘 뒤 다시 연결하세요. 시간이 맞는데도 오류가 계속되면 서버 관리자에게 알리고 인증서 검증을 건너뛰지 마세요.
기록을 공유할 때는 비밀번호, UUID, 개인 키, 구독 token을 가리세요. 프로토콜 종류, 일부를 가린 서버 주소, 포트, 테스트 시각, 오류 원문은 남겨도 됩니다. 전체 구독 링크에는 계정 접근 권한이 포함될 수 있으므로 공개 문의용 스크린샷에 올리지 마세요.
5. 마지막으로 시스템 시간과 구독 업데이트 확인
iPhone의 ‘설정 → 일반 → 날짜 및 시간’에서 ‘자동으로 설정’을 확인하세요. 기기 시간이 크게 틀렸다면 시간을 바로잡은 뒤 다시 연결하세요. 시간은 TLS 인증서의 유효 기간 확인에 사용되며, 시간 검증이 필요한 인증 절차에도 영향을 줄 수 있습니다. 날짜를 임의로 앞뒤로 바꾸는 것은 해결 방법이 아닙니다.
구독 업데이트와 노드 연결은 서로 다른 요청 경로를 사용합니다. 구독 업데이트는 설정 정보를 가져오고, 노드 연결은 이미 저장된 설정으로 서버에 접속합니다. 따라서 업데이트에 실패해도 기기에 저장된 모든 노드가 즉시 사용할 수 없게 되는 것은 아닙니다. 업데이트에 성공해도 모든 노드에 접속할 수 있다는 뜻은 아닙니다. 업데이트 후에는 연결할 노드를 다시 선택하고 실제로 설정이 어떻게 바뀌었는지 확인하세요.
- 구독 주소 확인: Home에서 이미 등록한 Subscribe 항목이 본인의 유효한 링크를 사용하는지 확인하세요. 형식 예시는
https://example.com/sub?token=xxxx입니다. 주소 형식을 보여 주기 위한 예시일 뿐입니다. - 한 번 업데이트: Home에서 아래로 당겨 기존 구독을 새로고침한 뒤 결과를 기다리고 노드 목록을 확인하세요. 먼저 오류 내용을 기록하고, 문제를 더 복잡하게 만들 수 있으니 새로고침을 연속으로 반복하지 마세요.
- 업데이트 경로 확인: 구독 주소에 프록시를 통해 접속해야 하고 사용할 수 있는 연결이 이미 있다면 Settings → Subscribe → Update via Proxy를 확인하세요. 이 설정은 작동하는 프록시 경로가 있어야 하며, 사용할 수 없는 노드를 저절로 복구하지는 않습니다.
- 서비스 상태 확인: 본인의 서비스 제공자에게 구독 유효 여부, 계정 사용 가능 여부, 주소나 인증 정보 변경 여부를 확인하세요. 앱 구매 상태와 서비스 제공자 계정 상태는 각각 따로 확인해야 합니다.
결론: 업데이트 후 대상 하나만 다시 테스트
먼저 연결에 실패한 노드 하나를 골라 업데이트 전후의 주소, 포트, 인증 정보가 달라졌는지 비교한 뒤 같은 네트워크에서 동일한 테스트를 반복하세요. 설정이 바뀌지 않았는데도 계속 시간 초과가 발생한다면 네트워크 경로와 서버 상태를 다시 점검하세요.
6. 테스트는 통과했지만 웹페이지가 열리지 않을 때 분류 설정 확인
노드 테스트가 완료됐는데 실제 접속은 실패한다면 요청이 해당 노드를 실제로 통과하는지 확인하세요. Home에서 Global Routing을 살펴보세요. Config는 설정에 따라 요청을 처리하고, Proxy는 프록시 경로를 비교하는 용도이며, Direct는 직접 연결 경로를 비교할 때 사용합니다. Scene은 해당 시나리오 설정을 함께 확인해야 합니다. 연결 스위치가 켜져 있다는 이유만으로 모든 트래픽이 프록시를 통과한다고 판단하지 마세요.
Config를 사용할 때는 비활성 파일이 아니라 현재 활성화된 설정을 Config에서 확인하세요. DOMAIN-SUFFIX는 도메인 접미사를 일치시키고, IP-CIDR은 IP 대역을 일치시킵니다. GEOIP는 IP 지리 데이터베이스를 기준으로 판단하고, FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. DIRECT에 일치한 요청은 노드가 선택되어 있어도 자동으로 프록시를 통과하지 않습니다. REJECT에 일치한 요청은 거부됩니다.
- Proxy에서는 접속되지만 Config에서는 실패: 설정의 규칙 순서, 정책 참조, DNS 결과를 먼저 확인하세요. 노드를 바로 다시 만들 필요는 없습니다.
- 웹사이트 하나만 접속 실패: 해당 요청에 적용된 규칙과 목적지의 응답을 확인하세요. 한 사이트만 실패했다고 전체 프록시 경로가 작동하지 않는다고 단정할 수는 없습니다.
- 모든 목적지에 접속 실패: 프로토콜 설정과 연결 기록을 다시 확인해 인증, TLS, 외부 연결 중 어느 단계에서 멈췄는지 살펴보세요.
비교를 마치면 평소 사용하는 라우팅 방식으로 되돌리세요. Proxy는 이번 점검에서 경로를 분리하는 수단이지, 모든 규칙 문제를 해결하는 방법은 아닙니다. 전체 조작 순서는 Global Routing 가이드를 참고하세요.
7. 노드 연결 시간 초과 관련 자주 묻는 질문
노드 하나만 시간 초과되는데 앱을 다시 설치해야 하나요?
먼저 다시 설치하지 마세요. Home에서 본인이 이미 보유한 다른 노드를 선택해 같은 테스트를 해보세요. 다른 노드는 정상이라면 실패한 노드의 주소, 포트, 인증 정보, 서버 상태를 먼저 확인하세요. 앱을 다시 설치해도 원격 서버 포트가 수신 대기하지 않는 문제는 해결되지 않으며, 기기에 저장된 점검 기록이 사라질 수 있습니다.
지연 시간은 표시되는데 연결 후에도 웹페이지가 열리지 않는 이유는 무엇인가요?
먼저 테스트 방식이 어떤 단계까지 확인하는지 살펴본 뒤 Global Routing → Proxy로 실제 접속을 비교하세요. 그래도 실패한다면 인증 및 TLS 오류를 확인하세요. Config에서만 실패한다면 지연 수치만 보는 대신 현재 활성화된 설정의 규칙과 정책을 확인하세요.
구독 새로고침이 시간 초과되면 기존 노드도 사용할 수 없나요?
반드시 그런 것은 아닙니다. 먼저 기기에 저장된 노드를 테스트하고 구독 주소의 접속 경로는 따로 확인하세요. 프록시를 통해 업데이트해야 하는 요청은 사용할 수 있는 프록시 연결이 있어야 Settings → Subscribe → Update via Proxy가 도움이 될 수 있습니다. 구독 링크가 유효한지도 본인의 서비스 제공자에게 확인하세요.
서비스 제공자에게 문의할 때 어떤 정보를 준비해야 하나요?
문제 발생 시각, 사용한 Wi-Fi 또는 셀룰러 네트워크, 프로토콜 종류, 일부를 가린 주소, 포트, 세 차례 테스트 결과를 준비하고 오류 원문을 함께 전달하세요. 네트워크를 바꾼 뒤 복구됐는지, 다른 노드는 정상인지도 알려 주세요. 개인 키, 전체 비밀번호, token이 포함된 구독 링크는 보내지 마세요.