이 글에서는 Shadowrocket에 이미 추가한 연결 항목에서 시간 초과, 핸드셰이크 실패, 연결 후 접속 불가 문제가 발생할 때 점검하는 방법을 설명합니다. 사용 중인 서비스 제공업체와 구독이 있다는 전제하에 기본 네트워크, 테스트 방식, 서버 설정, 시스템 시간, 규칙 라우팅을 순서대로 확인하세요. 한 번에 하나의 설정만 변경하고 마지막에는 같은 대상으로 다시 테스트합니다. 아래 메뉴 안내는 iPhone / iPad 화면을 기준으로 하며, 다른 플랫폼에서는 시스템 권한과 메뉴 위치가 다를 수 있습니다.
1. 시간 초과가 발생한 단계부터 확인하기
Home에서 테스트 시간 초과가 표시돼도 서버가 오프라인이라고 단정할 수는 없습니다. 요청은 보통 시스템 터널, 규칙 일치, 주소 확인, 프록시 연결, 대상 서버의 응답 단계를 거칩니다. 어느 단계에서든 제한 시간 안에 처리가 끝나지 않으면 대기 후 실패할 수 있습니다. 먼저 ‘테스트 실패’인지 ‘실제 웹페이지 접속 실패’인지 기록하고, 모든 설정을 바로 삭제하지 마세요.
같은 기기에서 Shadowrocket 연결을 잠시 끈 뒤 평소 직접 접속할 수 있는 웹사이트를 열어 보세요. 이때도 접속에 실패한다면 먼저 Wi-Fi 인증, 모바일 데이터 권한 또는 네트워크 자체의 문제를 해결해야 합니다. 공용 Wi-Fi의 웹 인증을 마치지 않은 상태라면 연결 항목을 계속 바꿔도 대개 문제가 해결되지 않습니다.
- 모든 연결 항목이 동시에 실패하는 경우: 현재 네트워크, 시스템 시간, 구독 유효 여부와 공통 주소 확인 문제를 먼저 점검하세요.
- 특정 연결 항목 하나만 실패하는 경우: 해당 항목의 주소, 포트, 프로토콜 설정을 확인한 다음 서비스 제공업체에 해당 서비스 상태를 문의하세요.
- 테스트 결과에 수치가 표시되지만 웹사이트가 열리지 않는 경우: Global Routing, 실제로 일치한 동작, DNS, 대상 웹사이트를 추가로 확인하세요. 응답 시간 수치만으로 정상 작동을 판단할 수는 없습니다.
- 앱을 열어 둔 상태에서는 작동하지만 네트워크 전환 후 실패하는 경우: Wi-Fi와 모바일 데이터에서의 차이를 기록하고, Settings → On Demand의 자동 연결 조건이 재테스트에 영향을 주는지 확인하세요.
2. 조건을 고정해 응답 시간과 접속 테스트하기
테스트마다 확인하는 범위가 다릅니다. TCP 연결 테스트는 지정한 주소와 포트에 연결할 수 있는지만 확인하는 경우가 많으며, 인증 정보가 올바른지, TLS 핸드셰이크가 성공하는지, 대상 웹페이지가 열리는지는 보장하지 않습니다. Home의 Connectivity Test 결과도 선택한 테스트 방식과 대상을 함께 고려해야 합니다. 서로 다른 테스트 방식의 수치를 직접 비교하지 마세요.
-
현재 상태 기록하기
현재 연결 항목 이름, 테스트 방식, Global Routing 상태, 실패 시간을 기록하세요. Config에 현재 설정의 사본을 남겨 두고, 결과를 캡처하거나 옮겨 적을 때는 인증 정보와 구독 주소를 가리세요.
-
연결 항목 고정하기
Home에서 기존 연결 항목 하나를 선택해 테스트 중 자동 선택 정책으로 출구가 바뀌지 않도록 하세요. 현재 Wi-Fi와 모바일 데이터 중 어느 네트워크를 사용하는지도 기록합니다.
-
테스트 반복하기
같은 Connectivity Test를 세 번 연속 실행해 성공 여부와 표시된 소요 시간을 각각 기록하세요. 한 번 우연히 성공했다고 해서 문제가 해결된 것으로 보지 마세요.
-
대상에 접속하기
연결 스위치를 켜고 브라우저에서 정상 작동 여부를 알고 있는 같은 HTTPS 페이지를 여세요. ‘테스트 결과가 표시됨’과 ‘페이지가 실제로 열림’을 따로 기록합니다.
-
네트워크 바꾸기
연결 항목과 대상을 그대로 둔 채 Wi-Fi와 모바일 데이터만 바꾸고 위 테스트를 다시 진행하세요. 모바일 데이터 사용 시 요금이 발생할 수 있습니다.
정리: 네트워크와 연결 항목 중 차이가 생긴 쪽 찾기
같은 연결 항목이 특정 네트워크에서만 실패한다면 해당 네트워크의 주소 확인과 전송 제한을 살펴보세요. 네트워크가 달라도 같은 연결 항목만 실패한다면 주소, 포트, 프로토콜 설정을 확인하세요. 모든 설정을 무작위로 바꾸지 마세요.
3. 주소·포트·프로토콜 설정을 항목별로 확인하기
Home에서 해당 연결 항목의 편집 화면을 열고 서비스 제공업체가 안내한 원래 설정과 하나씩 대조하세요. 서버 주소에는 호스트 이름이나 IP를 입력해야 하며, 웹 경로·공백·프로토콜 접두사를 포함하면 안 됩니다. 포트에는 제공업체가 지정한 숫자를 입력하세요. 예를 들어 안내된 포트가 443이라면 흔히 보는 예시가 8443이라는 이유만으로 바꾸지 마세요. 포트 번호만으로 사용 중인 프로토콜을 판단할 수도 없습니다.
| 프로토콜 또는 계층 | 중점 확인 항목 | 놓치기 쉬운 차이 |
|---|---|---|
| Shadowsocks | 주소, 포트, Password, 암호화 방식 | 암호화 방식은 서버 설정과 일치해야 합니다. 비밀번호가 맞더라도 암호화 방식이 다르면 연결되지 않습니다. |
| VMess / VLESS | UUID, 전송 방식, TLS 및 서버에서 지정한 추가 설정 | UUID만 복사해서는 안 됩니다. WebSocket 경로와 Host 등의 항목도 원래 설정에 맞게 입력해야 합니다. |
| Trojan | Password、TLS、Server Name | 연결 주소와 인증서에 지정된 이름이 다를 수 있으므로 서버에서 요구한 이름을 그대로 사용하세요. |
| Hysteria2 | 인증 정보, TLS, 서버에서 지정한 포트와 추가 설정 | UDP 전송을 사용하므로 TCP 포트 테스트 결과로 실제 프로토콜이 작동하는지 판단할 수 없습니다. |
| WireGuard | 키, Peer 공개 키, Endpoint, 터널 주소 및 라우팅 범위 | 핸드셰이크와 데이터 송수신을 확인해야 합니다. 비밀번호 기반 프록시의 설정 항목에 맞춰 점검하지 마세요. |
TLS를 사용하는 연결은 서버 주소, Server Name, HTTP Host를 구분해야 합니다. 모두 도메인처럼 보이더라도 서로 다른 계층의 값이므로 바꿔 쓸 수 없습니다. WebSocket 경로는 대소문자를 구분할 수 있으며, 맨 앞의 슬래시가 빠지거나 공백이 들어가도 연결에 실패할 수 있습니다.
4. 오류 원문으로 범위를 좁힌 뒤 시스템 시간 확인하기
로그에 표시된 오류는 단순히 ‘연결할 수 없음’이라는 설명보다 원인을 찾는 데 유용합니다. 아래는 발생할 수 있는 하위 계층 오류 예시입니다. 대소문자, 접두사, 구체적인 문구는 플랫폼과 연결 단계에 따라 다를 수 있으므로 기기에 실제로 기록된 내용을 기준으로 확인하세요. 문제가 발생했을 때의 오류 원문을 저장하고 모든 오류를 연결 시간 초과로 뭉뚱그리지 마세요.
오류: i/o timeout
원인 및 해결 방법: 특정 네트워크 읽기 또는 쓰기 작업이 제한 시간 안에 끝나지 않았다는 뜻입니다. 이 문구만으로 어느 지점에서 멈췄는지 판단할 수는 없습니다. 앞뒤 로그를 확인해 주소 확인, 연결, 응답 수신 중 어디에서 발생했는지 파악한 뒤 같은 연결 항목으로 네트워크를 바꿔 다시 테스트하세요.
오류: connection refused
원인 및 해결 방법: 연결 요청이 명시적으로 거부된 상태입니다. 해당 포트에서 서비스가 대기 중이지 않거나 기기가 연결을 거부할 때 주로 발생합니다. 주소와 포트를 대조한 뒤 서비스 제공업체에 해당 포트의 서비스 상태를 문의하세요.
오류: TLS handshake timeout
원인 및 해결 방법: TLS 핸드셰이크가 제시간에 완료되지 않았습니다. 전송이 차단되었거나 서버가 응답하지 않는 문제일 수 있습니다. TLS 설정, Server Name, 포트를 확인한 뒤 다른 네트워크에서도 테스트해 네트워크 경로 문제인지 살펴보세요.
오류: certificate has expired or is not yet valid
원인 및 해결 방법: 인증서의 유효 기간과 현재 시스템 시간이 일치하지 않습니다. 먼저 기기 시간을 맞추고, 그래도 문제가 계속되면 서버 관리자가 인증서 유효 기간을 확인해야 합니다.
iPhone / iPad에서는 시스템 설정 → 일반 → 날짜 및 시간에서 ‘자동으로 설정’을 확인하고 날짜, 시간대, 현재 시간이 맞는지 살펴보세요. Windows, Mac, Android, Linux는 각 운영체제의 날짜 및 시간 설정에서 시간을 동기화하면 됩니다. 시간을 바로잡은 뒤 연결을 다시 설정하고 같은 오류가 발생하는지 확인하세요.
- 시간이 맞지 않으면 TLS 인증서의 유효 시간 확인이나 시간 범위에 의존하는 프로토콜 인증에 영향을 줄 수 있습니다.
- 시스템 시간이 정확해도 인증서가 정상이라는 뜻은 아닙니다. 만료된 인증서, 이름 불일치, 인증서 체인 문제는 각각 따로 확인해야 합니다.
- 특정 대상 웹사이트에서만 인증서 문제가 발생한다면 프록시 핸드셰이크 실패인지 대상 웹사이트 자체의 인증서 오류인지 먼저 구분하세요.
5. 연결 후 라우팅, DNS, 구독 상태 확인하기
연결 스위치가 켜져 있다는 것은 시스템 터널이 작동 중이라는 뜻일 뿐, 모든 요청이 선택한 프록시를 거친다는 의미는 아닙니다. Home → Global Routing에서 현재 모드를 확인하세요. Proxy는 전체 프록시 경로, Direct는 직접 연결, Config는 현재 설정에 따른 규칙 분기, Scene은 시나리오 설정에 따른 작동을 뜻합니다. 문제를 확인하는 동안에는 Proxy로 잠시 바꿔 같은 대상에 다시 접속해 보세요. 테스트가 끝나면 원래 모드로 복구합니다.
- Proxy에서는 작동하지만 Config에서는 실패하는 경우: Config의 규칙 순서와 실제로 일치한 결과를 확인하세요.
DOMAIN-SUFFIX는 도메인 접미사,IP-CIDR은 주소 범위,GEOIP는 IP 주소의 지역을 기준으로 일치시킵니다.FINAL은 앞선 규칙에 일치하지 않은 연결을 처리합니다. - DIRECT에 일치한 경우: 요청이 예상한 대로 프록시를 통과하지 않은 상태입니다. 연결 항목의 비밀번호를 바꾸기보다 앞에서 먼저 일치한 규칙이 있는지 확인하세요.
- REJECT에 일치한 경우: 규칙이 요청을 차단한 것입니다. 규칙의 목적과 적용 범위를 먼저 확인하고 서버가 응답하지 않는 문제로 오해하지 마세요.
- 로그에 주소 확인 실패가 표시되는 경우: 설정의 DNS 항목, 서버 도메인 철자, 현재 네트워크에서의 주소 확인 가능 여부를 점검하세요. TLS 이름이 맞지 않거나 잘못된 주소에 연결될 수 있으므로 서버 도메인을 임의로 IP로 바꾸지 마세요.
구독 업데이트는 별도의 요청 경로를 사용합니다. 업데이트 성공은 이번에 구독 내용을 다운로드하고 해석할 수 있었다는 뜻일 뿐, 모든 연결 항목이 작동한다는 보장은 아닙니다. 이미 추가한 항목으로 연결할 수 있어도 구독 링크가 여전히 유효하다는 뜻은 아닙니다. 서비스 제공업체가 설정을 변경했다면 Home에서 해당 구독을 업데이트한 뒤 연결 항목이 실제로 바뀌었는지 확인하세요.
정리: 구독 업데이트 실패와 연결 실패를 따로 기록하기
‘구독 업데이트 결과, 선택한 연결 항목, Global Routing 모드, 실제 접속 결과’를 각각 기록하세요. 업데이트 경로에 문제가 있고 이미 작동하는 프록시가 있는 경우에만 Settings → Subscribe에서 Update via Proxy를 확인하세요. 연결되지 않는 프록시는 업데이트 요청에 사용할 수 없습니다.
자동 연결이 테스트에 영향을 주지 않도록 재테스트 전에 Settings → On Demand의 현재 상태를 기록하세요. 필요한 경우 잠시 끄고 수동으로 연결합니다. 테스트가 끝나면 설정을 복구하고, 문제 해결을 위해 임시로 바꾼 모드를 일상 설정으로 계속 사용하지 마세요.
6. 자주 묻는 질문과 문제 정보 전달하기
응답 시간이 수십 밀리초로 나오는데 웹페이지가 열리지 않는 이유는 무엇인가요?
먼저 어떤 테스트 결과인지 확인하세요. TCP 연결이 빠르다고 해서 프로토콜 인증과 대상 사이트 접속까지 성공한 것은 아닙니다. Home에서 선택한 연결 항목과 Global Routing을 확인하고 같은 HTTPS 페이지에 접속하세요. 실패 당시 로그를 바탕으로 핸드셰이크 오류와 규칙 분기 문제를 구분할 수 있습니다.
Wi-Fi에서는 시간 초과가 발생하고 모바일 데이터에서는 정상입니다. 다시 가져와야 하나요?
구독을 바로 삭제하지 마세요. 같은 연결 항목과 프로토콜 설정을 유지한 상태에서 Wi-Fi 인증이 완료됐는지, 주소 확인이 성공했는지 점검하세요. Hysteria2 또는 WireGuard를 사용하는 경우 해당 네트워크의 UDP 제한도 확인해야 합니다. 네트워크 차이는 서비스 제공업체나 네트워크 관리자에게 문의하세요.
구독을 업데이트한 뒤에도 연결 항목 하나가 시간 초과되면 어떻게 해야 하나요?
해당 연결 항목의 설정이 실제로 업데이트됐는지 확인한 다음 원래 설정과 대조해 주소, 포트, 인증 항목을 점검하세요. 같은 네트워크에서 다른 연결 항목은 작동한다면 민감 정보를 가린 항목 이름, 실패 시간, 오류 원문을 서비스 제공업체에 전달해 해당 서비스를 확인해 달라고 요청하세요.
설정 전체를 다른 사람에게 보내 점검을 받아야 하나요?
대개 운영체제, 사용 중인 프로토콜, 네트워크 유형, Global Routing 상태, 테스트 방식, 민감 정보를 가린 오류 내용만 전달하면 됩니다. 구독 전체 URL, Password, UUID, 개인 키, 인증 정보가 포함된 QR 코드를 공개하지 마세요. 로그를 공유하기 전에는 도메인과 개인 정보가 포함되어 있는지 확인하세요.
점검을 마친 뒤에는 원래 사용하던 네트워크, 연결 항목, 대상으로 다시 테스트하고 문제 해결을 위해 임시로 변경한 설정을 복구하세요. 원인을 계속 찾기 어렵다면 단순히 시간 초과 화면을 보내는 대신 ‘어떤 네트워크에서, 어떤 민감 정보를 가린 항목을 선택했고, 어떤 모드로 연결했으며, 어떤 오류 원문이 표시됐는지’를 단계별로 기록하세요.