Shadowrocket 노드 시간 초과·연결 실패 해결: 지연 테스트, 프로토콜 설정, 시스템 시간 점검

이 글의 핵심

Shadowrocket에서 시간 초과가 표시되더라도 모든 연결 설정이 잘못된 것은 아닙니다. 이미 서비스 제공업체와 구독을 이용 중인 경우를 전제로, 기본 네트워크부터 지연 테스트, 프로토콜 항목, 시스템 시간, DNS, 라우팅 규칙 순서로 원인을 확인합니다. 한 번에 하나의 설정만 변경하고 같은 대상으로 다시 테스트하세요. 마지막으로 재현 가능한 증상과 오류 기록을 남겨 두세요.

1. 테스트 시간 초과와 실제 연결 실패 구분하기

먼저 기억할 점은 지연 테스트가 진단을 위한 단서일 뿐, 연결 성공을 보장하지 않는다는 것입니다. TCP 테스트는 지정한 주소와 포트에 TCP 연결이 가능한지 주로 확인하며, 비밀번호나 UUID, 이후의 TLS 핸드셰이크가 올바른지는 확인할 수 없습니다. 프록시를 통해 테스트 URL에 접속하면 프로토콜 협상, 대상 도메인 조회, 대상 사이트의 응답도 영향을 줍니다. 두 테스트는 측정 범위가 다르므로 결과를 서로 바꿔 해석할 수 없습니다.

시스템에 VPN 연결됨으로 표시되어도 시스템 터널이 만들어졌다는 뜻일 뿐, 원격 서버와 DNS, 각 라우팅 규칙이 모두 정상이라는 의미는 아닙니다. ‘테스트 실패’, ‘연결 스위치 켜짐’, ‘실제 웹 페이지 접속 여부’를 구분해 기록하세요. UDP를 사용하는 프로토콜은 TCP 포트 테스트 한 번만으로 유효성을 판단할 수 없습니다.

기본 네트워크 주소 및 포트 프로토콜 핸드셰이크 DNS 조회 대상 응답

테스트만 시간 초과되는 경우: 먼저 테스트 방식과 대상을 기록한 뒤, 정상 작동하는 HTTPS 페이지에 실제로 접속해 보세요. 노드를 바로 삭제하지 마세요.
테스트 결과는 나오지만 접속에 실패하는 경우: 인증, TLS, DNS, 규칙을 추가로 점검하세요. 지연 수치만 보고 설정 확인을 건너뛰면 안 됩니다.
특정 웹사이트 하나만 실패하는 경우: 먼저 대상 사이트와 적용된 정책, 도메인 조회를 확인하세요. 전체 연결이 작동하지 않는다고 단정하지 마세요.

2. 반복 가능한 점검 기준 만들기

점검을 마친 뒤 원래 설정으로 되돌릴 수 있도록 현재 선택한 노드, Global Routing 상태, Config 이름을 먼저 기록하세요. 아래 단계에서는 같은 노드와 같은 테스트 대상을 사용합니다. Wi-Fi와 셀룰러 네트워크를 전환할 때 프로토콜이나 DNS를 동시에 바꾸지 마세요. 셀룰러 네트워크 테스트는 모바일 데이터를 사용할 수 있으므로 요금제에 맞게 진행하세요.

기본 네트워크 확인

먼저 Settings → On Demand의 현재 설정을 기록하고, 점검 중에는 자동 실행을 잠시 끄세요. 그런 다음 Home의 연결 스위치를 끕니다. 정상 작동하는 웹사이트에 접속해 보세요. 공용 Wi-Fi에서 로그인 인증 페이지가 표시되면 먼저 인증을 완료합니다.
테스트 대상 고정

Home으로 돌아가 확인할 노드를 선택하고 지연 테스트 방식과 대상을 기록하세요. 세 번 연속 테스트한 뒤 성공, 시간 초과 또는 구체적인 오류를 각각 기록합니다. 이 테스트는 증상을 재현하기 위한 것이며 장기적인 가동률을 추정하는 데 사용하지 마세요.
네트워크 환경 비교

가능하다면 같은 노드를 Wi-Fi와 셀룰러 네트워크에서 각각 테스트하세요. 한쪽 네트워크에서만 실패한다면 해당 네트워크의 인증, DNS, 전송 제한부터 확인하고 노드 설정을 전부 다시 입력하지 마세요.
실제 요청 확인

