서비스 제공업체의 구독을 이미 보유하고 있지만 Shadowrocket에서 노드 시간 초과나 연결 실패를 겪는 사용자를 위한 안내입니다. 로컬 네트워크, Connectivity Test, 프로토콜 설정, 시스템 시간, 실제 요청 순으로 확인해 포트에 연결할 수 없는 경우, 인증 실패, 규칙이 예상한 정책을 적용하지 않는 경우를 구분하세요. 한 번에 하나의 조건만 바꾸고 결과를 다시 확인할 수 있도록 기록해 두세요.
1. 먼저 어느 단계에서 실패하는지 확인하기
Home에서 연결 스위치를 켰다고 해서 원격 노드의 인증이 완료되거나 웹 요청이 반드시 해당 노드를 통과하는 것은 아닙니다. 시스템은 먼저 로컬 VPN 터널을 만든 뒤, 개별 요청이 발생할 때 원격 연결을 시도할 수 있습니다. 따라서 ‘VPN 표시가 나타남’, ‘노드에 지연 시간 값이 표시됨’, ‘웹페이지에 접속할 수 있음’은 서로 다른 관찰 결과입니다.
시작하기 전에 현재 네트워크가 Wi-Fi인지 셀룰러인지, 선택한 노드, Global Routing 상태, 실패 시각을 기록하세요. 구독을 삭제하거나 설정 전체를 초기화하거나 여러 설정값을 한꺼번에 바꾸지 마세요. 어느 단계에서 결과가 달라졌는지 파악하기 어렵습니다. 아래 표는 증상을 해석하는 방법이며 특정 회선의 실측 결과가 아닙니다.
| 확인된 증상 | 가능한 의미 | 다음 단계 |
|---|---|---|
| Shadowrocket 연결을 끈 뒤에도 일반 웹페이지가 열리지 않음 | 로컬 네트워크가 정상적으로 접속할 수 있는 상태가 아닐 수 있음 | Wi-Fi 로그인 인증을 완료하거나 셀룰러 네트워크로 전환해 확인 |
| TCP 테스트에는 값이 표시되지만 실제 요청은 실패 | 대상 포트에 연결할 수 있을 가능성은 있지만, 인증과 TLS 성공을 의미하지는 않음 | 비밀번호, UUID, SNI, 전송 설정 확인 |
| 테스트는 시간 초과되지만 웹페이지는 정상적으로 열림 | 테스트 방식이나 대상이 실제 요청과 다를 수 있음 | 테스트 방식과 웹 요청에 실제로 적용된 정책 확인 |
| Wi-Fi에서만 실패하고 셀룰러 네트워크에서는 정상 | 현재 네트워크 경로와 관련된 문제일 가능성이 높음 | Wi-Fi 인증, DNS, 네트워크 접근 제한 확인 |
| 기존 노드 중 하나만 실패하고 다른 노드는 사용 가능 | 클라이언트 전체의 문제라고 단정하기 어려움 | 해당 노드 설정을 확인하고 서비스 제공업체에 상태 문의 |
결론: 재현 가능한 비교 조건을 하나씩 유지하세요
실패하는 노드 하나와 테스트 대상 하나를 정하고 설정은 그대로 둔 채 Wi-Fi와 셀룰러 네트워크에서 각각 한 번씩 테스트하세요. 네트워크에 따라 결과가 달라지면 먼저 네트워크 경로를 확인하고, 계속 실패하면 설정값을 점검하세요.
2. 정해진 순서에 따라 지연 시간과 연결 테스트하기
지연 시간 테스트는 특정 테스트 조건에서만 답을 알려 줍니다. TCP 테스트는 주로 TCP 연결 수립 여부를 확인합니다. 밀리초 값이 표시되더라도 프로토콜 인증이나 실제 요청의 성공을 의미하지는 않습니다. UDP를 사용하는 연결에서는 TCP 테스트 결과만으로 판단해서는 안 됩니다. 서로 다른 테스트 방식으로 얻은 값을 그대로 비교해 순위를 매기지 마세요.
-
로컬 네트워크 확인
Home에서 연결 스위치를 끄고 Safari로 평소 직접 접속할 수 있는 페이지를 여세요. Wi-Fi에서 웹 로그인이 필요하다면 먼저 인증을 완료하세요. 그래도 접속되지 않으면 노드 비밀번호를 바꾸기 전에 기기의 네트워크 연결부터 확인해야 합니다.
-
테스트할 노드 선택
Home으로 돌아가 확인할 노드를 직접 선택하고 이름과 프로토콜을 기록하세요. 목록에서 특정 항목의 지연 시간만 확인하고 실제 연결에서는 다른 항목이 선택된 상태로 두지 마세요.
-
연결 테스트 실행
Home에서 Connectivity Test를 실행하고 선택한 테스트 방식, 결과, 네트워크 유형을 기록하세요. 같은 방식으로 3회 반복하고 매번 결과를 남기세요. 가장 빠른 결과만 기록하지 마세요.
-
규칙의 영향 분리
Home → Global Routing을 임시로 Proxy로 전환하고 테스트할 노드가 선택되어 있는지 확인한 다음 연결 스위치를 켜고 같은 웹페이지를 요청하세요. 테스트가 끝나면 원래 Config 또는 Scene으로 되돌려 문제 해결용 설정을 장기 설정으로 남기지 마세요.
-
네트워크를 바꿔 재테스트
노드, 테스트 방식, 대상을 그대로 유지한 채 사용 가능한 다른 네트워크로 전환해 테스트를 반복하세요. 자동 재연결을 확인하는 중이라면 Settings → On Demand에서 요청 시 연결을 잠시 중지한 뒤, 확인이 끝나면 원래 설정으로 복구하세요.
Proxy에서는 요청이 성공하고 Config로 되돌리면 실패한다면 프로토콜 설정을 계속 바꾸기보다 Config의 일치 규칙, 정책 연결, DNS를 먼저 확인하세요. Global Routing이 Direct이면 요청이 직접 연결되므로 이를 근거로 프록시 노드가 정상이라고 판단할 수 없습니다. Scene을 사용한다면 현재 Scene에 어떤 라우팅 설정이 적용되는지 확인하세요.
3. 프로토콜 설정과 구독 정보를 항목별로 확인하기
노드 이름은 단순한 표식입니다. 이름이 같아도 주소, 포트, 인증 정보가 바뀌었을 수 있습니다. Home에서 해당 노드의 편집 화면을 열고 서비스 제공업체가 제공한 최신 정보와 대조하세요. 구독을 보유하고 있다면 먼저 구독을 업데이트한 뒤 확인하세요. 비밀번호, UUID, 전송 경로를 온라인 글만 보고 추측하지 마세요.
| 항목 | 확인할 내용 | 흔한 오해 |
|---|---|---|
| Address / Port | 주소에 웹페이지 경로가 들어가 있지 않은지, 포트가 서비스 제공업체의 정보와 일치하는지 확인 | TLS가 보인다는 이유로 원래 포트를 443으로 변경하는 것. 443은 흔히 쓰이는 포트일 뿐 필수값이 아닙니다. |
| Shadowsocks | 암호화 방식과 비밀번호, 서비스 제공업체가 요구하는 플러그인 설정을 함께 확인 | 비밀번호가 맞으면 나머지 항목도 모두 맞다고 판단하는 것 |
| VMess / VLESS | UUID, TLS 상태, 전송 방식을 확인하고 WebSocket 사용 시 Host와 Path를 다시 확인 | WebSocket의 Host, TLS의 SNI, 연결 주소가 반드시 같다고 보는 것 |
| Trojan | 비밀번호, SNI, 포트, 인증서 검증 조건을 확인 | 잘못된 서버 이름을 수정하는 대신 인증서 검증을 끄는 것 |
| Hysteria2 | 인증 정보와 TLS 설정을 확인하고 현재 네트워크에서 필요한 UDP 통신을 허용하는지 확인 | TCP 테스트에 성공했으니 UDP 경로도 정상이라고 판단하는 것 |
| WireGuard | 키, Endpoint, 터널 주소, Allowed IPs를 확인 | Endpoint만 확인하고 터널 내부 주소나 라우팅 범위는 놓치는 것 |
SNI는 TLS 핸드셰이크에서 서버 이름을 표시하는 데 사용됩니다. 인증서를 검증하려면 이름, 신뢰 체인, 유효 기간도 확인해야 합니다. 연결 주소가 IP라고 해서 SNI에도 반드시 해당 IP를 입력해야 하는 것은 아닙니다. 서비스 제공업체가 별도로 도메인을 안내했다면 해당 정보를 입력하세요. Allow Insecure를 일반적인 해결책으로 사용하지 마세요.
4. 오류 메시지 원문을 바탕으로 다음 단계 정하기
‘시간 초과’는 정해진 시간 안에 어떤 단계가 완료되지 않았다는 뜻이지, 원인을 바로 알려 주지는 않습니다. 로그에 아래 영문 문구가 표시되면 해당 방향으로 원인을 좁혀 보세요. 구체적인 문구는 프로토콜, 내부 연결 라이브러리, 실패 단계에 따라 달라질 수 있습니다. 전체 문맥을 기록할 때는 인증 정보를 가리고 마지막 단어만 잘라서 남기지 마세요.
오류: i/o timeout
원인 및 해결 방법: 특정 읽기 또는 쓰기 작업이 제한 시간 안에 완료되지 않았습니다. 네트워크 패킷 손실, 필터링, 원격 서버의 응답 없음 등이 원인일 수 있습니다. 같은 노드를 다른 네트워크에서 다시 테스트하고 주소와 포트를 확인하세요. 이 오류 한 줄만으로 비밀번호가 틀렸다고 단정할 수는 없습니다.
오류: connection refused
원인 및 해결 방법: 대상 서버나 중간 장치가 연결을 거부했습니다. 포트에서 서비스가 대기 중이지 않거나 거부 정책이 적용된 경우가 흔합니다. 구독 정보의 Port를 확인하고 서비스 제공업체에 해당 포트의 서비스 상태를 문의하세요. 임의의 포트를 하나씩 시도하지 마세요.
오류: TLS handshake timeout
원인 및 해결 방법: TLS 핸드셰이크가 제한 시간 안에 완료되지 않았습니다. 네트워크 경로, TLS 설정, 서버 응답과 관련된 문제일 수 있습니다. 먼저 SNI, TLS 스위치, 포트를 확인한 뒤 다른 네트워크에서 비교 테스트하세요. 이 오류만으로 인증서가 만료됐다고 판단할 수는 없습니다.
오류: certificate has expired or is not yet valid
원인 및 해결 방법: 인증서 유효 기간 확인에 실패했습니다. 기기 시간 오차나 서버 인증서 문제일 수 있습니다. 먼저 iPhone 시간을 정확하게 맞춘 뒤 다시 시도하세요. 시간이 올바른데도 실패한다면 서비스 제공업체에 인증서 유효 기간을 확인해 달라고 요청하세요.
특정 웹사이트를 열 때만 오류가 발생한다면 프록시 서버까지의 연결과 프록시 서버에서 대상 웹사이트까지의 연결을 구분해야 합니다. 같은 TLS 오류도 서로 다른 연결 단계에서 나타날 수 있습니다. 오류에 표시된 대상 호스트, 포트, 발생 시각을 함께 확인해 대상 웹사이트의 인증서 문제를 노드 자체의 문제로 오해하지 않도록 하세요.
5. iPhone 시스템 시간과 자동 재연결 확인하기
TLS 인증서에는 유효 시작 시각과 만료 시각이 포함되며, 일부 프로토콜의 인증도 시간에 영향을 받습니다. 기기의 시계가 크게 어긋나면 네트워크와 비밀번호가 올바르더라도 연결에 실패할 수 있습니다. 표시 시간대만 바꾼다고 실제 시계가 보정되는 것은 아닙니다. 시스템의 날짜와 시간을 정확하게 맞춘 뒤 새 연결을 다시 수립하세요.
- iPhone에서 ‘설정 → 일반 → 날짜 및 시간’을 열고 ‘자동 설정’을 확인한 다음 현재 날짜, 시간, 시간대가 올바른지 살펴보세요. 기기 관리 설정이나 기타 제한으로 해당 옵션을 변경할 수 없다면 먼저 제한이 적용된 이유를 확인하세요.
- Shadowrocket → Home으로 돌아가 연결을 끈 다음 다시 켜고, 같은 노드와 대상을 사용해 재테스트하세요. 시간을 조정한 뒤 이전 테스트에 남은 값만 확인하지 마세요.
- 연결을 끄자마자 자동으로 다시 켜진다면 Settings → On Demand를 확인하세요. 수동 테스트 결과를 명확하게 확인하려면 잠시 비활성화하고, 테스트 후 평소 설정에 맞게 복구하세요.
- 다른 기존 노드는 정상인데 특정 노드에서만 인증서 유효 기간 오류가 계속되면 실패 시각과 오류 문구를 기록해 서비스 제공업체에 전달하고 서버 시간과 인증서 체인을 확인해 달라고 요청하세요.
On Demand는 조건이 충족될 때 연결을 시작하는 기능이며, 원격 서버의 비밀번호 오류, 만료된 인증서, 연결할 수 없는 포트를 해결하지는 않습니다. 문제 해결 중 잠시 끄는 것은 연결 상태가 자동으로 바뀌어 생기는 혼선을 줄이기 위한 것이며, 평소에도 계속 꺼 두어야 한다는 뜻은 아닙니다.
6. 자주 묻는 질문과 문의 기록
지연 시간 값이 표시되는데도 왜 접속할 수 없나요?
먼저 Connectivity Test에서 어떤 방식을 사용했는지 확인하세요. 그런 다음 Home → Global Routing을 임시로 Proxy로 설정하고 테스트할 노드로 같은 대상에 접속하세요. TCP 연결 수립에 성공해도 프로토콜 인증, TLS, 대상 접속은 실패할 수 있습니다. Proxy에서는 정상이고 Config에서 실패한다면 규칙과 정책을 다시 확인하세요.
모든 노드가 시간 초과되면 앱을 다시 구매해야 하나요?
먼저 연결을 끄고 일반 웹페이지에 접속할 수 있는지 확인한 뒤 Wi-Fi와 셀룰러 네트워크를 전환해 다시 테스트하세요. 앱 구매 상태만으로 회선 상태를 확인할 수는 없습니다. 앱 일회성 구매와 회선 요금제는 별개입니다. 보유한 구독이 유효한지는 서비스 제공업체에 확인해야 합니다.
구독 업데이트에 성공했는데 기존 노드는 왜 계속 실패하나요?
Home에서 업데이트된 항목을 확인하고 테스트할 노드를 직접 선택하세요. 현재 Address, Port, 인증 설정이 최신 정보와 일치하는지 확인하세요. 구독 리소스에 접근할 수 있는 것과 노드 서비스를 사용할 수 있는 것은 별개입니다. 설정을 확인하는 대신 항목을 반복해서 삭제하고 다시 추가하지 마세요.
서비스 제공업체에 문의할 때 어떤 정보를 보내야 하나요?
실패 시각과 시간대, Wi-Fi 또는 셀룰러 네트워크 여부, 프로토콜 유형, 테스트 방식, 연속 3회 결과, 민감한 정보를 가린 오류 문구를 전달하세요. 다른 네트워크에서 사용할 수 있었는지도 설명하세요. 전체 구독 링크, 비밀번호, UUID, 개인 키는 보내지 마세요.
문제 해결이 끝나면 원래 Global Routing과 On Demand 설정을 복구하고 평소 사용하는 웹페이지에 다시 접속해 확인하세요. 변수를 하나씩 바꾸어 안정적으로 재현한 결과가 ‘연결됨’ 화면을 찍은 스크린샷 한 장보다 문제를 찾는 데 더 도움이 됩니다. 기기 시간, 설정, 로컬 네트워크 연결을 모두 확인했는데도 같은 노드가 여러 네트워크에서 계속 실패한다면 기록을 서비스 제공업체에 전달해 원격 서비스를 확인해 달라고 요청하세요.