Shadowrocket에서 시간 초과가 표시되더라도 원격 서버의 장애라고 단정할 수는 없습니다. 이미 이용 중인 서비스와 구독 정보가 있는 사용자를 위해 네트워크 연결, 프로토콜 인증, TLS 검증, 시스템 시간 문제를 차례로 구분한 뒤 라우팅과 구독 업데이트를 확인합니다. 한 번에 한 가지 조건만 바꾸고 테스트 방식, 네트워크 종류, 오류 문구를 기록해야 변경 효과를 판단할 수 있습니다.
1. 테스트 조건을 고정하고 테스트와 실제 연결 구분하기
먼저 Home에서 해당 항목의 Connectivity Test를 실행한 다음 실제 접속도 한 번 시도합니다. 지연 시간은 이번 테스트에 사용된 경로와 방식만 보여 줍니다. 이 결과만으로 프로토콜 인증, TLS 핸드셰이크, 대상 웹사이트 접속까지 정상이라고 판단할 수는 없습니다. TCP 연결이 성립해도 이후 인증 단계에서 실패할 수 있으며, 특정 테스트에서 시간 초과가 발생했다고 모든 트래픽이 전송되지 않는다고 단정할 수도 없습니다.
점검하는 동안 구독 새로고침, 구성 전환, DNS 변경, 네트워크 변경을 동시에 하지 마세요. 연결이 복구되더라도 원인을 확인할 수 없게 됩니다. 사용 중인 구성의 사본을 먼저 저장하고 현재 항목 이름, 프로토콜 종류, Global Routing 상태를 기록하세요. 암호, UUID, 개인 키, 전체 구독 링크는 공개 기록에 남기지 마세요.
-
네트워크 고정
같은 Wi-Fi를 유지하고 일반적인 인터넷 연결이 되는지 먼저 확인합니다. 웹 로그인 인증이 필요한 네트워크라면 먼저 인증을 완료하세요. 이 단계에서는 셀룰러 네트워크로 전환하지 않습니다.
-
항목 고정
Home에서 기존 항목 하나를 선택하고 Type, 주소, Port를 기록합니다. 다른 항목으로 바꾸거나 여러 매개변수를 한꺼번에 수정하지 마세요.
-
테스트 기록
Home에서 Connectivity Test를 실행하고 테스트 방식, 결과, 시간을 기록합니다. 반복 테스트는 같은 방식으로 진행하고 서로 다른 방식의 수치를 직접 비교하지 마세요.
-
자동 연결 조건 확인
Settings → On Demand에서 현재 조건을 기록합니다. 자동 연결 때문에 수동 재현이 어렵다면 On Demand를 잠시 끄고, 점검을 마친 뒤 기존 설정으로 되돌립니다.
-
한 번 재현
Home으로 돌아가 연결을 켜고 같은 대상에 접속합니다. 연결 스위치가 켜진 상태로 유지되는지, 즉시 오류가 표시되는지, 특정 웹사이트만 실패하는지 구분하세요.
2. 지연 시간과 오류 문구로 문제 발생 단계를 판단하기
지연 테스트가 계속 시간 초과되면 주소, 포트, 네트워크 경로부터 확인하세요. 테스트 결과는 나오지만 실제 접속이 즉시 끊긴다면 프로토콜 설정과 TLS를 중점적으로 점검합니다. 특정 웹사이트 하나만 실패할 때는 모든 항목을 다시 만들기 전에 해당 요청에 적용된 정책을 확인하세요. 아래는 흔히 볼 수 있는 네트워크 오류 문구입니다. 앱에 표시되는 전체 메시지에는 주소, 포트 또는 앞뒤 상황이 함께 나올 수 있습니다.
오류: Connection timed out
원인: 제한 시간 안에 작업이 완료되지 않았다는 뜻입니다. 네트워크 경로, 원격 응답 또는 핸드셰이크와 관련된 문제일 수 있지만, 이 문구만으로 어느 쪽에서 발생한 문제인지 판단할 수는 없습니다.
해결 방법: 주소와 Port를 먼저 확인하세요. 다른 설정은 그대로 둔 채 Wi-Fi와 셀룰러 네트워크를 한 번 전환하고 같은 테스트 결과를 비교합니다.
오류: Connection refused
원인: 연결 요청이 명시적으로 거부되었습니다. 대상 포트에서 서비스가 대기 중이지 않거나 네트워크 장비가 연결을 거부하는 경우가 흔하며, 암호가 틀렸다는 직접적인 증거는 아닙니다.
해결 방법: Port를 서비스 제공자가 안내한 정보와 하나씩 대조하세요. 일치한다면 해당 주소와 포트가 여전히 사용 중인지 문의하세요.
오류: certificate has expired
원인: 인증서 유효기간 검증에 실패했습니다. 원격 인증서가 만료되었거나 기기의 날짜가 실제 시간과 크게 다를 수 있습니다.
해결 방법: 먼저 시스템의 자동 시간 설정을 확인하세요. 시간이 맞는데도 오류가 계속되면 서비스 제공자에게 인증서를 확인해 달라고 요청하세요. 인증서 검증을 끄는 것으로 문제를 대신 해결하지 마세요.
네트워크를 바꾼 뒤 복구되었다면 네트워크 경로와 관련된 문제일 수 있다는 뜻이지, 특정 통신 사업자의 문제라고 단정할 수는 없습니다. 두 네트워크에서 모두 실패하더라도 설정 오류 가능성은 남아 있습니다. ‘한 네트워크에서만 실패’, ‘두 네트워크 모두 실패’, ‘특정 대상에서만 실패’로 나누어 기록한 뒤 다음 단계로 진행하세요.
- 모든 항목이 동시에 실패: 기기의 기본 인터넷 연결, 네트워크 인증, 현재 라우팅 상태, 시간을 먼저 확인하세요.
- 항목 하나만 실패: 해당 항목의 주소, 포트, 인증 정보, 원격 상태를 우선 확인하세요.
- 특정 앱 종류만 실패: 실제 요청에 TCP 또는 UDP 중 무엇이 사용되는지, 예상한 정책이 적용되는지 확인하세요.
3. Type, Port, 프로토콜별 설정을 하나씩 확인하기
Home에서 해당 항목의 편집 화면을 열고 기존 연결 정보를 기준으로 대조합니다. Type은 원격 설정과 일치해야 합니다. 문제를 찾겠다고 VMess를 VLESS로 임의 변경하지 마세요. 주소 입력란에는 해당 필드가 요구하는 주소만 입력하고, 공유 문자열 전체나 웹 경로, 여분의 공백을 섞지 않습니다.
Port는 원격에서 실제로 수신 대기 중인 포트입니다. 경험에 따라 일괄 교체할 수 있는 값이 아닙니다. 예를 들어 기존 구성에 8443이라고 되어 있다면 TLS를 사용한다는 이유만으로 443으로 임의 변경하지 마세요. 아래 숫자는 프로토콜과 포트의 관계를 설명하기 위한 예이며, 접속 가능한 서비스를 제공한다는 뜻이 아닙니다.
| Type | 중점 확인 항목 | 흔한 오해 |
|---|---|---|
| Shadowsocks | 주소, Port, 암호화 방식, 암호를 확인합니다. 플러그인이 있다면 플러그인 설정도 대조합니다. | 암호만 바꾸고 암호화 방식이 원격 설정과 일치하는지 확인하지 않습니다. |
| VMess / VLESS | UUID, 전송 방식, 기존 구성에서 요구하는 TLS, Host, Path 등의 필드를 확인합니다. | UUID만 맞으면 된다고 생각해 전송 계층 설정을 놓칩니다. |
| Trojan | 암호, TLS, Server Name, 기존 구성에서 지정한 전송 방식을 확인합니다. | 암호를 다른 인증 필드에 입력하거나 인증서에 해당하는 도메인을 누락합니다. |
| Hysteria2 | 인증 정보, TLS, Server Name, UDP 경로를 확인합니다. | TCP 테스트가 성공하면 UDP 경로도 반드시 사용 가능하다고 생각합니다. |
| WireGuard | 로컬 개인 키, 상대 공개 키, Endpoint, 주소, 라우팅 관련 설정을 확인합니다. | 키의 역할을 반대로 입력하거나 Endpoint만 확인하고 라우팅을 놓칩니다. |
모든 프로토콜이 표의 필드를 전부 사용하는 것은 아닙니다. 현재 Type에서 실제로 표시되고 기존 정보에 명시된 항목만 확인하세요. 항목이 본인 구독에서 가져온 것이라면 업데이트 전에 로컬 변경 사항을 기록합니다. 업데이트 후 편집 화면을 다시 열어 수정 내용이 구독의 이전 값으로 덮어쓰이지 않았는지 확인하세요.
4. TLS, Server Name, 시스템 시간 확인하기
TLS 오류가 발생하면 먼저 항목 편집 화면의 TLS 설정과 Server Name(SNI)을 확인하세요. 연결 주소가 IP여도 인증서는 도메인 이름을 대상으로 발급되었을 수 있습니다. 이 경우 주소 입력란의 값을 그대로 복사하지 말고 기존 구성에 지정된 Server Name을 입력해야 합니다. 인증서 검증에 쓰이는 이름과 네트워크 요청의 Host는 임의로 바꿔 쓸 수 있는 필드가 아닙니다.
WebSocket을 사용한다면 Path와 Host가 원격 설정과 일치해야 합니다. Path의 대소문자, 앞의 슬래시, 추가 매개변수가 요청에 영향을 줄 수 있으므로 흔해 보이는 경로를 임의로 입력하지 마세요. 원격 설정에 없는 필드도 추측해서 추가하지 않습니다.
- 항목 편집 화면에서 TLS, Server Name, 전송 방식, Host, Path를 하나씩 대조하고 저장한 뒤 같은 대상에 다시 연결해 보세요.
- iPhone 또는 iPad에서 시스템 ‘설정 → 일반 → 날짜 및 시간’을 열고 ‘자동으로 설정’을 확인합니다. 현재 날짜, 시간, 시간대가 올바른지도 살펴보세요.
- ‘자동으로 설정’을 변경할 수 없다면 기기 관리 제한이나 시스템 설정 조건을 확인하세요. 오류를 피하려고 인증서 유효기간에 맞는 과거 날짜를 수동으로 설정하지 마세요.
- 시간을 맞춘 뒤 연결을 다시 설정합니다. 기기 시간이 정확한데도 인증서가 만료되었거나 이름이 일치하지 않는다면 오류 문구를 보관하고 서비스 제공자에게 인증서 설정을 확인해 달라고 요청하세요.
5. 라우팅, DNS, 구독 업데이트 문제 구분하기
설정과 TLS 확인을 마친 뒤 Home → Global Routing을 살펴봅니다. Proxy, Direct, Config, Scene은 네 가지 지연 테스트 방식이 아니라 트래픽을 처리하는 서로 다른 상태입니다. 문제를 확인할 때 Proxy를 잠시 사용해 선택한 프록시 경로를 테스트할 수 있습니다. 테스트가 끝나면 원래 상태로 복원하고, 임시 전환을 영구적인 해결책으로 삼지 마세요.
- Proxy: 프록시 경로를 확인할 때 실제로 선택된 항목이나 정책 그룹 구성원이 예상한 대상인지 확인하세요.
- Direct: 직접 연결 경로를 확인합니다. 이 상태에서 접속에 성공해도 프록시 항목이 올바르다는 뜻은 아닙니다.
- Config: Config에서 현재 사용 중인 구성을 확인하고 요청이 앞쪽 규칙에 먼저 일치하는지 살펴보세요.
- Scene: 선택한 Scene의 설정을 확인하세요. Proxy나 Config와 같은 결과가 나온다고 가정하지 마세요.
Config에서는 DOMAIN-SUFFIX, IP-CIDR, GEOIP 등의 규칙마다 일치 조건이 다릅니다. FINAL은 앞선 규칙에 하나도 일치하지 않을 때 적용되는 기본 규칙입니다. 규칙은 위에서부터 차례로 확인되므로 도메인이 앞선 DIRECT 또는 REJECT 규칙에 이미 처리되었다면 뒤의 FINAL을 수정해도 해당 요청에는 영향을 주지 않습니다. 실제 요청 기록을 먼저 확인한 뒤 규칙을 수정하고, 웹사이트 하나가 열리지 않는다고 구성 전체를 삭제하지 마세요.
DNS 문제도 별도로 확인해야 합니다. 도메인으로 연결되지 않다가 IP를 입력했을 때 결과가 달라졌다면 이름 해석 경로를 살펴볼 단서일 뿐, IP를 영구적인 대체 주소로 써도 된다는 뜻은 아닙니다. TLS에 기존 Server Name이 필요할 수도 있습니다. DNS, SNI, 주소를 동시에 바꾸면 어떤 변경이 결과에 영향을 줬는지 구분할 수 없습니다.
지연 테스트에 수치가 나오는데 웹페이지는 왜 열리지 않나요?
Connectivity Test에 사용한 방식을 먼저 기록한 뒤 같은 대상에 직접 접속해 보세요. Global Routing과 적용된 정책을 확인합니다. 테스트 성공은 특정 단계에서 연결 가능했음을 보여 줄 뿐, 인증부터 TLS와 대상 서버 응답까지 전 과정을 확인한 것은 아닙니다.
기존 항목은 작동하는데 구독 업데이트는 왜 시간 초과되나요?
구독 업데이트는 구독 주소에 접속하며 기존 항목의 서버 포트에 연결하는 것이 아닙니다. Home에서 본인 구독을 새로고침하고 링크가 여전히 유효한지 확인하세요. 기존 프록시 연결이 작동하고 구독 주소 접속에 해당 경로가 필요하다면 Settings → Subscribe에서 Update via Proxy를 확인한 뒤 한 번 더 시도하세요.
Wi-Fi에서는 시간 초과되지만 셀룰러 네트워크에서는 정상이라면 암호를 다시 입력해야 하나요?
암호는 아직 바꾸지 마세요. 같은 항목과 테스트 방식을 유지하고 Wi-Fi 웹 인증, 네트워크 제한, UDP 연결 가능성을 확인합니다. 특정 네트워크에서만 실패한다면 설정은 그대로 두고 네트워크 경로의 차이를 계속 살펴보세요.
수동으로 껐는데 매번 다시 연결됩니다. 어떻게 안정적으로 재현하나요?
Settings → On Demand에서 자동 연결 조건을 확인하세요. 조건을 기록한 뒤 On Demand를 잠시 끄고 Home으로 돌아가 수동으로 다시 테스트합니다. 점검이 끝나면 필요한 조건을 복원해 자동 연결이 테스트 상태를 바꾸지 않도록 하세요.
6. 문제가 계속되면 최소한의 점검 기록 제출하기
앞선 항목을 모두 확인했는데도 문제가 계속되면 단순히 ‘연결이 안 된다’고 설명하기보다 재현에 필요한 최소한의 기록을 서비스 제공자에게 전달하세요. 구독 업데이트, Connectivity Test, 실제 접속 중 어디에서 오류가 났는지 구분하고 마지막으로 변경한 항목 하나를 알려 주세요. 로그는 해당 시간대에 필요한 부분만 발췌하고 구성 전체를 공개하지 마세요.
- 환경: 기기 종류, 시스템에 표시된 버전, Wi-Fi 또는 셀룰러 네트워크, 자동 시간 설정 상태.
- 대상: 프로토콜 Type, 식별 정보를 가린 항목 이름, 사용한 Port. 암호, UUID, 개인 키, 구독 토큰은 포함하지 마세요.
- 증상: 오류 원문, 발생 시간, 테스트 방식, 네트워크 전환 전후의 차이.
- 라우팅: Global Routing 상태, 현재 구성 또는 Scene, 확인한 적용 정책.
- 점검 내역: 설정 대조 결과, TLS와 Server Name 일치 여부, 시간 조정 후 재연결 여부.
복구되면 원래 사용하던 On Demand 조건과 Global Routing 상태를 되돌리고 같은 대상에 다시 접속해 보세요. 유효한 변경 사항은 유지하고 진단을 위해 임시로 추가한 설정은 되돌립니다. 인증서 검증을 건너뛰거나 확인되지 않은 주소를 대체 값으로 남겨 두지 마세요.