연결을 켜고 Home → Global Routing에서 임시로 Proxy를 선택한 뒤 같은 HTTPS 대상에 접속하세요. 이렇게 하면 Config 라우팅의 영향을 줄일 수 있습니다. 테스트가 끝나면 원래 상태로 되돌려 진단 설정이 계속 적용되지 않도록 하세요.

3. 주소, 포트, 프로토콜 항목 차례로 확인하기

Home에서 해당 노드의 편집 화면을 열고, 직접 이용 중인 서비스 제공업체가 전달한 원본 설정과 항목별로 비교하세요. 노드 이름만 보고 프로토콜을 판단하지 마세요. 이름은 예전 정보 그대로일 수 있지만 실제 설정은 달라졌을 수 있습니다. 주소에는 지정된 호스트 이름이나 IP를 입력하세요. 공유 링크 전체, 구독 URL, 경로가 포함된 웹 주소를 서버 주소로 입력하면 안 됩니다.

점검 항목	확인할 내용	흔한 오판
Address / Port	서버 주소와 포트를 원본과 정확히 대조하세요. 포트 범위는 1–65535이며 실제 값은 원본 설정을 따릅니다.	모든 노드의 기본 포트가 443이라고 생각해 원본 설정의 8443을 임의로 443으로 바꾸는 경우.
Shadowsocks	암호화 방식과 비밀번호를 함께 확인하세요. 플러그인이나 추가 전송 설정이 있다면 서버 설정과도 일치해야 합니다.	포트에 연결할 수 있으니 비밀번호도 맞다고 생각하거나 암호화 방식을 임의로 바꾸는 경우.
VMess / VLESS	UUID, 전송 유형, TLS를 확인하고 선택한 전송 방식에 필요한 Host, Path 또는 Service Name도 점검하세요.	UUID만 확인하고 WebSocket 경로나 gRPC 서비스 이름을 놓치는 경우.
Trojan	비밀번호, 서버 주소, 포트, TLS, SNI를 확인하세요. 추가 전송 설정은 원본 구성에 맞춰 입력합니다.	주소를 IP로 바꾸면서 SNI를 지워 인증서 이름이 일치하지 않게 되는 경우.
Hysteria2	인증 정보, TLS, 서버에서 요구하는 난독화 설정을 확인하고 네트워크에서 해당 UDP 통신을 허용하는지도 확인하세요.	TCP 테스트 실패만으로 QUIC 기반 연결을 사용할 수 없다고 판단하는 경우.
WireGuard	로컬 PrivateKey, 상대방 PublicKey, Endpoint, Address, 라우팅 범위를 확인하세요.	두 종류의 키를 혼동하거나 TLS가 없다는 오류를 WireGuard 핸드셰이크가 완료된 것으로 오해하는 경우.

노드가 구독에서 제공된 경우 먼저 최근 구독 업데이트가 성공했는지 확인한 뒤 업데이트된 항목을 비교하세요. 구독 업데이트와 노드 연결은 서로 다른 요청입니다. 구독 업데이트가 성공했다는 것은 설정을 가져왔다는 뜻일 뿐, 그 안의 모든 노드에 연결할 수 있다는 의미는 아닙니다. 직접 설정을 바꾸기 전에 필요한 정보를 저장하세요. 이후 구독을 업데이트하면 변경 사항이 덮어써질 수 있습니다.

요약: 포트 연결 확인 후 핸드셰이크 점검

TCP 테스트에서 결과가 나오는데 실제 프록시 요청은 실패한다면, 포트만 반복해서 바꾸지 말고 인증, TLS, 전송 설정을 확인하세요. UDP 프로토콜은 실제 프로토콜 요청 결과를 기준으로 판단해야 합니다.

4. 오류가 발생한 단계에 따라 범위 좁히기

앱 내 연결 기록을 확인할 때는 오류 앞뒤의 내용을 함께 살펴보세요. 특히 오류가 서버 주소, DNS 조회, 대상 사이트 중 어디와 관련됐는지 확인해야 합니다. 아래는 네트워크 오류에 나타날 수 있는 원문 일부입니다. 대소문자와 전체 문구는 오류가 발생한 위치에 따라 다를 수 있으며, 어느 한 영어 문구도 Shadowrocket에 항상 표시되는 고정 메시지로 간주하면 안 됩니다.

