2026-10-15 · 문제 해결 · 약 9분

Shadowrocket 연결은 켜졌는데 인터넷이 안 될 때: 서버·모드·DNS·규칙 점검

연결을 켰는데 웹페이지가 열리지 않나요? 서버 상태, Global Routing 모드, DNS 설정, FINAL·REJECT 규칙을 차례로 확인해 원인을 좁혀 보세요.

이 글의 핵심

Shadowrocket의 연결 스위치가 켜져 있다는 것은 기기의 연결 상태를 뜻할 뿐, 서버·DNS·대상 웹사이트가 모두 정상이라는 의미는 아닙니다. 이미 사용할 서비스와 설정이 있다는 전제하에 기본 네트워크, 서버 매개변수, Global Routing, DNS, 규칙 순서로 점검합니다. 한 번에 하나씩만 변경하고 같은 주소로 다시 테스트한 뒤 평소 설정으로 복원하세요.

1. 기기 내 터널과 실제 요청 구분하기

시스템에 VPN 상태가 표시되면 기기에 로컬 네트워크 경로가 설정된 것입니다. 원격 서버가 연결을 받아들이는지, 도메인이 제대로 조회되는지, 규칙에 따라 요청이 어디로 전달되는지는 각각 따로 확인해야 합니다. 스위치가 켜져 있다는 이유만으로 브라우저에 문제가 있다고 단정하거나, 모든 페이지 오류를 DNS 문제로 돌리지 마세요.

앱 요청 기기 내 터널 이름 조회 및 라우팅 외부 연결 대상 응답

이 흐름은 점검 범위를 나누기 위한 것으로, 모든 요청이 반드시 같은 순서로 이름 조회와 라우팅을 거친다는 뜻은 아닙니다. 도메인 규칙이 먼저 적용될 수 있고, 일부 IP 규칙은 조회 결과가 필요할 수 있습니다. 먼저 아래 항목을 비교해 기본 네트워크부터 작동하지 않는지 확인하세요.

  1. 현재 Home에서 선택한 서버, Global Routing 모드, Config에서 활성화한 설정을 기록하고 변경 전에 복원할 수 있는 사본을 보관하세요.
  2. Shadowrocket을 잠시 끄고 Safari에서 평소 바로 접속되는 웹페이지를 열어 보세요. 그래도 접속되지 않으면 먼저 Wi-Fi 인증 페이지를 완료하거나 셀룰러 데이터 권한과 현재 네트워크 상태를 확인하세요.
  3. 기본 네트워크가 복구되면 연결을 다시 켜고 같은 웹페이지에 접속해 보세요. 모든 사이트가 안 되는지, 일부 도메인만 안 되는지, 특정 앱만 실패하는지 기록하세요.
  4. 가능하다면 Wi-Fi와 셀룰러 데이터에서 각각 다시 테스트하세요. 네트워크를 전환한 뒤 새 요청을 보내고, 이전 페이지의 캐시 결과를 새 테스트 결과로 착각하지 마세요.

2. Home의 서버와 기존 구독 확인하기

Home에서 현재 선택된 서버가 유효한 본인 설정에 포함된 항목인지, 만료된 예전 항목은 아닌지 확인하세요. Connectivity Test 결과는 연결 가능성을 판단하는 참고 자료일 뿐, 테스트 대상과 방식은 실제 웹사이트 접속과 다를 수 있습니다. 지연 시간이 표시되어도 모든 웹페이지에 접속할 수 있다는 뜻은 아니며, 테스트 시간 초과도 실제 연결 기록과 함께 판단해야 합니다.

항목이 구독에서 가져온 것이라면 구독 업데이트가 성공했는지, 목록에 오래된 정보가 남아 있는지 확인하세요. 업데이트가 필요하면 Home에서 기존 구독을 갱신하고 Settings → Subscribe에서 관련 설정을 확인하세요. 구독 업데이트는 설정을 가져오는 과정이고 서버 연결은 실제 외부 연결이므로 서로 다른 요청입니다. 업데이트에 성공해도 항목이 작동한다는 보장은 없으며, 업데이트 실패만으로 기존 항목이 모두 만료되었다고 볼 수도 없습니다.

오류: connection refused

원인 및 해결: 일반적으로 대상 주소나 중간 장비가 연결을 명시적으로 거부했다는 뜻입니다. 먼저 해당 연결 기록이 서버와 대상 웹사이트 중 어디를 가리키는지 확인한 다음 주소, 포트, 원격 서버의 대기 상태를 점검하세요. DNS부터 변경하지 마세요.

