서비스 제공업체와 구독 정보를 이미 보유하고 있지만 Shadowrocket에서 노드 시간 초과가 발생하거나 연결 후 웹사이트에 접속할 수 없는 경우를 위한 안내입니다. 테스트 실패, 프로토콜 핸드셰이크 실패, 규칙에 따른 경로 문제를 구분한 뒤 기존 연결 정보와 기기 시간을 확인합니다. 매번 한 가지 조건만 변경하고 결과를 기록하면 문제가 로컬 네트워크, 원격 서버, 앱 설정 중 어디에서 발생하는지 파악하기 쉽습니다.
1. 연결 스위치, 노드 테스트, 웹 접속을 구분하기
Shadowrocket의 연결 스위치를 켜면 시스템 VPN 터널이 설정되지만, 원격 노드 인증까지 완료됐다는 뜻은 아니며 모든 웹사이트에 접속할 수 있다는 보장도 없습니다. 노드 옆에 지연 시간이 표시되더라도 해당 테스트가 지정된 조건에서 완료됐다는 의미일 뿐, 모든 대상과 전송 방식이 정상이라고 판단할 수는 없습니다.
Home에서 현재 선택된 노드, Global Routing 상태, 사용 중인 네트워크를 기록합니다. 문제를 확인하는 동안 Settings → On Demand로 이동해 On Demand를 잠시 끄면 네트워크 전환에 따라 자동 연결 동작이 바뀌는 것을 방지할 수 있습니다. 테스트가 끝나면 원래 설정으로 되돌립니다. 노드 교체, 설정 업데이트, DNS 변경을 한꺼번에 진행하면 접속이 복구되더라도 어떤 변경이 효과가 있었는지 알기 어렵습니다.
- 로컬 네트워크 확인: 연결 스위치를 잠시 끄고 현재 Wi-Fi 또는 셀룰러 네트워크로 정상적으로 인터넷에 접속할 수 있는지 확인합니다. 공용 Wi-Fi에 로그인 페이지가 표시되면 먼저 인증을 완료합니다.
- 테스트 조건 기록: 네트워크 유형, 노드 이름, 테스트 방식, 성공 여부 또는 시간 초과 여부, 오류 원문을 적어 둡니다. 기록을 공유하기 전에는 서버 주소, 계정 정보, 인증 정보를 가립니다.
- 문제가 발생하는 범위 확인: 보유한 노드 전체에서 실패하는지, 특정 노드만 실패하는지, 특정 웹사이트만 열리지 않는지 확인합니다. 각 경우에 따라 중점적으로 살펴볼 항목이 다릅니다.
2. 지연 시간 테스트를 실행하고 결과의 의미 파악하기
Home에서 Connectivity Test를 실행해 기존 노드를 확인하고, 사용한 테스트 방식도 기록합니다. 테스트 방식에 따라 확인하는 단계가 다릅니다. TCP 연결 성공은 지정된 서버 주소가 TCP 연결을 받아들였다는 뜻일 뿐입니다. 프록시를 통해 테스트 주소에 요청하는 방식은 인증, 프록시의 외부 연결, DNS, 테스트 대상 자체까지 확인합니다. 두 결과를 같은 지표로 간주해서는 안 됩니다.
-
조건 고정
Home에서 기존 노드 하나를 선택하고 네트워크와 테스트 방식을 그대로 유지한 채 세 번 연속 테스트합니다. 매번 결과를 기록하고, 한 번 측정된 최저 지연 시간만으로 안정성을 판단하지 않습니다.
-
모드 확인
Home → Global Routing으로 이동해 현재 상태를 확인합니다. 프록시 경로를 점검할 때는 Proxy를 임시로 선택하고 올바른 노드가 선택됐는지 확인합니다. 기존 Config, Direct 또는 Scene 상태를 기록하고 테스트 후 복원합니다.
-
접속 확인
연결 스위치를 켜고 평소 사용하는 HTTPS 페이지 중 상태를 확인할 수 있는 두 곳에 접속합니다. 테스트 주소만으로 판단하지 마세요. 테스트 대상 하나에 문제가 생겨도 테스트 시간 초과로 나타날 수 있습니다.
-
네트워크 전환
노드와 설정은 그대로 둔 채 Wi-Fi와 셀룰러 네트워크를 바꿔 같은 테스트를 다시 실행합니다. 셀룰러 데이터 사용 권한과 현재 네트워크에서 필요한 전송 방식이 허용되는지도 확인합니다.
| 확인된 결과 | 결과로 알 수 있는 점 | 다음 단계 |
|---|---|---|
| 같은 노드에서 세 번 모두 시간 초과 | 현재 테스트 조건에서 제한 시간 안에 완료되지 않았다는 뜻이며, 인증 정보 오류라고 단정할 수는 없습니다. | 네트워크를 바꿔 다시 테스트한 뒤 주소, 포트, 전송 유형을 확인합니다. |
| TCP 테스트는 성공하지만 프록시 요청은 실패 | 서버 주소에 연결할 수 있더라도 인증, TLS 또는 후속 요청 단계에서 실패할 수 있습니다. | 프로토콜 설정과 오류 기록을 항목별로 확인합니다. |
| Wi-Fi에서는 실패하고 셀룰러 네트워크에서는 성공 | 네트워크 경로, 주소 확인 또는 네트워크 제한과 관련됐을 가능성이 높습니다. | Wi-Fi 인증, DNS, UDP 사용 가능 여부를 확인합니다. |
| Proxy에서는 접속되지만 Config에서는 접속되지 않음 | 규칙, 정책 선택, DNS 경로를 우선 확인합니다. | Config에서 현재 활성화된 설정과 일치한 규칙을 확인합니다. |
요약: 비교 테스트 결과로 문제 범위 좁히기
같은 노드가 특정 네트워크에서만 실패한다면 프로토콜 설정은 그대로 두고 해당 네트워크 경로부터 확인합니다. 두 네트워크에서 모두 실패한다면 주소, 포트, 핸드셰이크 설정을 점검합니다. 올바른 설정을 반복해서 바꾸지 않도록 주의하세요.
3. 주소, 포트, 인증, 전송 순서로 확인하기
Home에서 해당 노드의 편집 화면을 열고 사용자가 보유한 원본 연결 정보와 항목별로 대조합니다. 서버 주소에 프로토콜 접두사, 경로, 끝의 공백이 섞이지 않았는지 확인합니다. Port는 원격 서버에서 실제로 수신 대기 중인 포트와 일치해야 합니다. 예를 들어 원본 정보에 443이라고 적혀 있다면 연결 실패만을 이유로 임의로 8443으로 바꾸면 안 됩니다. 포트 번호가 같아도 TCP와 UDP가 모두 사용 가능한 것은 아닙니다.
구독 업데이트와 노드 연결은 서로 다른 요청 경로를 사용합니다. 구독 업데이트 성공은 설정 정보를 가져왔다는 뜻일 뿐이며, 노드가 작동한다고 해서 구독 주소에도 현재 접속할 수 있다는 뜻은 아닙니다. 서비스 제공업체가 연결 설정 변경을 명확히 안내했다면 기존 구독을 먼저 업데이트한 뒤 선택된 항목을 다시 확인합니다. 이전 주소로 계속 테스트하지 않도록 주의하세요. 수동 편집 전에 기존 값을 기록해 두세요. 이후 구독을 업데이트하면 항목에 적용한 변경 사항이 덮어써질 수 있습니다.
| 프로토콜 | 우선 확인할 항목 | 자주 하는 오해 |
|---|---|---|
| Shadowsocks | 주소, 포트, 암호화 방식, 비밀번호, 원본 정보에 지정된 플러그인 설정 | 포트에 연결된다고 암호화 방식과 비밀번호까지 일치하는 것은 아닙니다. |
| VMess | UUID, 암호화 설정, 전송 방식, TLS, 기기 시간 | UUID만 확인하고 전송 설정이나 시간 오차를 놓치는 경우 |
| VLESS | UUID, 전송 방식, TLS, 원본 정보에 지정된 flow 등의 설정 | 같은 주소에 설정된 다른 전송 방식을 그대로 적용하는 경우 |
| Trojan | 비밀번호, TLS, 서버 이름, 포트 | 연결 주소와 TLS 서버 이름이 반드시 같다고 여기는 경우 |
| Hysteria2 | 인증 정보, TLS, UDP 경로, 원본 정보에 지정된 난독화 설정 | TCP 테스트 성공을 QUIC 기반 연결이 정상이라는 근거로 삼는 경우 |
| WireGuard | 로컬 개인 키, 피어 공개 키, Endpoint, 터널 주소, Allowed IPs | 스위치 상태만 확인하고 유효한 핸드셰이크와 트래픽은 확인하지 않는 경우 |
TLS를 사용하는 연결은 서버 이름도 확인해야 합니다. WebSocket 연결은 Host와 Path도 점검합니다. Path의 대소문자와 슬래시가 라우팅에 영향을 줄 수 있으므로 익숙한 형태로 임의 변경하지 마세요. 프로토콜마다 설정을 서로 바꿔 쓸 수 없습니다. 특정 항목을 입력해야 하는지는 보유한 원본 연결 정보를 기준으로 판단하고, 오류를 없애기 위해 인증서 확인을 끄지 마세요.
4. 오류 메시지로 실패 단계 파악하기
오류 기록은 단순히 “연결할 수 없음”이라고 할 때보다 문제를 파악하는 데 도움이 됩니다. 아래는 연결 과정에서 나타날 수 있는 대표적인 영문 오류입니다. 실제 메시지에는 주소, 프로토콜 접두사 또는 자세한 상황 설명이 함께 표시될 수 있습니다. 오류 전후의 단계 정보도 보존하고, 키워드 하나만으로 원격 서버 상태를 단정하지 마세요.
오류: i/o timeout
원인: 연결, 읽기, 핸드셰이크 등의 작업이 제한 시간 안에 완료되지 않았다는 뜻이며, 비밀번호 오류를 직접 의미하지는 않습니다.
해결 방법: 같은 노드로 네트워크를 바꿔 다시 테스트한 뒤 주소, 포트, TCP 또는 UDP 전송 조건을 확인합니다.
오류: connection refused
원인: 연결 요청이 거부됐습니다. 대상 포트에서 서비스가 대기 중이지 않거나 중간 장비가 연결을 적극적으로 차단했을 수 있습니다.
해결 방법: 원본 정보에 기재된 포트가 변경되지 않았는지 확인합니다. 같은 문제가 계속되면 민감 정보를 가린 발생 시각과 오류 메시지를 서비스 제공업체에 보내 서버 연결 상태를 문의합니다.
오류: no such host
원인: 도메인 이름을 확인할 수 있는 결과를 얻지 못했습니다. 주소 오타, DNS 서비스 또는 도메인 자체에 문제가 있을 수 있습니다.
해결 방법: 먼저 노드 주소의 철자와 공백을 확인한 다음 네트워크를 바꿔 DNS 결과를 비교합니다. TLS 서버 이름을 임의로 바꾸지 마세요.
오류: x509: certificate has expired or is not yet valid
원인: 인증서 유효 기간이 현재 확인 시각과 일치하지 않습니다. 기기 시간이 잘못됐거나 원격 인증서가 실제로 만료됐을 수 있습니다.
해결 방법: 먼저 시스템 시간을 정확하게 맞춥니다. 시간이 올바른데도 같은 오류가 계속되면 인증서를 건너뛰지 말고 서비스 제공업체에 확인을 요청합니다.
5. 인증 및 인증서 오류를 방지하도록 시스템 시간과 시간대 확인하기
기기 시간은 TLS 인증서의 유효 기간 확인과 VMess 등 프로토콜의 시간 기반 인증에 사용됩니다. 상태 막대의 시각만 확인해서는 안 됩니다. 날짜, 연도 또는 절대 시간이 잘못돼도 핸드셰이크가 실패할 수 있습니다. 시간대는 주로 현지 시각 표시에 영향을 줍니다. 표시된 시간대가 다르다는 이유만으로 기기의 절대 시간이 잘못됐다고 볼 수는 없습니다.
- iPhone 또는 iPad에서 설정 → 일반 → 날짜 및 시간으로 이동해 ‘자동으로 설정’을 확인합니다. 해당 옵션을 사용할 수 있다면 켠 뒤 시스템이 시간을 동기화할 때까지 기다립니다.
- 표시된 날짜, 연도, 시간대를 확인하고 현재 네트워크를 사용할 수 있는지 점검합니다. 인증서 오류를 우회하려고 날짜를 수동으로 변경하지 마세요.
- Shadowrocket으로 돌아가 연결 스위치를 끈 다음 다시 연결합니다. 다른 설정은 바꾸지 말고 같은 노드에서 Connectivity Test를 실행합니다.
- 자동 설정을 변경할 수 없다면 기기 관리 제한이 있는지 확인합니다. 시간이 정확한데도 인증서 오류가 계속되면 오류 내용을 기록해 서비스 제공업체에 원격 인증서를 확인해 달라고 요청합니다.
6. 테스트는 통과했지만 웹페이지가 열리지 않는다면 Global Routing과 Config 확인하기
Global Routing에서 Direct는 요청을 직접 연결 경로로 처리하고, Proxy는 프록시 경로로 처리합니다. Config는 현재 설정된 규칙에 따라 처리 방식을 결정하며, Scene은 설정된 시나리오에 따라 요청을 처리합니다. 노드 테스트와 실제 앱의 요청이 같은 경로를 거치는 것은 아닙니다. 따라서 “지연 시간은 정상인데 웹페이지가 열리지 않는” 경우에는 라우팅과 대상을 확인해야 하며, 노드를 바로 다시 만들 필요는 없습니다.
- 먼저 모드 비교: Proxy를 임시로 선택해 같은 웹페이지에 접속한 뒤 원래 모드로 되돌립니다. Config에서만 실패한다면 비활성 파일이 아니라 현재 활성화된 Config를 확인합니다.
- 다음으로 규칙 순서 확인: 규칙은 보통 순서대로 일치 여부를 확인합니다.
DOMAIN-SUFFIX는 도메인 접미사로,IP-CIDR은 IP 주소 대역으로,GEOIP는 IP 주소의 위치 정보 데이터베이스를 기준으로 일치 여부를 판단합니다.FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. - DNS 관련 단서 확인: 서버 연결은 정상인데 도메인 요청이 실패한다면 현재 설정의 DNS 항목과 오류 기록을 확인합니다. HTTPS 페이지를 IP 주소로 접속해 도메인 테스트를 대신하지 마세요. 인증서나 가상 호스트에서 원래 도메인이 필요할 수 있습니다.
- 특정 대상만 실패하는지 확인: 다른 자주 사용하는 페이지는 정상인데 특정 대상만 실패하면 해당 대상과 발생 시각을 기록합니다. 대상 자체, DNS 확인 또는 관련 규칙에 문제가 있는지 살펴봅니다.
예를 들어 설정 끝부분이 FINAL,DIRECT라면 앞선 규칙에서 프록시 정책과 일치하지 않은 요청은 Direct로 처리됩니다. 이는 설정에 따른 동작이지 노드 시간 초과의 증거가 아닙니다. 변경 전에 현재 설정을 백업하고 대상에 적용해야 할 정책을 확인한 뒤 해당 규칙만 조정합니다. 일반적인 문제 해결 방법으로 전체 규칙을 지우지 마세요.
7. 자주 묻는 질문 및 문의 시 전달할 정보
지연 시간 숫자는 표시되는데 연결 후 웹페이지가 열리지 않는 이유는 무엇인가요?
먼저 Connectivity Test의 테스트 방식을 확인한 다음 Home → Global Routing에서 Proxy를 임시로 선택해 같은 웹페이지에 접속합니다. 서버 주소에 연결할 수 있다는 사실만으로 인증, DNS, 규칙, 대상 접속이 모두 정상이라고 볼 수는 없습니다.
모든 노드에서 시간 초과가 발생하면 하나씩 다시 추가해야 하나요?
먼저 연결을 끄고 로컬 네트워크가 정상인지 확인합니다. 그런 다음 기존 노드 하나를 그대로 둔 채 Wi-Fi와 셀룰러 네트워크를 바꿔 다시 테스트합니다. 모든 항목을 한꺼번에 다시 추가하기보다 공통 네트워크 경로, DNS, 시간 문제를 먼저 확인하는 편이 좋습니다.
Hysteria2만 실패하고 TCP 테스트는 성공하는 이유가 무엇인가요?
Hysteria2는 QUIC 기반이며 UDP를 사용합니다. 먼저 원본 정보에 기재된 포트와 인증 정보를 확인한 뒤 네트워크를 바꿔 테스트합니다. TCP 포트 테스트만으로 UDP 사용 가능 여부나 전체 프로토콜 핸드셰이크를 확인할 수는 없습니다.
구독 업데이트는 성공했는데 기존 노드가 계속 실패하는 이유가 무엇인가요?
업데이트 성공은 구독 내용을 가져왔다는 뜻일 뿐입니다. Home으로 돌아가 현재 선택된 항목이 이전 노드인지 확인하고, 최신 정보의 주소, 포트, 프로토콜을 대조합니다. 구독 요청 성공을 노드 상태 확인으로 간주하지 마세요.
서비스 제공업체에 어떤 정보를 전달해야 하나요?
실패 시각과 시간대, Wi-Fi 또는 셀룰러 네트워크 여부, 프로토콜 유형, 테스트 방식, 세 차례의 테스트 결과, 민감 정보를 가린 오류 메시지를 전달합니다. 전체 구독 링크, 비밀번호, UUID, 개인 키 또는 인증 정보가 포함된 스크린샷은 보내지 마세요.
문제 해결이 끝나면 Global Routing과 On Demand를 원래 설정으로 되돌린 뒤 자주 사용하는 앱에서 접속을 확인합니다. 변경 전 조건, 변경한 항목 하나, 변경 후 결과를 기록해 두세요. 같은 문제가 다시 발생하면 설정 전체를 반복해서 바꾸지 않고 이미 효과를 확인한 점검 순서를 활용할 수 있습니다.