오류: i/o timeout

원인 및 해결: 네트워크 읽기 또는 쓰기 단계가 제한 시간 안에 완료되지 않았다는 뜻입니다. 이 문구만으로는 포트, 핸드셰이크, 대상 응답 중 무엇이 문제인지 알 수 없습니다. 먼저 오류 문맥에서 대상 주소를 확인하고 기본 네트워크, 포트, 프로토콜 설정 순서로 점검하세요.

오류: connection refused

원인 및 해결: 연결 요청이 거부 응답을 받았습니다. 대상 포트에서 대기 중인 서비스가 없거나 중간 장비가 연결을 차단했을 수 있습니다. 먼저 주소와 포트를 확인하고, 해당 서버가 아직 서비스 중인지 이용 중인 서비스 제공업체에 문의하세요. 포트를 무작위로 바꾸는 방식으로 문제를 해결하지 마세요.

오류: no such host

원인 및 해결: 해당 호스트 이름을 조회하지 못한 상태입니다. 주소 오타, 존재하지 않는 레코드, 현재 DNS 조회 경로의 문제일 수 있습니다. 오류에 나온 도메인이 노드 주소인지 대상 사이트인지 먼저 확인한 다음 도메인과 DNS 설정을 점검하세요.

오류: certificate has expired or is not yet valid

원인 및 해결: 인증서 유효기간 확인에 실패했습니다. 기기 시간이나 서버 인증서 문제일 수 있습니다. 먼저 iPhone의 시간을 정확하게 맞추세요. 시간이 맞는데도 실패하면 서버 인증서 상태를 이용 중인 서비스 제공업체에 확인하세요.

인증서 오류를 없애려고 인증서 검증을 끄지 마세요. 주소, SNI, 인증서에 포함된 도메인은 일치해야 합니다. 어떤 설정으로 오류를 우회하더라도 이름이나 인증서 자체의 문제는 해결되지 않습니다.

5. iPhone 시스템 시간 및 TLS 확인

iPhone에서 ‘설정 → 일반 → 날짜 및 시간’을 열어 ‘자동으로 설정’을 확인하세요. 기기 관리 정책 때문에 설정을 바꿀 수 없다면 실제 기기 시간이 정확한지 먼저 확인합니다. 인증서 유효기간은 절대 시간을 기준으로 확인하는 경우가 많습니다. 표시되는 시간대가 다르다는 이유만으로 시스템 시계가 잘못됐다고 단정할 수는 없습니다.

시간이 크게 어긋난 경우: 시간을 정확하게 맞춘 뒤 Shadowrocket 연결을 끊었다가 다시 연결하고 같은 대상을 테스트하세요.
시간은 맞지만 인증서 검증에 실패하는 경우: 노드 편집 화면에서 TLS와 SNI를 확인하세요. 특히 서버 IP를 인증서 도메인으로 잘못 입력하지 않았는지 살펴보세요.
특정 대상에서만 실패하는 경우: 오류가 프록시 서버의 핸드셰이크가 아니라 대상 사이트의 인증서에서 발생한 것은 아닌지 확인하세요. 둘을 혼동하지 마세요.
최근 설정이 변경된 경우: 서비스 제공업체가 현재 제공하는 설정과 비교해 서버 주소나 인증서 관련 요구 사항이 바뀌었는지 확인하세요.

일부 인증 방식도 올바른 시스템 시간에 의존합니다. 시간 확인은 명확한 점검 항목으로 다뤄야 하며, 연결이 실패할 때마다 반복하는 만능 해결책은 아닙니다. 시간을 맞춘 후에도 오류가 그대로라면 같은 작업을 반복하지 말고 다음 단계를 확인하세요.

6. 마지막으로 DNS 및 Config 라우팅 확인

프로토콜 설정과 시간을 모두 확인한 뒤에는 ‘노드 도메인을 조회할 수 없는 경우’와 ‘연결 후 대상 도메인을 조회할 수 없는 경우’를 구분하세요. 첫 번째는 원격 연결 자체를 막을 수 있고, 두 번째는 연결 스위치는 정상인데 일부 웹사이트만 열리지 않는 증상으로 나타날 수 있습니다. IP 주소를 직접 열어 보는 것만으로는 HTTPS를 완전히 확인할 수 없습니다. 인증서 이름과 웹사이트 가상 호스트에서 여전히 도메인을 요구할 수 있기 때문입니다.