오류: i/o timeout

원인 및 해결: 어떤 I/O 작업이 시간 초과되었다는 의미입니다. 이 한 줄만으로는 문제가 발생한 위치를 알 수 없으므로 앞뒤 기록을 확인해 이름 조회, 서버 연결, 대상 접속 중 어디에서 발생했는지 판단하고 다른 기본 네트워크에서도 비교하세요.

위 내용은 연결 기록에 나타날 수 있는 오류의 일부이며, 모든 기기에 같은 메시지가 표시되는 것은 아닙니다. 점검 정보를 공유할 때는 오류 원문과 발생 단계를 남기고 비밀번호, UUID, 개인 키, 구독 token은 가리세요. 전체 설정을 공개하지 마세요.

3. Global Routing으로 모드와 규칙 비교하기

Home → Global Routing에서 현재 모드를 확인하세요. Proxy, Direct, Config, Scene은 각각 용도가 다르므로 연결이 켜졌다고 모든 요청이 선택한 서버를 사용하는 것은 아닙니다. 특히 Direct에서는 스위치가 켜져 있어도 요청이 자동으로 원격 프록시를 거치지 않습니다.

4가지
Global Routing 모드: Proxy / Direct / Config / Scene
53
기존 DNS에서 흔히 사용하는 포트로, 일반적으로 UDP를 사용하며 TCP도 사용할 수 있음
443
HTTPS와 DoH에서 주로 사용하는 포트로, 연결 가능 여부를 보장하지 않음
모드설명점검 방법
Proxy요청을 프록시로 처리선택한 프록시 경로를 잠시 테스트해 Config 규칙 분할의 영향을 확인
Direct요청을 직접 연결로 처리현재 네트워크의 직접 연결 상태를 비교하며, 원격 서버가 작동한다는 증거는 아님
Config현재 설정된 규칙에 따라 요청 처리 방식을 결정적용된 규칙, 정책 그룹, 최종 연결 경로 확인
Scene설정된 Scene에 따라 라우팅 선택현재 네트워크에 적용되는 Scene과 실제 활성 설정 확인

서버와 접속 주소를 그대로 둔 채 Proxy와 Config를 잠시 전환해 비교하세요. Proxy에서는 접속되고 Config에서는 실패한다면 규칙과 정책 그룹을 중점적으로 확인하되, 두 모드의 DNS나 요청 경로가 다를 수도 있습니다. 두 모드 모두 실패한다면 설정 전체를 바로 삭제하지 말고 서버, 기본 네트워크, DNS를 계속 점검하세요.

Scene은 기존 Scene 설정을 함께 살펴봐야 하며 Config와 같다고 가정할 수 없습니다. 테스트가 끝나면 원래 모드로 복원하세요. 비교 목적으로 사용한 Proxy를 평소 설정의 대안으로 간주해서는 안 됩니다.

4. 근거가 있을 때만 DNS 변경하기

DNS는 도메인을 주소로 변환합니다. 서버 주소 자체가 도메인이라면 원격 서버에 연결하기 전부터 조회가 필요할 수 있으며, 웹페이지 도메인도 별도의 조회 과정을 거칠 수 있습니다. 따라서 ‘서버 도메인을 조회하지 못함’과 ‘대상 웹페이지 도메인을 조회하지 못함’을 구분해 기록하세요.

  1. 문제가 발생하는 범위 확인: 평소 사용하는 도메인 두 개를 각각 테스트하세요. 하나의 도메인에서만 실패한다면 전체 설정을 바로 바꾸지 말고 해당 도메인과 DNS 레코드부터 확인하세요.
  2. 적용 중인 설정 확인: Config에서 실제 사용 중인 파일을 확인하고 DNS 관련 항목을 살펴본 뒤 Settings에서 활성화된 DNS 옵션과 대조하세요. 활성화되지 않은 설정 파일만 확인해서는 문제를 진단할 수 없습니다.
  3. 상위 DNS 서버 연결 확인: 사용자 지정 DNS 주소는 현재 경로를 통해 접속할 수 있어야 합니다. DoH를 사용하는 경우 HTTPS 연결과 인증서 검증, DoH 서비스 도메인 조회도 선행 조건이 될 수 있습니다.
  4. 한 항목만 되돌리기: DNS 변경 후 문제가 발생했다면 먼저 변경 전 설정으로 복원한 뒤 다시 연결하고 요청을 보내세요. DNS, 서버, 규칙을 한꺼번에 바꾸면 어떤 변경이 영향을 줬는지 파악할 수 없습니다.

