Shadowrocket의 지연 시간 수치, VPN 연결 상태, 웹페이지 접속 여부는 각각 서로 다른 단계의 결과를 보여 줍니다. 직접 이용 중인 서비스와 설정이 있는데 timeout 또는 연결 실패가 발생한 경우를 위한 안내입니다. 설정을 유지한 채 테스트를 반복하고, 프로토콜·포트·라우팅을 확인한 다음 시스템 시간과 네트워크 차이를 점검해 모든 문제를 노드 탓으로 돌리지 않도록 합니다.
1. 테스트 시간 초과, 터널 연결, 웹페이지 오류 구분하기
먼저 어느 단계에서 실패했는지 확인한 다음 해당 설정을 조정하세요. Home에서 항목에 timeout이 표시되면 해당 테스트가 제한 시간 내에 끝나지 않았다는 뜻입니다. 시스템에 VPN 표시가 떠도 원격 서비스의 인증이 완료됐거나 모든 웹사이트에 정상 접속할 수 있다는 의미는 아닙니다. 테스트 방식, 선택한 항목, 현재 Global Routing 설정, 접속하려는 대상을 함께 기록하세요.
이 흐름은 점검 단계를 나누기 위한 것으로, 모든 요청이 반드시 같은 순서로 처리된다는 뜻은 아닙니다. 도메인 확인은 기기나 원격 서버에서 이뤄질 수 있고, 규칙은 도메인·IP 또는 다른 조건에 따라 출구를 결정할 수 있습니다. 지연 시간 결과 하나만으로 이 모든 단계를 판단할 수는 없습니다.
- 테스트만 시간 초과되는 경우: 같은 테스트를 반복한 다음 실제 요청도 시도하세요. 설정을 바로 삭제하지 마세요.
- 연결 스위치가 켜진 상태로 유지되지 않는 경우: 시스템 VPN 권한, 다른 VPN 연결, On Demand를 먼저 확인한 뒤 원격 서버 설정을 살펴보세요.
- 연결은 켜졌지만 모든 대상에 접속할 수 없는 경우: 선택한 항목, Global Routing, 인증, DNS를 확인하세요.
- 특정 도메인만 접속되지 않는 경우: 해당 도메인의 규칙, DNS 확인 결과, 대상 서버 상태를 먼저 점검하세요.
2. Home에서 지연 시간 테스트를 반복하고 비교 조건 유지하기
Home에서 기존 설정 중 어떤 항목을 테스트하는지 확인하고 이름과 프로토콜을 기록하세요. 같은 네트워크에서 같은 항목을 약 10초 간격으로 세 번 연속 테스트합니다. 테스트 위치와 방식은 현재 앱에 표시되는 내용을 따르세요. TCP 테스트 결과는 주로 TCP 연결 수립 여부를 보여 주므로 UDP 기반 프로토콜의 연결이 정상이라는 근거가 되지는 않습니다.
- Wi-Fi가 네트워크 인증을 마쳤는지, 또는 셀룰러 데이터가 연결되는지 확인하세요. Shadowrocket 연결을 잠시 끄고 브라우저로 평소 접속할 수 있는 페이지를 열어 기본 네트워크 상태를 확인합니다.
- Home으로 돌아와 같은 항목을 같은 방식으로 세 번 테스트하고 결과를 기록하세요. 테스트 중에 포트, DNS, 라우팅 설정을 동시에 바꾸지 마세요.
- 해당 항목을 선택하고 연결을 켠 뒤 정해 둔 대상에 접속하세요. 즉시 오류가 나는지, 오래 기다려야 하는지, 페이지의 일부 리소스만 실패하는지 기록합니다.
- 이미 정상 작동하는 다른 항목이 있다면 같은 네트워크와 대상에서 비교할 수 있습니다. 테스트 방식이 다른 결과의 수치를 직접 비교하지 마세요.
| 결과 예시 | 판단할 수 있는 내용 | 다음 단계 |
|---|---|---|
| 세 번 모두 timeout | 테스트가 계속 실패하지만 원인은 아직 확인되지 않음 | 주소, 포트, 네트워크 연결 여부 확인 |
| 120 ms、timeout、135 ms | 결과가 일정하지 않음. 수치는 기록 예시일 뿐임 | 다른 네트워크에서 같은 테스트 반복 |
| TCP 테스트는 성공했지만 웹페이지 접속 실패 | 포트 연결 성공이 인증 성공을 의미하지는 않음 | 프로토콜 설정, TLS, 라우팅 확인 |
| 웹페이지는 열리지만 특정 테스트는 시간 초과 | 테스트 경로와 실제 사용 시 동작이 다름 | 테스트 방식을 확인하고 이 결과만으로 설정을 바꾸지 않기 |
요점: 변수를 고정한 뒤 문제 범위를 판단하세요
같은 항목이 Wi-Fi에서는 실패하고 셀룰러 네트워크에서는 성공한다면, 먼저 Wi-Fi 경로와 접속 제한을 확인하세요. 비밀번호와 DNS를 동시에 바꾸면 어떤 변경이 결과에 영향을 줬는지 알 수 없습니다.
3. 프로토콜, 서버 주소, 포트를 하나씩 확인하기
Home에서 기존 항목의 편집 화면을 열고 직접 저장해 둔 원본 설정과 하나씩 대조하세요. 표시 이름은 메모일 뿐, 서버 주소나 프로토콜이 올바르다는 뜻은 아닙니다. 포트는 원격 서버가 실제로 수신하는 포트와 일치해야 합니다. 원본 설정이 443이라면 그대로 사용하세요. 다른 설정에 8443이 있다고 해서 그대로 복사하면 안 됩니다. 포트가 443이라고 해서 반드시 TLS를 사용한다는 뜻도 아닙니다.
| 프로토콜 | 우선 확인할 항목 | 혼동하기 쉬운 점 |
|---|---|---|
| Shadowsocks | 서버 주소, 포트, 암호화 방식, 비밀번호 | 암호화 방식은 원격 서버 설정과 일치해야 합니다. 비밀번호만 확인해서는 안 됩니다. |
| VMess / VLESS | UUID, 전송 방식, 원본 설정에 지정된 TLS 매개변수 | WebSocket의 Host와 Path는 서버 주소와 다릅니다. |
| Trojan | 비밀번호, 포트, TLS Server Name | IP 주소로 바꿔도 인증서에 필요한 도메인 정보는 올바르게 설정해야 합니다. |
| Hysteria2 | 인증 정보, TLS 설정, UDP 연결 경로 | TCP 포트 테스트로 UDP 연결 상태를 확인할 수 없습니다. |
| WireGuard | PrivateKey, 피어의 PublicKey, Endpoint, 주소, AllowedIPs | 키 역할, UDP 연결 가능 여부, 라우팅 범위는 각각 따로 확인해야 합니다. |
도메인, TLS Server Name, WebSocket Host가 우연히 같은 경우도 있고 원본 설정에서 서로 다르게 지정된 경우도 있습니다. ‘통일’하려고 모두 같은 값으로 바꾸지 마세요. Path의 슬래시와 쿼리 문자열도 빠짐없이 유지해야 합니다. 설정을 복사할 때 앞뒤 공백, 줄바꿈, 잘린 인증 정보가 없는지 확인하세요. 단, 비공개 키·비밀번호·전체 구독 링크를 공개 기록에 붙여 넣지 마세요.
4. timeout만 원인으로 단정하지 말고 오류 메시지로 확인하기
앱에 연결 기록이나 로그가 있다면 이번 요청에 해당하는 오류 문구와 발생 시간을 원문 그대로 보관하세요. 다음은 네트워크 연결에서 흔히 볼 수 있는 오류입니다. 정확한 문구는 프로토콜, 하위 계층의 오류, 앱 화면에 따라 달라질 수 있습니다. 해당 문구가 없다면 그 유형의 오류가 발생했다고 단정하지 마세요.
오류: timeout
원인 및 해결 방법: 작업이 제한 시간 내에 완료되지 않았습니다. 주소 확인, 연결, 핸드셰이크 단계에서 발생했을 수 있으므로 로그의 어느 단계인지 확인한 뒤 같은 설정으로 다른 네트워크에서 다시 테스트하세요.
오류: connection refused
원인 및 해결 방법: 대상 서버나 중간 장치가 연결을 거부했습니다. 주소와 포트를 확인하고 이용 중인 서비스 제공업체에 해당 서비스가 수신 대기 중인지 문의하세요.
오류: no such host
원인 및 해결 방법: 도메인 확인 결과를 얻지 못했습니다. 도메인 철자, 현재 DNS, 기본 네트워크를 확인한 다음 도메인이 여전히 유효한지 확인하세요.
오류: certificate has expired or is not yet valid
원인 및 해결 방법: 인증서 유효 기간과 현재 시간이 맞지 않습니다. 먼저 시스템 날짜와 시간을 정확하게 설정하세요. 시간이 맞는데도 오류가 계속되면 원격 인증서의 유효 기간을 확인하세요.
같은 기록에서 연결 재시도가 먼저 표시되고 마지막에 timeout으로 요약될 수 있습니다. 따라서 마지막 한 줄만 자르지 말고 앞뒤 오류 기록을 함께 보관하세요. 구독 업데이트는 실패했지만 저장된 항목으로는 접속되는 경우에도 두 문제를 따로 기록해야 합니다. 구독을 가져오지 못했다고 해서 기존 원격 연결까지 사용할 수 없어진 것은 아닙니다.
5. Global Routing, Config, DNS 확인하기
Home의 Global Routing은 현재 라우팅 방식을 결정합니다. Proxy, Direct, Config, Scene은 같은 스위치가 아닙니다. Direct는 직접 연결하고, Config는 현재 설정의 규칙에 따라 경로를 선택하며, Scene은 현재 장면 설정까지 확인해야 합니다. 문제를 점검할 때는 기존 값을 먼저 기록하세요. 필요한 경우 고정된 대상을 Proxy로 잠시 테스트한 뒤 원래 설정으로 되돌리세요.
- Home에서 현재 선택된 항목을 확인하고 Global Routing의 기존 값을 기록하세요. 테스트 중 Direct로 설정되어 있지 않은지도 확인합니다.
- Config를 사용한다면 Config에서 현재 적용 중인 구성 파일을 확인하세요. 대상 도메인이나 IP에 어떤 규칙이 적용되는지, 해당 정책이 유효한지 점검합니다.
- Scene을 사용한다면 장면에서 실제로 적용되는 라우팅과 정책을 확인하세요. 장면 이름만 보고 요청 경로를 판단하지 마세요.
- ‘원격 서버 도메인을 확인할 수 없는 경우’와 ‘대상 웹사이트 도메인을 확인할 수 없는 경우’를 구분하세요. 전자는 프록시 연결을 시작하기 전에 실패할 수 있고, 후자는 설정의 DNS와 실제 연결 기록을 함께 확인해야 합니다.
아래는 규칙 문법 예시이며 기존 설정을 덮어쓸 수정 파일이 아닙니다. 규칙은 일반적으로 순서대로 적용되므로 앞쪽 규칙이 일치하면 뒤의 규칙은 이번 경로 선택에 적용되지 않을 수 있습니다. DOMAIN-SUFFIX는 도메인 접미사를 기준으로 일치 여부를 확인하고, IP-CIDR과 GEOIP는 IP 조건에 사용합니다. FINAL은 앞선 규칙에 해당하지 않을 때 적용되는 기본 정책입니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY여기서 no-resolve는 해당 IP 규칙의 일치를 확인하기 위해 도메인 확인을 새로 실행하지 않는다는 뜻입니다. 전체 구성의 DNS를 끈다는 의미는 아닙니다. 고정된 대상이 Proxy에서는 열리지만 Config에서는 실패한다면 원격 서버 비밀번호를 다시 바꾸기보다 규칙과 정책을 먼저 확인하세요. 특정 도메인 하나를 고치려고 규칙 전체를 삭제하지 마세요.
6. 마지막으로 시스템 시간, 네트워크 경로, On Demand 확인하기
시간이 잘못되면 인증서 유효 기간 판정이나 시간 확인이 필요한 인증 과정에 영향을 줄 수 있습니다. iPhone 또는 iPad의 시스템 설정에서 ‘일반 → 날짜 및 시간’으로 이동해 ‘자동으로 설정’과 실제 날짜·시간·시간대를 확인하세요. 중요한 것은 시스템 시간이 정확한지 여부입니다. 시간대 표시가 다르다는 사실만으로 반드시 오류라고 볼 수는 없습니다. 기기 관리 정책으로 옵션이 제한되어 있다면 해당 기기의 관리 지침을 따르세요.
- Wi-Fi와 셀룰러 네트워크 비교: 같은 항목, 대상, 라우팅 설정을 유지한 채 각 네트워크에서 한 번씩 테스트하세요. 특정 네트워크에서만 실패한다면 해당 네트워크의 DNS, 접속 제한, UDP 연결 가능 여부를 먼저 확인하세요.
- 네트워크 인증: 호텔, 학교, 공공 Wi-Fi에서는 먼저 웹페이지 인증을 완료해야 할 수 있습니다. 기본 네트워크 접속이 허용되지 않은 상태에서는 프로토콜 설정을 바꿔도 연결에 도움이 되지 않습니다.
- On Demand: Settings → On Demand에서 요청 시 연결 조건을 확인하세요. 수동으로 연결을 끊어도 바로 다시 연결되거나 네트워크를 바꾼 뒤 상태가 자동으로 바뀐다면 관련 조건을 잠시 끄고 수동 테스트를 마친 뒤 다시 켜세요.
- 시스템 VPN 상태: 다른 VPN 연결이 트래픽을 처리하고 있는지 확인하세요. 용도를 모르는 상태에서 기기 관리 설정을 삭제하지 마세요. 현재 실제로 활성화된 연결이 무엇인지 먼저 확인하세요.
- 구독 업데이트: 기존에 작동하던 항목과 설정 백업을 보관하세요. 원래 구독 내용이 바뀐 것을 확인한 경우에만 업데이트하세요. 연결 문제 해결과 설정 교체를 한 번에 처리하지 마세요.
요점: 모든 설정이 아니라 필요한 최소한의 재현 정보를 전달하세요
문제가 계속되면 이용 중인 서비스 제공업체에 발생 시간, 네트워크 종류, 프로토콜, 포트, 세 번의 테스트 결과, 민감 정보를 가린 오류 기록을 전달하세요. 공개 스크린샷에 비밀번호, PrivateKey, 전체 UUID, 구독 token이 포함되지 않도록 주의하세요.
7. 자주 묻는 질문과 복구 후 확인 사항
지연 시간 수치는 나오는데 웹페이지가 열리지 않는 이유는 무엇인가요?
먼저 테스트 방식을 확인하세요. TCP 테스트 성공은 해당 테스트에서 포트 연결이 성공했다는 뜻일 뿐입니다. Home으로 돌아가 선택한 항목과 Global Routing을 확인하고, 실제 요청이 인증·TLS·DNS·규칙 중 어느 단계에서 실패했는지 살펴보세요.
Wi-Fi에서는 시간 초과가 발생하고 셀룰러 네트워크에서는 정상이라면 앱을 다시 설치해야 하나요?
먼저 다시 설치하지 마세요. 같은 설정으로 차이를 반복해서 확인한 다음 Wi-Fi 인증, DNS, 네트워크 제한을 점검하세요. 앱을 다시 설치해도 네트워크가 특정 포트나 UDP 경로를 제한하는 문제는 해결되지 않습니다.
구독 업데이트 후 연결에 실패했습니다. 기존 항목을 모두 삭제해도 되나요?
먼저 기존 설정을 보관하고 업데이트 전후의 주소, 포트, 프로토콜 설정을 비교하세요. 목록이 비었거나 내용이 누락됐다면 구독을 가져오는 문제부터 해결해야 합니다. 백업 없이 기존 항목을 삭제하면 비교에 사용할 기록을 잃게 됩니다.
연결이 복구된 뒤 어떤 설정을 다시 확인해야 하나요?
문제 해결을 시작하기 전의 Global Routing과 On Demand 조건을 복원한 뒤 평소 이용하는 대상으로 다시 테스트하세요. 실제로 효과가 있었던 수정은 유지하고 임시 비교 설정은 되돌리세요. 이번 문제의 원인이었던 항목이나 네트워크 조건을 기록해 두세요.
문제 해결은 스위치가 켜졌는지가 아니라 ‘특정 변경에 따라 결과가 반복해서 달라지는지’를 확인하고 마무리해야 합니다. 기존 항목이 두 네트워크 모두에서 실패하지만 기본 네트워크는 정상이라면 공통으로 사용하는 설정, 시스템 시간, 원격 서버 상태를 집중적으로 확인하세요. 특정 대상만 실패한다면 해당 대상의 주소 확인과 규칙을 더 세밀하게 살펴보세요.