Config를 사용 중이라면 현재 선택된 설정을 Config에서 확인한 다음 편집 내용의 [General] 및 dns-server 설정을 살펴보세요. 활성화되지 않은 다른 설정 파일을 수정하고 적용된 것으로 착각하지 마세요. 익숙하지 않은 DNS 주소를 한꺼번에 여러 개 추가하는 것도 피하세요. 기존 값을 저장하고 한 항목만 바꾼 뒤 같은 도메인으로 다시 테스트합니다.

규칙 순서 확인: DOMAIN-SUFFIX는 도메인 접미사를, IP-CIDR는 IP 주소 대역을, GEOIP는 IP의 지리적 위치를 기준으로 합니다. 이 규칙들을 같은 조건으로 취급하면 안 됩니다.
최종 정책 확인: FINAL은 앞선 규칙에 일치하지 않는 트래픽에 적용되는 기본 정책입니다. 설정된 정책이 예상과 다르면 대상 트래픽이 다른 경로로 나갈 수 있습니다.
라우팅 상태 비교: 같은 노드가 Proxy에서는 작동하고 Config에서는 실패한다면, 이미 확인한 인증 항목을 다시 입력하기보다 규칙, 정책 참조, 설정의 DNS를 먼저 살펴보세요.
원래 설정 복원: 비교 테스트가 끝날 때마다 기존 Global Routing과 On Demand 설정을 복원하고 최종적으로 유지한 변경 사항을 기록하세요.

7. 자주 묻는 질문과 점검 결과 정리

지연 테스트에 수치가 나오는데도 웹 페이지가 열리지 않는 이유는 무엇인가요?

먼저 테스트 방식을 확인하세요. TCP 연결이 된다고 인증과 TLS까지 성공한 것은 아닙니다. Home → Global Routing에서 Proxy를 임시로 선택하고 같은 HTTPS 대상에 접속한 뒤 핸드셰이크 오류를 확인하세요. Proxy에서는 연결되지만 Config에서는 안 된다면 현재 Config에서 규칙과 DNS를 점검하세요.

구독 업데이트는 성공했는데 노드가 시간 초과되는 이유는 무엇인가요?

구독 내용을 가져오는 과정과 원격 서버에 연결하는 과정은 별개입니다. 먼저 노드 편집 화면에서 주소, 포트, 프로토콜 설정을 비교한 다음 현재 네트워크에서 같은 방식으로 다시 테스트하세요. ‘업데이트 성공’을 모든 노드가 연결된다는 증거로 보면 안 됩니다.

Wi-Fi에서는 연결되지 않고 셀룰러에서는 되는데 노드를 다시 추가해야 하나요?

노드를 바로 삭제하지 마세요. 노드 설정은 그대로 두고 Wi-Fi 로그인 인증과 DNS를 확인하세요. Hysteria2 또는 WireGuard를 사용한다면 해당 네트워크에서 UDP 통신이 가능한지도 확인해야 합니다. 네트워크 관리자나 서비스 제공업체에 비교 테스트 결과를 전달하면 반복해서 노드를 추가하는 것보다 원인을 찾기 쉽습니다.

서비스 제공업체에 문의할 때 어떤 정보를 보내야 하나요?

오류가 발생한 시간과 시간대, 네트워크 유형, 프로토콜 유형, 테스트 방식, 전체 오류 문구, Proxy와 Config의 비교 결과를 전달하세요. 비밀번호, UUID, PrivateKey, 구독 token은 가리고 보내세요. 검토하지 않은 전체 설정이나 스크린샷은 그대로 전송하지 마세요.

점검을 마친 뒤 ‘변경 전 증상, 변경한 항목 하나, 변경 후 결과’를 기록하세요. 문제가 계속되더라도 마지막으로 재현 가능한 테스트 조건을 남겨 두어야 합니다. 다음 점검을 명확한 단계에서 이어 갈 수 있어 모든 설정을 무작위로 다시 조정하지 않아도 됩니다.