연결 기록에 인증서 이름 불일치나 만료가 표시되면 기기의 날짜와 시간, 서비스 매개변수의 서버 이름, 원격 서버 인증서를 먼저 확인하세요. 인증서 검증을 끄는 방식으로 문제를 감추지 말고 TLS 오류를 일반적인 DNS 시간 초과로 취급하지 마세요.

5. FINAL·REJECT와 규칙 순서 확인하기

주로 Config 모드에서 문제가 발생한다면 현재 Config를 열고 규칙 순서에 따라 대상 도메인에 어떤 규칙이 적용되는지 확인하세요. 규칙은 대체로 위에서 아래로 매칭되므로 앞쪽 규칙에 이미 적용되면 뒤의 예외 규칙까지 진행하지 않습니다. 맨 아래에 허용 규칙을 추가해도 앞쪽의 REJECT를 덮어쓸 수는 없습니다.

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

이 내용은 문법 설명용입니다. example.com과 192.0.2.0/24는 예시이므로 이 부분을 통째로 현재 설정에 붙여 넣지 마세요. 예시의 FINAL,DIRECT는 앞선 규칙에 매칭되지 않은 요청을 최종적으로 직접 연결한다는 뜻이며, 모든 사용자가 이 정책을 사용해야 한다는 의미는 아닙니다.

페이지는 열리지만 이미지, 로그인, API 요청이 실패한다면 주소 표시줄의 대표 도메인뿐 아니라 실패한 리소스의 도메인도 확인하세요. 규칙이 잘못 적용된 것이 확실하다면 먼저 백업한 뒤 해당 규칙의 범위, 순서 또는 정책을 조정하세요. 재테스트가 통과하면 변경을 최소한으로 유지하고, 한 페이지를 고치려고 모든 거부 규칙을 삭제하지 마세요.

6. 증상별 재테스트 후 최소한의 기록 남기기

한 항목을 변경할 때마다 기존 접속 주소로 다시 테스트하세요. 네트워크 유형, 서버 항목 이름, Global Routing 모드, 실패한 도메인, 오류 원문, 테스트 시간을 기록하면 일시적 오류와 반복되는 문제를 구분하는 데 도움이 됩니다. 아래 문답으로 자주 발생하는 경우를 정리합니다.

“지연 시간 테스트에는 숫자가 나오는데 웹페이지는 왜 열리지 않나요?”

테스트 성공은 해당 테스트의 대상과 경로에만 적용됩니다. Home에서 선택한 항목을 확인한 다음 같은 웹페이지로 Proxy와 Config를 각각 비교하세요. Config에서만 실패한다면 해당 도메인의 규칙과 최종 정책을 확인하세요.

“Wi-Fi에서만 안 되고 셀룰러 데이터로 전환하면 되나요?”

먼저 연결을 끄고 Wi-Fi 인증이 완료되었는지 확인한 뒤 서버와 설정을 그대로 두고 다시 테스트하세요. 해당 Wi-Fi에서만 계속 실패한다면 DNS, 관련 포트, UDP 경로의 연결 가능성을 확인하세요. 이것만으로 설정 전체가 잘못되었다고 단정하지 마세요.

“웹페이지는 정상인데 특정 앱이 계속 로딩 중이면 어떻게 하나요?”

앱을 다시 열고 실제로 요청하는 도메인을 확인하세요. API, 미디어, 로그인 요청이 REJECT되거나 다른 정책으로 분기되는지 살펴보세요. 대표 웹페이지가 열린다고 해서 앱에 필요한 모든 도메인도 정상이라는 뜻은 아닙니다.

“구독 업데이트가 실패했는데 서버 항목을 전부 삭제해야 하나요?”

먼저 목록을 비울 필요는 없습니다. 현재 항목을 보존하고 구독 링크 상태를 확인한 뒤 Settings → Subscribe에서 업데이트 관련 설정을 살펴보세요. 기존 매개변수가 유효하지 않다고 확인된 경우에만 본인의 유효한 서비스 정보를 기준으로 업데이트하세요.

원인을 찾지 못했다면 민감 정보를 가린 오류 내용과 위 비교 결과를 본인의 서비스 지원 담당자에게 전달하세요. Shadowrocket 앱 구매와 원격 서비스 상태는 별개입니다. 앱을 다시 받아도 만료된 서버나 잘못된 규칙은 복구되지 않습니다. 이 사이트는 서버나 구독을 제공·판매·추천하지 않습니다.

App Store에서 Shadowrocket 다운로드