연결 스위치가 켜졌다는 사실만으로 로컬 연결이 시작된 것일 뿐, 서버와 도메인 이름 확인, 대상 웹사이트가 모두 정상이라는 뜻은 아닙니다. 이미 본인 서버 정보나 구독을 보유한 사용자를 위한 안내입니다. 먼저 기본 네트워크를 확인한 다음 서버, Global Routing, DNS, 규칙을 차례로 점검하세요. 한 번에 한 가지 설정만 바꾸고, 테스트가 끝나면 평소 설정으로 되돌립니다.
01 ‘연결됨’과 ‘요청 성공’ 구분하기
Shadowrocket의 연결 상태, 서버 지연 시간 테스트, 웹페이지 로딩은 서로 다른 확인 지점입니다. 상태 막대에 VPN 표시가 나타나도 원격 서버 인증이 완료됐다는 뜻은 아닙니다. 지연 시간 테스트에서 값이 표시돼도 웹페이지에 필요한 DNS, TLS, 후속 리소스 요청이 모두 성공한 것은 아닙니다. 연결 스위치를 반복해서 켜고 끄기보다 먼저 나타난 증상을 기록하면 원인을 더 쉽게 좁힐 수 있습니다.
시작하기 전에 현재 서버, Global Routing 옵션, 사용 중인 Config, 열리지 않는 웹페이지의 도메인을 기록하세요. 평소 바로 접속할 수 있는 웹페이지 하나와 현재 열리지 않는 웹페이지 하나를 비교 대상으로 정합니다. 한 웹사이트만 안 된다고 해서 모든 네트워크가 작동하지 않는다고 단정하지 마세요.
-
기본 네트워크 확인
먼저 Settings → On Demand에서 자동 연결 설정을 확인하고 잠시 끈 다음, Home으로 돌아가 연결 스위치를 끄세요. Safari에서 평소 바로 접속할 수 있는 웹페이지를 엽니다. 그래도 열리지 않으면 Wi-Fi 로그인 인증, 셀룰러 데이터 권한 또는 네트워크 자체 문제부터 해결하세요.
-
테스트 조건 고정하기
같은 네트워크, 같은 웹페이지, 같은 기기를 유지한 채 Home으로 돌아가 본인 서버를 선택하고 연결을 켭니다. 테스트 중에는 Wi-Fi, 서버, Config를 동시에 바꾸지 마세요. 어떤 변경으로 결과가 달라졌는지 판단하기 어렵습니다.
-
실패 범위 기록하기
‘모든 웹페이지가 열리지 않음’, ‘일부 도메인만 열리지 않음’, ‘웹페이지는 열리지만 이미지가 표시되지 않음’, ‘특정 App만 실패’ 중 어떤 상황인지 각각 기록하세요. 발생 시각과 당시 Global Routing 옵션도 함께 적어 두면 나중에 요청 기록과 비교하기 쉽습니다.
-
설정 하나씩 바꾸고 재테스트하기
한 번에 설정 하나만 바꾼 뒤 같은 요청을 다시 시도하세요. 필요한 경우 연결을 끈 다음 다시 켭니다. 개선되지 않으면 해당 설정을 원래 값으로 되돌리고 다음 단계로 넘어가세요. 여러 임시 설정을 한꺼번에 적용하지 않는 것이 좋습니다.
02 서버 연결 가능 여부와 기존 구독 확인하기
Home에서 Connectivity Test로 기존 서버를 점검하고, 테스트하려는 항목이 현재 선택되어 있는지 확인하세요. 결과는 테스트 방식과 대상에 따라 달라집니다. 포트 연결이 되더라도 프로토콜 인증에 성공한 것은 아니며, 테스트 대상에 접속할 수 있어도 다른 웹사이트까지 접속된다는 뜻은 아닙니다. 테스트 결과와 브라우저의 실제 요청을 함께 확인하세요.
현재 항목의 편집 화면을 열어 Type, 서버 주소, 포트, 인증 정보를 하나씩 확인하세요. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 서로 같은 매개변수를 사용하지 않습니다. 항목 하나가 시간 초과됐다고 다른 프로토콜로 임의 변경하지 마세요. TLS를 사용하는 경우 서비스 제공자가 안내한 서버 이름과 관련 매개변수도 확인하고, 설정 오류를 감추려고 인증서 검증을 끄지 마세요.
- 항목 하나만 실패하는 경우: 본인이 보유한 다른 사용 가능한 항목이 있다면 다른 조건은 그대로 둔 채 바꿔서 테스트하세요. 결과 차이를 통해 문제가 해당 서버나 설정에 집중되어 있는지 판단할 수 있습니다.
- 같은 네트워크에서 모두 실패하는 경우: 먼저 기본 네트워크를 확인한 다음, 본인이 사용할 수 있는 다른 네트워크에서도 테스트하세요. 네트워크를 바꿔서 문제가 해결되더라도 경로가 다르다는 점만 확인할 수 있을 뿐, 인증 정보가 올바르다고 단정할 수는 없습니다.
- 전에는 됐는데 지금은 실패하는 경우: 본인이 이용 중인 서비스의 유효 기간, 트래픽 상태, 점검 공지를 확인하세요. 기존 구독을 업데이트한 뒤 현재 선택된 항목도 다시 확인합니다.
- 구독 업데이트에 성공했는데도 실패하는 경우: 업데이트 성공은 구독 내용을 가져왔다는 뜻이지, 모든 서버가 사용 가능하다는 뜻은 아닙니다. 업데이트가 완료됐는지만 보지 말고 선택된 항목도 확인하세요.
03 Global Routing으로 비교 테스트하기
서버가 기본적으로 작동하는 것을 확인했다면 Home → Global Routing에서 현재 옵션을 확인하세요. Proxy, Direct, Config, Scene은 서로 다른 라우팅 방식입니다. 연결 스위치만 보고 트래픽이 어디로 향하는지 판단할 수는 없습니다. 점검을 시작할 때 원래 옵션을 기록하고 Proxy와 Config를 잠시 비교한 뒤, 테스트가 끝나면 평소 설정으로 되돌리세요.
| 옵션 | 점검할 항목 | 결과 해석 |
|---|---|---|
Proxy | 일반 요청을 프록시 경로로 보내고 현재 프록시 선택을 확인합니다. | 같은 웹페이지가 여기서는 열리지만 Config에서는 실패한다면 규칙과 정책 선택을 먼저 확인하세요. DNS 차이도 살펴봐야 합니다. |
Direct | 요청을 직접 연결 경로로 보냅니다. | 서버를 선택해도 요청이 해당 서버를 사용한다는 뜻은 아닙니다. 직접 접속할 수 있는 웹페이지로 기본 상태만 비교하세요. |
Config | 현재 설정의 규칙에 따라 요청을 처리합니다. | 예상한 Config가 활성화되어 있는지 확인한 뒤, 실패한 요청에 적용된 규칙과 최종 정책을 살펴보세요. |
Scene | 현재 Scene과 연결된 설정을 확인합니다. | Scene에 따라 실제 라우팅 설정이 달라질 수 있으므로 서버를 직접 선택했더라도 최종 경로를 단정할 수 없습니다. |
Proxy와 Config에서 모두 실패한다면 규칙을 바로 추가하지 말고 서버와 DNS를 계속 확인하세요. Proxy에서는 열리지만 Config에서는 열리지 않는다면 Config에서 대상 도메인이 DIRECT, REJECT 또는 사용할 수 없는 정책 그룹으로 전달되는지 중점적으로 살펴보세요. 이 비교 결과는 원인을 좁히는 단서일 뿐, 서버가 완전히 정상임을 증명하는 유일한 근거는 아닙니다.
04 지연 시간은 정상인데 웹페이지가 열리지 않을 때 DNS 확인하기
웹페이지에 접속하려면 먼저 도메인을 IP 주소로 확인해야 합니다. 지연 시간 테스트가 서버 포트만 확인하거나 웹페이지와 다른 대상을 테스트하면 ‘지연 시간은 정상인데 웹페이지가 열리지 않는’ 상황이 생길 수 있습니다. Settings → DNS에서 현재 설정을 확인하고, 활성화된 Config에 본인의 DNS 설정이 들어 있는지도 살펴보세요. 한쪽만 바꾸고 다른 설정을 빠뜨리지 않도록 주의해야 합니다.
먼저 현재 설정을 저장한 다음, 작동하지 않는 사용자 지정 DNS 주소나 특정 네트워크에서만 접속 가능한 리졸버, 불완전한 암호화 DNS 주소가 있는지 확인하세요. 출처가 불분명한 주소를 여러 개 계속 추가하지 마세요. 리졸버 자체에 접속할 수 없다면 주소를 늘려도 해결되지 않을 수 있으며, 원인을 비교하기만 더 어려워집니다.
여기에 나온 값은 각 프로토콜에서 흔히 사용하는 포트이지, 서버 항목에 일괄 입력해야 하는 값이 아닙니다. 서버 포트는 서비스 제공자가 안내한 값으로 유지하세요. DoH 엔드포인트에 호스트 이름이 포함된 경우 해당 호스트 이름을 먼저 확인해야 합니다. 리졸버에 접속할 때 프록시가 필요한데 프록시가 작동하지 않으면 DNS 확인도 실패할 수 있습니다.
- 먼저 이전 설정으로 비교: 최근 추가한 사용자 지정 DNS 설정을 잠시 되돌리고, 이전에 작동했던 설정을 복원한 다음 연결을 다시 설정해 같은 도메인을 여세요.
- 다음으로 실패 단계 확인: 요청이 DNS 확인 결과를 얻지 못한 것인지, 주소를 받은 후 연결 또는 TLS 단계에서 실패한 것인지 구분하세요. 후자의 경우 DNS만 바꿔서는 해결되지 않습니다.
- IP 주소 웹페이지로 판단하지 않기: HTTPS 웹사이트는 도메인에 연결된 인증서, SNI, 가상 호스트를 사용할 수 있습니다. IP 주소로 직접 접속이 안 된다고 해서 네트워크가 끊겼다고 단정할 수는 없습니다.
05 규칙 순서, 정책, FINAL 확인하기
Config에서만 문제가 발생한다면 Config를 열어 현재 사용 중인 설정을 확인한 다음 규칙을 살펴보세요. 규칙은 일반적으로 위에서 아래 순서로 매칭되며, 먼저 일치한 규칙이 정책을 결정합니다. 앞선 규칙에 일치하지 않은 요청은 FINAL이 처리합니다. 따라서 올바른 규칙을 추가하더라도 너무 앞에 있는 FINAL 뒤에 배치하면 기대한 대로 작동하지 않습니다.
아래 내용은 문법 설명이며, 현재 설정 전체를 그대로 교체하라는 뜻이 아닙니다. example.com과 192.0.2.0/24는 예시입니다. 실제 규칙은 본인의 대상과 정책 구성에 맞춰야 합니다.
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXYDOMAIN-SUFFIX,example.com,PROXY: 해당 도메인과 하위 도메인에 매칭되어 PROXY로 전달됩니다. 웹페이지 로딩에 사용되는 다른 독립 도메인까지 자동으로 포함하지는 않습니다.IP-CIDR,192.0.2.0/24,DIRECT,no-resolve: 대상 IP 주소 대역을 기준으로 매칭합니다.no-resolve는 이 규칙을 위해 도메인 확인을 따로 시작하지 않는다는 뜻이며, 요청 전체에 DNS가 필요하지 않다는 의미는 아닙니다.GEOIP,CN,DIRECT: 대상 IP의 지리 데이터베이스 분류를 기준으로 매칭합니다. 웹사이트의 문구나 도메인 접미사로 지역을 판단하는 규칙이 아닙니다.FINAL,PROXY: 앞선 규칙에 매칭되지 않은 요청을 처리합니다. 실제 설정이 DIRECT 또는 REJECT라면 의도한 동작인지 확인하세요.
다시 테스트할 때 앱 내 요청 기록에서 방금 테스트한 시각과 도메인으로 요청을 찾아 매칭된 규칙과 실제 정책을 확인하세요. PROXY에 매칭됐는데도 실패한다면 해당 서버나 정책 그룹을 확인해야 합니다. REJECT에 매칭됐다면 우선 범위가 너무 넓은 규칙이 요청을 차단하는지 살펴보세요. 웹페이지 하나를 열기 위해 모든 규칙을 삭제하지 마세요. 먼저 백업하고 변경 범위를 좁히세요.
06 오류 문구로 다음 단계 결정하기
오류 문구는 표시된 위치와 함께 살펴봐야 합니다. 아래에는 연결 또는 DNS 기록에서 흔히 볼 수 있는 영어 오류 문구를 정리했습니다. 대소문자나 추가 정보는 다를 수 있습니다. 브라우저에 표시되는 막연한 ‘웹페이지를 열 수 없음’만으로는 실패 단계를 구분하기 어려우므로 같은 시각의 앱 내 기록도 확인하세요.
오류: Connection refused
원인 및 해결: 대상 주소 또는 경로상의 기기가 연결을 거부한 상태입니다. 포트에서 서비스가 수신 대기 중이지 않거나 접속이 거부됐을 때 흔히 발생합니다. 본인 서버의 주소와 포트를 확인한 뒤 서비스 제공자에게 수신 대기 상태를 문의하세요. 바로 비밀번호 오류로 단정하지 마세요.
오류: Connection timed out
원인 및 해결: 제한 시간 안에 연결이 완료되지 않은 상태입니다. 경로, 서버 상태, 방화벽과 관련됐을 수 있습니다. 설정을 그대로 유지하고 본인이 사용할 수 있는 다른 네트워크에서 다시 테스트한 뒤, 특정 서버 하나에서만 발생하는지 기록하세요.
오류: NXDOMAIN
원인 및 해결: DNS가 도메인이 존재하지 않는다고 응답한 상태입니다. 도메인 오타나 비정상적인 DNS 응답이 원인일 수 있습니다. 먼저 전체 도메인을 확인하고, 이전에 정상 작동했던 DNS 설정으로 다시 테스트하세요. 서버 목록을 반복해서 새로 고쳐도 도메인 오타는 해결되지 않습니다.
TLS 인증서 오류가 있다면 기기의 날짜와 시간, 서버 이름, 서비스 제공자의 인증서 설정도 확인하세요. 웹페이지에서 명확한 HTTP 상태 코드가 반환됐다면 최소 한 번은 HTTP 응답을 받은 것입니다. 이 경우 모든 실패를 DNS 문제로 취급하지 말고 상태 코드에 따라 웹사이트나 접속 정책을 확인하세요.
07 자주 묻는 질문과 설정 복원
Connectivity Test에 값이 표시되는데도 왜 웹페이지가 열리지 않나요?
먼저 Home → Global Routing에서 현재 옵션을 기록하고 같은 웹페이지를 Proxy와 Config에서 비교하세요. 지연 시간 테스트는 웹페이지의 모든 요청을 확인하지 않습니다. 실패한 시각을 기준으로 DNS 응답, 적용된 정책, 연결 오류를 살펴보세요.
Proxy로 전환하면 열리는데 계속 이렇게 사용해도 되나요?
라우팅 방식에 따라 결과가 달라졌다는 뜻이지 규칙 문제가 해결됐다는 뜻은 아닙니다. Config로 돌아가 대상 도메인의 규칙 위치, 정책 그룹, FINAL을 확인하세요. 수정한 다음 원래 라우팅 방식으로 복원하고 같은 웹페이지를 다시 테스트하세요.
연결을 껐는데 다시 자동으로 켜져요. 기본 테스트는 어떻게 하나요?
Settings → On Demand에서 현재 설정을 기록하고 자동 연결을 잠시 끈 다음, Home으로 돌아가 연결을 끄세요. 점검을 마치면 원래 On Demand 설정을 복원해 테스트 설정이 일상 구성으로 남지 않도록 하세요.
구독을 업데이트한 뒤 서버를 다시 선택해야 하나요?
Home으로 돌아가 현재 항목을 확인해야 합니다. 업데이트로 항목의 내용이나 이름이 바뀔 수 있습니다. 선택한 항목을 확인한 다음 Connectivity Test와 실제 웹페이지 테스트를 진행하세요. 구독 업데이트 성공만으로 회선이 사용 가능하다고 판단할 수는 없습니다.
먼저 앱을 삭제한 뒤 다시 설치해야 하나요?
우선 앞서 안내한 단계별 점검을 완료하세요. 재설치로 원격 서버나 네트워크 경로 문제를 해결할 수는 없으며, 로컬 설정이 사라질 수도 있습니다. 재설치가 꼭 필요하다면 먼저 설정을 백업하고 본인의 구독 및 인증 정보를 안전하게 보관하세요.
점검이 끝나면 기존 네트워크와 대상 웹페이지를 사용해 다시 테스트하고, 임시로 변경했던 Global Routing, DNS, On Demand 설정을 복원하세요. 실패 시각, 네트워크 유형, 사용한 서버, 적용된 정책, 오류 문구, 효과가 있었던 변경 사항을 간단히 기록해 두세요. 추가 문의 시 민감 정보를 가린 기록만 제공하세요. 구독의 token, 비밀번호, 개인 키가 스크린샷이나 공개 메시지에 노출되지 않도록 주의하세요.