이 글은 Shadowrocket에서 직접 보유한 구성을 가져왔지만 지연 테스트가 시간 초과되거나 연결을 켜도 요청에 실패하는 경우를 위한 안내입니다. 테스트 결과의 의미, 로컬 네트워크, 프로토콜 항목, 시스템 시간, TLS 순서로 확인하고 한 번에 조건 하나만 바꾸세요. 마지막으로 같은 요청을 다시 테스트해 서버에 도달할 수 없는 문제인지, 설정 불일치인지, 규칙이 일치하지 않은 것인지 구분합니다.
1. 지연 테스트와 실제 연결을 구분하기
‘시간 초과’는 대기 시간 안에 어떤 단계가 완료되지 않았다는 뜻일 뿐, 비밀번호가 틀렸거나 서버가 중단됐다는 의미는 아닙니다. 지연 테스트는 방식에 따라 확인하는 연결 경로가 다릅니다. TCP 핸드셰이크에 성공해도 해당 시점에 대상 주소와 포트로 TCP 연결을 설정할 수 있었다는 것만 확인됩니다. 프록시를 통한 HTTP 요청에는 프로토콜 협상, 대상 사이트 접속, 응답 반환도 포함됩니다. 두 결과는 서로 대신할 수 없습니다.
먼저 Home에서 선택한 구성 이름, 테스트 방식, 결과를 기록한 다음 평소 접속할 수 있는 HTTPS 페이지를 브라우저에서 열어 보세요. 이는 진단을 위한 확인이며 계정 정보를 입력할 필요는 없습니다. 한 번의 테스트 결과를 지속적인 상태로 간주하지 말고 VPN 표시만 보고 프록시 연결이 정상이라고 판단하지도 마세요. 시스템 터널 설정과 원격 인증 성공은 서로 다른 단계입니다.
| 관찰 결과 | 판단할 수 있는 점 | 다음 단계 |
|---|---|---|
| TCP 테스트 성공, 웹페이지 접속 실패 | 포트에 연결할 수 있다는 뜻이며 프로토콜 인증이나 TLS 성공을 의미하지는 않습니다 | Type, 인증 정보, TLS 항목 확인 |
| 지연 테스트 시간 초과, 웹페이지는 열림 | 테스트 방식·대상 또는 탐색 경로가 다를 수 있습니다 | 테스트 방식을 기록하고 같은 실제 요청을 다시 확인 |
| Wi-Fi 실패, 셀룰러 네트워크 성공 | 네트워크 연결과 관련된 문제일 수 있지만 원인이 된 장치는 아직 특정할 수 없습니다 | Wi-Fi 로그인, DNS, 네트워크 제한 확인 |
| 특정 웹사이트 하나만 접속 실패 | 전체 연결을 사용할 수 없다고 단정하기 어렵습니다 | 해당 요청에 적용된 규칙과 대상 응답 확인 |
요약: 실제 접속 테스트도 함께 기록
지연 시간과 웹페이지 접속 결과가 다르면 현재 구성을 유지하고 테스트 방식과 실제 요청 결과를 기록한 뒤 실패한 단계를 기준으로 확인하세요. 프로토콜을 여러 개 한꺼번에 바꾸거나 모든 설정을 바로 초기화하지 마세요.
2. 테스트 조건을 고정하는 6단계
문제를 확인하는 동안 기존 구성 하나와 같은 테스트 페이지를 사용하세요. 네트워크 전환, 구독 업데이트, 라우팅 모드 변경은 결과에 영향을 줄 수 있습니다. 여러 조건을 한꺼번에 바꾸면 원인을 파악하기 어렵습니다. 다음 단계는 반복 가능한 기준을 만들기 위한 것이며 특정 라우팅 설정을 계속 사용하라는 뜻은 아닙니다.
-
현재 설정 기록
Home에서 선택된 구성과 Global Routing의 현재 모드를 기록하세요. Settings → On Demand에서 주문형 연결 상태도 확인합니다. 테스트 중 자동으로 다시 연결된다면 기존 조건을 기록한 다음 잠시 비활성화하고, 테스트가 끝난 뒤 복원하세요.
-
로컬 네트워크 확인
연결을 잠시 끄고 현재 Wi-Fi 또는 셀룰러 네트워크에서 평소 이용하는 페이지에 접속할 수 있는지 확인하세요. 공용 Wi-Fi에 웹 로그인 인증이 필요한 경우 먼저 인증을 완료한 뒤 Shadowrocket의 연결을 켜세요.
-
구성 고정
Home으로 돌아가 확인할 구성을 선택하고 이름이 같은 다른 항목을 고른 것은 아닌지 확인하세요. 테스트 도중 주소, 포트 또는 인증 정보가 바뀌지 않도록 구독을 반복해서 업데이트하지 마세요.
-
규칙 영향 분리
Home → Global Routing에서 일시적으로 Proxy를 선택한 뒤 같은 테스트 페이지로 프록시 경로를 확인하세요. Proxy는 규칙의 영향을 분리하기 위한 설정이며 모든 페이지에 접속할 수 있음을 보장하지 않습니다. Direct는 직접 연결하므로 선택한 프록시가 작동하는지 확인하는 용도로 사용할 수 없습니다.
-
네트워크 전환
구성과 페이지를 그대로 둔 채 Wi-Fi와 셀룰러 네트워크에서 각각 테스트하세요. 각 네트워크에서 세 번씩 확인하고 성공 또는 시간 초과 여부와 발생 시각을 기록할 수 있습니다. 이는 기록 방법에 대한 권장 사항이며 미리 정해진 테스트 결과가 아닙니다.
-
설정 복원
테스트가 끝나면 Global Routing을 원래 사용하던 Config, Scene 또는 다른 모드로 복원하고 On Demand 조건도 되돌리세요. Proxy에서는 작동하지만 Config에서는 작동하지 않는다면 Config의 활성 구성과 규칙을 확인하세요.
셀룰러 네트워크로 전환한 뒤 정상화되면 비밀번호를 바로 바꾸기보다 기존 Wi-Fi를 먼저 확인하세요. 반대로 두 네트워크에서 같은 단계에 실패하더라도 주소, 포트, 인증 정보, 서버 상태처럼 공통 조건을 더 확인해야 한다는 뜻일 뿐, 어느 항목이 잘못됐는지는 단정할 수 없습니다.
3. 주소·포트·프로토콜 항목 확인
Home에서 해당 구성의 편집 화면을 열고 서비스 제공자가 전달한 원본 정보와 항목별로 대조하세요. Type은 클라이언트가 사용할 프로토콜을 결정하므로 주소가 같다는 이유만으로 임의로 바꾸면 안 됩니다. 주소 항목에는 일반적으로 호스트 이름이나 IP를 입력합니다. 구독 URL 전체를 서버 주소로 입력하거나 웹페이지 경로를 호스트 이름 항목에 넣지 마세요.
| 설정 항목 또는 프로토콜 | 확인할 내용 | 흔한 오해 |
|---|---|---|
| 주소와 포트 | 호스트 이름의 철자, 포트 번호, 앞뒤 공백 확인. 원본 구성을 기준으로 대조 | 443은 흔히 사용하는 포트의 예일 뿐, 모든 서비스를 443으로 바꿔야 한다는 뜻은 아닙니다 |
| Shadowsocks | 암호화 방식과 비밀번호가 서버 설정과 일치하는지 확인하고 플러그인이 있다면 플러그인 설정도 대조 | 포트 접속만 확인하고 암호화 방식 불일치는 놓침 |
| VMess / VLESS | UUID, 전송 방식, 구성에 지정된 TLS·Host·Path 등의 매개변수 확인 | UUID를 일반 비밀번호로 취급하거나 전송 계층 항목을 누락 |
| Trojan | 비밀번호, TLS, SNI를 확인하고 서버 인증서 및 설정과 일치하는지 대조 | 포트가 열려 있으면 TLS와 비밀번호도 올바르다고 판단 |
| Hysteria2 | 인증 정보, TLS, 기존 구성의 혼동 방지 매개변수를 확인하고 필요한 UDP 통신이 네트워크에서 허용되는지 확인 | TCP 탐색 결과로 QUIC 기반 연결 상태를 판단 |
| WireGuard | 키, Endpoint, 터널 주소, 라우팅 범위를 확인하고 UDP 접속 가능 여부 점검 | TLS 인증서가 없는 프로토콜도 SNI 문제로 처리 |
예를 들어 원본 정보에 포트가 8443이라고 명시되어 있다면 편집 화면에도 8443으로 설정되어 있는지 확인하세요. TLS를 사용한다는 이유만으로 443으로 바꾸면 안 됩니다. 마찬가지로 TLS의 SNI는 핸드셰이크 중 서버 이름을 지정하고, 전송 계층의 Host는 해당 전송에 사용할 호스트 정보를 지정합니다. 특정 구성에서 두 값이 같더라도 모든 구성에서 반드시 같아야 한다고 볼 수는 없습니다.
- 인증 정보를 복사할 때 앞뒤 공백, 줄바꿈, 전각 문자가 포함되지 않았는지 확인해 긴 문자열을 직접 다시 입력하지 않도록 하세요.
- 암호화 방식을 하나씩 전부 바꿔 가며 확인하지 마세요. 먼저 원본 항목을 확보한 뒤 하나씩 대조하세요.
- 구독을 업데이트한 뒤 Home에서 현재 선택된 항목을 다시 확인하세요. 새로 추가되거나 이름이 바뀐 항목이 기존에 선택했던 항목과 다를 수 있습니다.
- 문제를 문의할 때 비밀번호, UUID, 개인 키, 구독 token을 가리세요. 프로토콜 유형과 오류가 발생한 단계만으로도 초기 진단을 시작하기에 충분한 경우가 많습니다.
4. iPhone 시스템 시간과 TLS 인증서 확인
TLS 검증은 인증서에 해당하는 이름뿐 아니라 유효 기간도 확인합니다. iPhone 시간이 실제 시간과 크게 다르면 인증서가 아직 유효하지 않거나 이미 만료된 것으로 잘못 판단될 수 있습니다. iPhone에서 ‘설정 → 일반 → 날짜 및 시간’을 열어 ‘자동으로 설정’과 현재 표시 시간을 확인하세요. 관리 정책으로 설정을 변경할 수 없다면 먼저 기기 관리 요구 사항을 확인해야 합니다.
시간을 바로잡은 뒤 연결을 다시 설정하고 테스트하세요. 인증서 오류가 계속되면 기기 시간 문제인지, 서버 인증서가 만료됐는지, SNI와 인증서 이름이 일치하지 않는지 구분해야 합니다. 기기 시간이 정확하더라도 서버에서 만료된 인증서가 갱신되지는 않습니다. 연결 주소를 IP로 바꿔도 인증서 이름 불일치가 자동으로 해결되지 않습니다.
Allow Insecure로 인증서 문제를 덮지 마세요
Allow Insecure(안전하지 않은 연결 허용)는 인증서 검증을 약화하므로 일반적인 해결 방법으로 사용하면 안 됩니다. 검증을 유지한 채 SNI와 원본 정보를 대조하고 서비스 제공자에게 서버 인증서를 확인해 달라고 요청하세요. 오류 메시지를 없애려고 이 옵션을 함부로 켜지 마세요.
- 시간 확인: 특히 시간을 수동으로 변경한 적이 있다면 날짜, 시간, 시간대가 올바르게 설정되어 있는지 확인하세요.
- 이름 확인: SNI에는 기존 구성이 요구하는 이름을 사용하세요.
https://가 포함된 전체 URL이나 경로를 입력하지 마세요. - 유효 기간 확인: 기기 시간이 정확한데도 인증서가 만료됐다는 오류가 표시되면 원래 오류 메시지를 기록해 서비스 제공자에게 확인하세요.
- 프로토콜 구분: 실제로 TLS를 사용하는 연결만 이 항목에 따라 확인하세요. WireGuard의 키와 핸드셰이크 문제는 SNI를 조정해 해결할 수 없습니다.
5. 로그 오류로 실패 단계 파악
‘웹페이지가 열리지 않는다’는 증상도 이름 확인, 연결 설정, TLS 핸드셰이크, 인증 등 서로 다른 단계에서 발생할 수 있습니다. 문제를 한 번 재현한 뒤 앱에서 확인할 수 있는 진단 로그에서 해당 시각의 기록을 찾아 오류 문구 전체를 보관하세요. 아래는 흔히 볼 수 있는 하위 단계 오류의 일부입니다. 대소문자, 접두어, 표시 위치는 프로토콜 구현에 따라 다를 수 있으며 매번 같은 문구가 표시되는 것은 아닙니다.
오류: i/o timeout
원인 및 해결: 읽기 또는 쓰기 작업이 대기 시간을 초과했습니다. 이 문구만으로는 어느 단계에서 실패했는지 알 수 없습니다. 앞뒤 로그를 함께 보고 대상 주소와 실패 단계를 확인한 뒤 구성을 그대로 둔 상태에서 Wi-Fi와 셀룰러 네트워크를 전환해 다시 테스트하세요.
오류: connection refused
원인 및 해결: 대상 또는 중간 장치가 연결을 명시적으로 거부했습니다. 포트에서 서비스가 대기 중이 아니거나 접근 정책과 관련된 문제일 수 있습니다. 먼저 포트와 프로토콜을 확인하고, 설정이 맞다면 서비스 제공자에게 해당 포트의 서비스 상태를 확인해 달라고 요청하세요.
오류: no such host
원인 및 해결: 주소 확인 단계에서 사용할 수 있는 호스트 주소를 얻지 못했습니다. 호스트 이름의 철자나 DNS 응답에 문제가 있을 수 있습니다. 서버 호스트 이름을 확인하고 다른 네트워크에서도 테스트하세요. 인증 정보는 바로 변경하지 마세요.
오류: x509: certificate has expired or is not yet valid
원인 및 해결: 인증서 유효 기간과 현재 시간이 일치하지 않습니다. 먼저 iPhone의 자동 시간 설정을 확인하세요. 시간이 정확하다면 서비스 제공자에게 서버 인증서를 확인해 달라고 요청하고, 검증 해제를 장기적인 해결책으로 사용하지 마세요.
기록에는 ‘어떤 요청이 어느 네트워크에서 언제 실패했는지’를 명확히 적으세요. 빨간색 시간 초과 화면만 제출해서는 원인을 파악하기 어렵습니다. 로그에 연결 종료만 표시된다고 비밀번호 오류라고 단정할 수도 없습니다. 서버 정책, 전송 매개변수 불일치, 네트워크 중단으로 연결이 일찍 종료될 수 있으므로 앞서 확인한 항목과 함께 살펴보세요.
요약: 가장 먼저 실패한 단계부터 수정
같은 요청에서 가장 먼저 실패한 단계가 호스트 이름 확인이라면 주소와 DNS부터 확인하세요. 연결이 TLS 또는 인증 단계에 도달한 경우에만 해당 항목을 점검하세요. 아직 도달하지 않은 단계의 매개변수를 반복해서 바꾸지 마세요.
6. 연결 복구 후 규칙과 구독 확인
Proxy 모드에서는 접속되지만 Config로 돌아간 뒤 실패한다면 활성 구성의 규칙과 정책 대상을 확인하세요. DOMAIN-SUFFIX는 도메인 접미사를 기준으로 일치하고, IP-CIDR은 IP 대역을 기준으로 일치하며, GEOIP는 지리 IP 조건을 사용합니다. FINAL은 최종 규칙으로 나머지 연결을 처리합니다. 각 조건을 모두 같은 도메인 판정으로 취급할 수는 없습니다. 규칙 순서, 실제 요청 도메인, 최종적으로 적용된 정책을 함께 확인해야 합니다.
예를 들어 기존 구성의 FINAL,DIRECT는 앞선 규칙과 일치하지 않은 연결을 직접 전송한다는 뜻입니다. 페이지가 열렸다고 해서 프록시를 통과했다고 볼 수는 없습니다. 반대로 사이트의 메인 페이지와 리소스가 서로 다른 도메인을 사용할 수 있으므로 메인 도메인만 일치시켜도 모든 리소스가 같은 경로를 이용한다고 단정할 수 없습니다. 먼저 요청 기록에서 실제 도메인과 일치한 규칙을 확인한 다음 Config를 수정할지 판단하세요.
지연 테스트에 숫자가 표시되는데 웹페이지가 열리지 않는 이유는 무엇인가요?
먼저 테스트 방식을 확인하세요. TCP에 연결할 수 있어도 프로토콜 인증에 성공했다는 뜻은 아닙니다. Home에서 선택한 항목과 Global Routing을 확인하고, Proxy를 임시로 선택해 다시 테스트한 뒤 프로토콜 항목과 TLS 로그를 살펴보세요. 테스트가 끝나면 원래 설정으로 복원하세요.
구독 업데이트가 시간 초과되면 모든 구성이 작동하지 않는 건가요?
아닙니다. 구독 업데이트는 구독 주소에 요청을 보내고, 저장된 구성으로 연결하는 것은 별도의 요청입니다. Home에서 구독 항목을 확인하고 구독이 아직 유효한지 확인하세요. Settings → Subscribe → Update via Proxy 설정이 현재 이용 가능한 연결 경로에 맞는지도 살펴보세요. 프록시 자체가 작동하지 않을 때 업데이트를 반복해서 시도하지 마세요.
Direct로 바꾸자 웹페이지가 열리면 문제가 해결된 건가요?
해당 페이지에 직접 접속할 수 있다는 점만 확인된 것이며 프록시 구성이 복구된 것은 아닙니다. Home → Global Routing으로 돌아가 Proxy를 선택해 현재 구성을 테스트한 다음 Config로 복원해 규칙을 확인하세요. 원래 Scene을 사용했다면 해당 시나리오의 실제 라우팅 설정도 확인해야 합니다.
수동으로 연결을 끊었는데 다시 자동 연결되는 이유는 무엇인가요?
Settings → On Demand에서 주문형 연결 조건을 확인하세요. 테스트 조건을 고정하려면 현재 조건을 기록한 뒤 잠시 비활성화하고, 문제 해결을 마친 다음 복원하면 됩니다. 시스템 연결이 자동으로 다시 설정되더라도 원격 인증에 성공했다는 뜻은 아닙니다.
7. 재현 가능한 기록을 정리해 문의하기
위 항목을 모두 확인해도 문제가 계속되면 핵심 정보만 정리해 서비스 제공자에게 서버 상태를 문의하세요. 공개 게시물에 구독 주소 전체를 붙여 넣지 마세요. 구독 링크의 token에는 일반적으로 접근 권한이 포함되어 있으므로 스크린샷에서도 QR 코드와 인증 정보를 가려야 합니다. 앱 구매 정보와 연결 서비스 설정은 별개이며, 앱을 구매해도 누락된 서버 매개변수가 보충되지는 않습니다.
- 환경: iPhone 또는 iPad, 실제 시스템 정보, Wi-Fi 또는 셀룰러 네트워크. 시스템 호환 요구 사항은 App Store 페이지를 기준으로 확인하세요.
- 구성: 프로토콜 Type, 포트, TLS 사용 여부, 전송 방식. 비밀번호, 개인 키, 구독 링크 전체는 포함하지 마세요.
- 모드: Global Routing에서 Proxy, Direct, Config, Scene 중 무엇을 사용했는지와 테스트 중 On Demand가 활성화되어 있었는지 기록하세요.
- 결과: 같은 페이지를 두 네트워크에서 각각 세 번 테스트한 성공·실패 기록과 사용한 지연 테스트 방식을 적으세요.
- 로그: 한 번 재현한 시각과 가장 먼저 발생한 오류 원문을 기록하고, 민감한 항목을 삭제한 뒤 필요한 앞뒤 내용을 남기세요.
주소와 포트, 프로토콜 항목, 기기 시간을 모두 확인했는데도 여러 네트워크에서 같은 단계에 계속 실패한다면 서비스 제공자에게 포트 대기 상태, 인증 정보, 인증서를 확인해 달라고 요청하세요. 로컬 설정을 무작위로 계속 바꾸는 것보다 효과적으로 원인을 좁힐 수 있습니다. 마지막으로 기존 규칙과 On Demand 조건을 복원하고 평소 접속도 예상대로 되는지 확인하세요.