자신의 서비스 제공업체, 서버 정보 또는 구독을 이미 보유한 사용자를 위한 안내입니다. 테스트 시간 초과와 실제 요청 실패를 구분한 뒤 네트워크, 프로토콜 설정, 시스템 시간, 라우팅 설정을 순서대로 확인하세요. 한 번에 한 항목만 변경하고 기존 값은 기록해 두어야 되돌릴 수 있는 문제로 설정이 뒤엉키는 일을 막을 수 있습니다. Shadowrocket의 연결 스위치 상태, 테스트 결과, 웹페이지 접속 여부는 각각 따로 확인해야 합니다.
1. 먼저 지연 테스트로 실패 단계 확인하기
timeout은 작업이 제한 시간 안에 완료되지 않았다는 뜻일 뿐, 비밀번호 오류나 서버 중단, 클라이언트 이상을 바로 의미하지는 않습니다. Home의 Connectivity Test에서 진단을 시작할 수 있습니다. 테스트 방식에 따라 확인하는 단계가 다르므로 현재 테스트 방식을 기록하고 같은 항목끼리 비교하세요. 서로 다른 테스트 방식의 수치를 함께 비교하지 마세요.
포트 연결에 성공했다고 해서 프록시 인증까지 완료되었거나 대상 웹페이지에서 콘텐츠를 받아올 수 있다는 뜻은 아닙니다. 반대로 특정 테스트가 실패해도 실제 요청이 모두 실패한다고 단정할 수 없습니다. 먼저 연결 스위치를 끈 상태에서 현재 Wi-Fi 또는 셀룰러 네트워크로 정상 접속할 수 있는지 확인하세요. 그런 다음 기존 항목을 선택해 테스트하고, 마지막으로 연결을 켜 평소 접속 가능한 대상 페이지를 열어 보세요.
-
현재 상태 기록
Home에서 선택한 항목, Global Routing의 현재 옵션, Connectivity Test 방식, 실패 메시지를 기록하세요. 서버 로그와 대조할 수 있도록 테스트 시간도 남겨 두세요.
-
네트워크 연결 확인
Home의 연결 스위치를 끄고 로컬 네트워크에 로그인 인증이 필요한지 확인하세요. 기본 네트워크 연결이 복구되기 전에는 서버 프로토콜 설정을 변경하지 마세요.
-
테스트 반복
같은 항목과 테스트 방식을 유지한 채 세 번 연속 테스트하세요. 성공, timeout 또는 다른 오류를 각각 기록해 계속 실패하는지 간헐적으로 실패하는지 확인하세요.
-
네트워크 전환
가능하면 Wi-Fi와 셀룰러 네트워크에서 각각 다시 테스트하세요. 네트워크만 전환하고 항목, 프로토콜, Global Routing은 동시에 변경하지 마세요.
-
요청 확인
Home의 연결 스위치를 켠 뒤 같은 대상 페이지에 접속하세요. “테스트는 실패했지만 페이지는 열림”과 “테스트와 페이지 모두 실패”를 구분해 기록한 다음 설정을 점검하세요.
2. 서버 주소·포트·프로토콜 설정 확인
Home에서 해당 항목의 편집 화면을 열고 먼저 Type이 기존 원본 설정과 일치하는지 확인한 다음 주소, 포트, 인증 정보를 점검하세요. 연결 실패를 이유로 VLESS를 VMess로 바꾸거나 Hysteria2를 Trojan으로 바꾸지 마세요. 클라이언트 설정은 서버 설정과 일치해야 합니다.
| 점검 항목 | 확인할 내용 | 자주 하는 오해 |
|---|---|---|
| 주소와 포트 | 도메인 철자, IP 주소, 포트 번호 | 포트 443은 예시일 뿐이며, 포트 번호만으로 프로토콜·TLS·인증 설정이 올바르다고 볼 수 없습니다. |
| Shadowsocks | 서버에서 지정한 암호화 방식과 비밀번호 | 비밀번호만 확인해서는 부족합니다. 암호화 방식도 일치해야 합니다. |
| VMess / VLESS | UUID, 전송 방식, 설정에 필요한 TLS·Host·Path 등의 항목 | UUID가 맞더라도 전송 경로나 핸드셰이크 설정이 잘못되면 연결되지 않습니다. |
| Trojan | 비밀번호, TLS 설정, 서버 이름 | 연결 주소와 인증서에서 검증하는 이름은 다를 수 있으므로 원본 설정을 기준으로 확인하세요. |
| Hysteria2 | 인증 정보, TLS 설정, UDP 경로 연결 여부 | TCP 포트 확인만으로 UDP 기반 프로토콜을 검증할 수는 없습니다. |
| WireGuard | 키, Endpoint, 포트, 주소 및 라우팅 설정 | TCP 핸드셰이크 결과만으로 WireGuard의 UDP 터널 상태를 판단하지 마세요. |
항목을 복사할 때 앞뒤 공백, 빠진 문자, 전각 문장 부호가 없는지 확인하세요. 원본 설정에서 포트가 8443으로 지정되어 있다면 “고치려고” 임의로 443으로 바꾸지 마세요. 서버가 새 포트에서 같은 서비스를 제공하지 않는다면 설정 불일치만 하나 더 생깁니다. TLS 관련 오류를 인증서 검증을 끄는 방법으로 덮지 말고 서버 이름, 시간, 인증서 설정을 계속 확인하세요.
결론: 실패 단계에 따라 다음 점검 항목 선택
특정 항목만 계속 실패한다면 해당 항목의 원본 설정을 먼저 확인하세요. 같은 항목들이 특정 네트워크에서만 실패한다면 그 네트워크의 접속 조건부터 점검하세요. 두 경우 모두 규칙을 바로 다시 작성하지 마세요.
3. 오류 메시지에 따라 점검 방향 정하기
테스트 목록에는 간단한 상태만 표시될 수 있으며, 자세한 오류는 연결 기록이나 본인 서버의 로그에 남을 수 있습니다. 아래는 네트워크 진단에서 흔히 볼 수 있는 원문 오류이며, Shadowrocket의 같은 위치에 항상 표시되는 것은 아닙니다. 실제로 확인한 전체 메시지를 기록하고 모든 실패를 “노드 시간 초과”로 뭉뚱그리지 마세요.
오류: timeout
원인 및 해결 방법: 이번 요청이 제한 시간 안에 완료되지 않았다는 뜻입니다. 이 메시지만으로는 실패 단계를 특정할 수 없습니다. 같은 항목을 다시 테스트하고 다른 로컬 네트워크에서도 비교한 뒤 주소, 포트, 프로토콜 요구 사항을 확인하세요.
오류: connection refused
원인 및 해결 방법: 대개 대상 포트에서 연결을 거부했다는 뜻입니다. 서비스가 포트에서 대기 중이 아니거나 접속이 거부되었을 수 있습니다. 포트가 원본 설정과 일치하는지 확인한 뒤 본인의 서비스 제공업체나 서버 관리자에게 서비스 상태를 문의하세요.
오류: no such host
원인 및 해결 방법: 대상 이름을 확인할 수 없다는 뜻입니다. 서버 도메인 철자와 로컬 네트워크 연결 상태부터 확인하세요. 직접 관리하는 도메인이라면 해당 DNS 레코드가 있는지도 확인하세요.
오류: TLS handshake timeout
원인 및 해결 방법: 제한 시간 안에 TLS 핸드셰이크가 완료되지 않았습니다. TLS 설정이 서버 요구 사항과 일치하는지, 서버 이름이 올바른지 확인하고 네트워크 경로도 비교하세요. 비밀번호 문제라고 바로 단정하지 마세요.
본인의 서비스 제공업체에 문의할 때는 시간과 시간대, 네트워크 종류, 프로토콜, 테스트 방식, 오류 원문, 문제가 계속되는지 간헐적인지만 전달하면 됩니다. 비밀번호, UUID, 개인 키, 전체 구독 주소는 민감 정보이므로 공개 스크린샷이나 기록에 포함하지 마세요.
4. 시스템 날짜·시간대와 자동 연결 확인
시스템 시간이 맞지 않으면 인증서 유효 기간 확인이나 일부 프로토콜의 인증 과정에 영향을 줄 수 있지만 모든 timeout의 원인은 아닙니다. iPhone 또는 iPad의 시스템 Settings → General → Date & Time에서 Set Automatically를 확인하세요. 기기가 관리 대상이라면 해당 옵션이 제한될 수 있으므로 기기 관리 정책에 따라 처리하세요.
- 먼저 실제 날짜와 시간 확인: 연도, 날짜, 시, 분이 크게 어긋나지 않았는지 확인하세요. 상태 막대의 시각만 확인해서는 충분하지 않습니다.
- 다음으로 시간대 확인: 시간대는 현지 시각 표시와 로그 대조에 영향을 줍니다. 표시된 시간대가 다르다고 해서 기기의 절대 시간이 잘못된 것은 아닙니다. 로그를 전달할 때 시간대도 함께 적으세요.
- 시간을 바로잡은 뒤 다시 연결: 시간을 수정한 다음 Home의 연결 스위치를 껐다가 다시 켜고 같은 방식으로 재테스트하세요. 수정 전 결과를 기준으로 계속 판단하지 마세요.
- 자동 연결 변수 통제: 수동으로 연결을 끊은 뒤에도 연결 시도가 다시 발생한다면 Shadowrocket의 Settings → On Demand에서 현재 설정을 확인하고 기존 상태를 기록하세요. 수동 테스트를 위해 필요하면 잠시 비활성화하세요.
5. 마지막으로 Global Routing과 규칙 매칭 확인
연결 테스트는 성공했는데 페이지가 열리지 않을 때 Home → Global Routing을 확인하세요. 여기서 Proxy, Direct, Config, Scene은 서로 다른 라우팅 방식이지 서로 다른 프로토콜이 아닙니다. Proxy는 프록시로 처리할 수 있는 트래픽을 전역 프록시 방식으로 처리하고, Direct는 직접 연결 방식으로 처리합니다. Config는 선택한 설정의 분기 규칙을 사용하며, Scene은 현재 장면과 연결된 설정을 따로 확인해야 합니다. Scene을 Config의 다른 이름으로 보면 안 됩니다.
라우팅 설정의 영향을 분리하려면 원래 옵션을 기록한 뒤 잠시 Proxy로 전환하고, 같은 서버와 같은 대상을 사용해 접속해 보세요. 완료 후 원래 방식으로 복원하세요. Proxy에서는 접속되지만 Config에서는 안 된다면 Config에서 현재 사용하는 설정, 규칙 순서, 정책 연결을 우선 확인하세요. 이 방법은 점검 범위를 좁힐 뿐 모든 DNS 또는 대상 사이트 문제를 배제하지는 않습니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY위 내용은 규칙 매칭을 설명하기 위한 예시이며 전체 설정을 대체할 수 없습니다. DOMAIN-SUFFIX는 지정된 도메인과 하위 도메인에 매칭됩니다. IP-CIDR은 대상 IP 대역에 매칭되며, 예시의 192.0.2.0/24는 문서용 대역입니다. no-resolve는 해당 IP 규칙의 매칭을 위해 도메인을 별도로 조회하지 않는다는 뜻입니다. GEOIP는 IP의 지리적 위치를 기준으로 매칭하고, FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리합니다.
- 규칙은 위에서 아래 순서로 확인하며 먼저 매칭된 규칙의 정책이 적용됩니다. 우선 처리해야 하는 항목은 더 위에 배치하세요.
DIRECT,PROXY,REJECT는 각각 직접 연결, 프록시, 거부를 의미합니다. 대상이 REJECT 규칙에 매칭되었다면 서버 시간 초과로 간주해 계속 점검하지 마세요.- 사용자 지정 정책 그룹을 이용한다면 규칙에서 참조하는 이름과 그룹 내 선택 항목을 확인하세요. 테스트에 성공한 서버가 해당 규칙에서 실제로 사용하는 출구 서버라는 보장은 없습니다.
- 일부 도메인만 실패한다면 해당 대상에 적용된 규칙과 정책을 기록하세요. 다른 요청에 영향을 주도록 FINAL 규칙을 임의로 옮기지 마세요.
6. 구독 업데이트와 연결 실패에 관한 자주 묻는 질문
구독 업데이트가 시간 초과되면 기존 항목이 모두 만료된 건가요?
반드시 그렇지는 않습니다. 구독 업데이트는 설정 데이터를 가져오는 요청이고, 저장된 항목의 연결 테스트는 별도의 요청 경로를 사용합니다. 먼저 Home에 저장된 항목을 테스트한 다음 기존 구독이 유효한지 확인하세요. 기존 프록시를 통해 업데이트해야 한다면 연결이 정상인지 먼저 확인한 뒤 Settings → Subscribe → Update via Proxy를 살펴보세요. 모든 항목이 연결되지 않는 상태라면 이 옵션을 켜도 연결이 복구되지는 않습니다.
지연 시간은 표시되는데 웹페이지가 열리지 않는 이유는 무엇인가요?
먼저 Connectivity Test의 테스트 방식을 확인하세요. 포트에 연결된다고 해서 인증, TLS, 대상 주소 확인, 대상의 응답까지 모두 성공한 것은 아닙니다. 프로토콜 설정을 순서대로 확인하고 같은 대상에서 Proxy와 Config의 결과를 비교하세요. 숫자 하나만 보고 전체 연결 경로가 정상이라고 판단하지 마세요.
Wi-Fi에서만 시간 초과가 발생하고 셀룰러 네트워크에서는 정상이라면 비밀번호를 바꿔야 하나요?
먼저 비밀번호와 다른 항목은 그대로 둔 채 같은 항목을 반복 비교하세요. Wi-Fi에 로그인 인증이 필요한지, 사용 중인 포트나 UDP가 네트워크에서 제한되는지 확인하세요. 네트워크별 차이를 관리자에게 전달하세요. 비밀번호를 무작정 바꾸면 기존에 작동하던 설정까지 손상될 수 있습니다.
구독을 업데이트한 뒤 시간 초과가 발생하면 바로 삭제하고 다시 추가해야 하나요?
먼저 업데이트 전후의 주소, 포트, Type, 전송 설정을 비교하고 현재 선택한 항목이 바뀌었는지 확인하세요. 원래 정보를 보관한 뒤 서비스 제공업체에 변경 사항을 문의하세요. 항목을 바로 삭제하면 비교할 근거가 사라질 뿐 아니라 원격 서버가 응답하지 않는 문제도 해결되지 않습니다.
결론: 재현 가능한 최소 기록 남기기
점검이 끝나면 “같은 항목, 같은 테스트 방식, 두 종류의 네트워크, 하나의 대상, 한 번에 한 항목만 변경”한 결과를 보관하세요. 이를 바탕으로 다음 단계가 로컬 설정 수정인지, 네트워크 조건 확인인지, 서비스 제공업체에 서버 점검을 요청할지 판단할 수 있습니다.