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

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

연결 스위치는 켜져 있지만 웹페이지가 열리지 않나요? 서버 연결, Global Routing 모드, DNS 설정, 규칙 매칭을 차례로 확인하는 방법을 안내합니다.

이 글의 핵심

Shadowrocket의 연결 스위치가 켜졌다는 것은 시스템 터널이 활성화되었다는 뜻이지, 서버와 도메인 확인, 대상 웹사이트까지 모두 정상이라는 뜻은 아닙니다. 이미 이용 중인 서비스 제공업체와 구독이 있다는 전제로 서버, Global Routing, DNS, 규칙 순서로 문제 범위를 좁혀 보세요. 한 번에 한 가지 설정만 바꾸고 같은 주소로 다시 확인한 뒤, 마지막에는 기존 분할 라우팅 설정으로 되돌립니다.

점검 전 확인: 터널·서버·웹 요청 구분하기

앱을 삭제하거나 설정 전체를 다시 만들 필요는 없습니다. VPN 표시, 서버 지연 시간, 웹페이지 로딩은 각각 다른 단계를 보여 줍니다. 시스템에서 VPN 구성을 허용했더라도 원격 서버의 프로토콜 인증이 완료된 것은 아닙니다. 지연 시간 테스트에 응답이 와도 웹페이지에 필요한 도메인, 포트, 규칙 경로가 올바르다는 보장은 없습니다. 먼저 증상을 구체적으로 확인한 뒤 해당 단계만 점검하세요.

앱에서 요청 전송 시스템 터널이 트래픽 처리 DNS 확인 및 규칙 판단 직접 연결 또는 프록시로 전송 대상에서 데이터 응답

이 흐름은 점검 단계를 찾기 위한 것으로, 모든 연결이 규칙 매칭 전에 반드시 DNS 확인을 거쳐야 한다는 뜻은 아닙니다. 도메인 규칙은 호스트 이름을 기준으로 바로 판단할 수 있지만, IP 규칙에는 DNS 조회 결과가 관여할 수 있습니다. 아래 절차는 iPhone / iPad 화면을 기준으로 합니다. 시작 전에 Home에서 선택된 서버, Global Routing 값, Config에서 사용 중인 구성 파일을 기록해 두세요.

1단계: 선택한 서버가 실제로 연결되는지 확인

Home으로 이동해 선택 표시가 구독 그룹을 펼친 항목이 아니라 테스트하려는 서버에 있는지 확인합니다. 연결 스위치를 켠 다음 Connectivity Test를 실행하고 테스트 완료 여부와 표시된 내용을 기록하세요. 이 테스트는 해당 시점의 테스트 대상 연결 상태만 보여 줍니다. 모든 웹사이트의 접속을 보장하지 않으며 DNS나 규칙이 올바른지도 단독으로 판별할 수 없습니다.

  1. 선택된 항목 확인

    Home에서 선택 표시의 위치와 서버 이름을 확인하세요. 구성에서 정책 그룹을 사용하는 경우 그룹 안에서 실제로 선택된 항목도 확인해야 합니다. Home의 기본 선택이 구성에 지정된 고정 정책보다 우선하는 것은 아닙니다.

  2. 연결 테스트 실행

    Home에서 Connectivity Test를 실행한 뒤 같은 주소를 열어 보세요. 테스트와 웹페이지가 각각 성공했는지 기록합니다. 지연 시간 숫자만으로 웹페이지에 접속할 수 있다고 판단하지 마세요.

  3. 연결 정보 확인

    해당 서버의 편집 화면을 열고 Type, 주소, 포트, 인증 정보를 원래 구성과 대조하세요. Trojan, VLESS 등의 유형은 TLS와 전송 매개변수도 원래 설정대로 확인해야 합니다. 서버 이름만 보고 유형을 판단할 수는 없습니다.

  4. 기존 구독 업데이트

    Home에서 해당 구독의 업데이트 기능을 사용하세요. 업데이트가 성공한 것을 확인한 뒤 항목을 선택해 테스트합니다. 업데이트에 실패하면 기존 구성을 보존하고 서비스 제공업체에 구독 유효 여부를 문의하세요. 항목을 반복해서 삭제하고 다시 추가하지 마세요.

포트에는 사용 중인 구성에 지정된 값을 입력해야 하며, 무조건 443으로 바꾸면 안 됩니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 인증 및 전송 항목이 서로 다릅니다. Type을 바꿔도 설정이 자동으로 변환되지는 않습니다. 서버가 UDP를 요구하는데 현재 네트워크에서 UDP를 제한한다면, 포트 하나를 바꾸는 것만으로 문제가 해결됐다고 판단할 수 없습니다.

로그 키워드: connection refused

원인 및 해결 방법: 대개 대상 또는 중간 장비가 연결을 명시적으로 거부했음을 뜻합니다. 포트에서 서비스가 대기 중이지 않거나 접근이 차단되었을 수 있습니다. 먼저 서버 주소와 포트를 확인한 뒤 서비스 제공업체에 해당 서비스의 상태를 문의하세요.

로그 키워드: i/o timeout

원인 및 해결 방법: I/O 작업이 제한 시간 안에 완료되지 않았다는 뜻이며, 이것만으로 계정이 비활성화됐다고 단정할 수는 없습니다. 로그에 표시된 대상 주소를 확인해 시간 초과가 서버에서 발생했는지 대상 웹사이트에서 발생했는지 살펴보고, 다른 네트워크에서도 다시 테스트하세요.

위 문구는 네트워크 로그에 나타날 수 있는 원문 키워드이며 모든 문제에서 표시되는 것은 아닙니다. 해당 기기에 실제로 기록된 내용을 기준으로 확인하고, 글의 예시를 근거로 진단 결과를 임의로 만들어 내지 마세요.

2단계: Global Routing으로 분할 라우팅 문제 확인

Home → Global Routing으로 이동해 현재 값을 먼저 확인한 다음 임시로 설정을 바꿔 비교해 보세요. Proxy, Direct, Config, Scene은 서버 이름이 아니라 트래픽의 경로를 결정하는 모드입니다. Direct 자체가 오류는 아닙니다. 직접 연결할 수 있는 대상은 정상적으로 열려야 합니다. 프록시가 필요한 대상이라면 Direct로 설정된 상태가 접속 목적에 맞지 않을 수 있습니다.

4가지 모드
Global Routing：Proxy / Direct / Config / Scene
2가지 항목
각 테스트에서 라우팅 모드와 실제 전송 경로 기록
1회
한 번에 변수 하나만 바꾸고 같은 요청을 다시 테스트

3단계: DNS 조회 실패와 연결 실패 구분

DNS는 도메인 이름을 연결 가능한 주소로 변환합니다. 연결 기록에 대상 주소가 나오기 전에 오류가 발생했다면 먼저 DNS 조회를 확인하세요. 주소를 가져온 뒤 연결 시간 초과가 발생했다면 대상의 연결 가능 여부, 서버의 외부 연결, 규칙을 이어서 점검해야 합니다. 브라우저에 표시된 ‘웹페이지를 열 수 없음’만으로는 두 경우를 구분할 수 없습니다.

로그 키워드: no such host

원인 및 해결 방법: 대개 도메인 조회에서 사용할 수 있는 결과를 얻지 못했거나 주소에 오타가 있는 경우입니다. 오류에 표시된 도메인이 서버, DNS 서비스, 대상 웹사이트 중 어느 것인지 먼저 확인한 뒤 해당 주소와 조회 경로를 점검하세요.

  1. 실패 직후 연결 기록이나 로그를 열어 같은 시간대에 같은 도메인으로 기록된 항목을 찾으세요. 다른 앱의 백그라운드 요청을 현재 테스트의 결과로 혼동하지 마세요.
  2. Settings에서 DNS 관련 설정을 확인하고, Config에서 현재 구성의 [General] 아래에 dns-server가 있는지 또는 [Host]에 정적 매핑이 있는지 살펴보세요. 구성에 지정된 값이 문제를 찾는 단서일 수 있습니다.
  3. 사용자 지정 DNS를 최근 추가했다면 먼저 기존 값을 기록한 다음, 수정 전 정상 작동이 확인된 설정으로 되돌리세요. DNS, 서버, 라우팅 모드를 한꺼번에 바꾸면 어느 설정이 영향을 주었는지 알 수 없습니다.
  4. 암호화 DNS를 사용한다면 DNS 서비스 자체의 도메인, 네트워크 경로, TLS 연결도 설정되는지 확인하세요. 암호화 DNS를 사용한다고 해서 해당 조회 서비스에 자동으로 연결되는 것은 아닙니다.

‘웹사이트 IP를 직접 입력해 열리면 DNS 문제’라고 일반화하지 마세요. HTTPS 인증서 검증과 SNI에는 도메인 이름이 필요하며, 많은 웹사이트가 공유 IP나 CDN을 사용합니다. IP로 접속되지 않는다고 해당 IP에 연결할 수 없다는 뜻은 아닙니다. 도메인을 우회해 결론을 내리기보다 로그에 기록된 조회 결과와 연결 단계를 함께 확인하세요.

4단계: 규칙 순서와 매칭 결과, 전송 경로 확인

서버와 DNS를 확인한 뒤 Config에서 현재 활성화된 파일의 [Rule]을 살펴보세요. 규칙은 일반적으로 위에서 아래 순서로 매칭되므로 앞의 포괄적인 규칙이 뒤의 구체적인 규칙보다 먼저 적용될 수 있습니다. 실패한 요청의 연결 기록에서 대상 도메인 또는 IP, 매칭된 규칙, 실제 적용된 정책을 확인하세요. 규칙 파일에 해당 도메인이 적혀 있는지만 확인해서는 부족합니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

이 코드는 문법을 설명하기 위한 예시이며 현재 파일을 그대로 대체할 수 있는 완전한 구성은 아닙니다. example.com은 예시 도메인입니다. 실제 프록시 경로는 현재 구성과 정책 선택에 따라 달라집니다. 수정하기 전에 원본 파일을 저장하고 사용하려는 정책 이름이 현재 구성에서 유효한지 확인하세요.

문제가 계속되나요? 증상별로 범위를 좁혀 보세요

네 단계를 확인한 뒤에도 연결되지 않는다면 ‘기본 네트워크 정상 여부, 현재 서버, Global Routing 값, 실패한 도메인, 로그 키워드’ 다섯 항목으로 결과를 정리하세요. 공유하기 전에 민감한 정보는 삭제합니다. 특정 네트워크에서만 실패하면 네트워크 조건을 먼저 비교하세요. 모든 네트워크에서 실패하고 구성 항목도 일치한다면 서비스 제공업체에 서비스 상태를 문의하세요.

지연 시간은 표시되는데 웹페이지가 열리지 않는 이유는 무엇인가요?

지연 시간 테스트와 웹 요청은 서로 다른 대상과 경로를 사용할 수 있습니다. 먼저 Connectivity Test를 실행한 뒤 같은 웹페이지를 Proxy와 Config에서 비교하세요. Config에서만 실패한다면 해당 웹 요청의 규칙과 실제 전송 경로를 확인합니다.

Wi-Fi에서는 안 되지만 모바일 데이터에서는 된다면 무엇부터 확인해야 하나요?

서버, 구성, 대상 주소는 그대로 두고 네트워크만 바꿔 다시 테스트하세요. 먼저 Wi-Fi에서 웹 로그인이 필요한지 확인한 다음 해당 네트워크가 필요한 전송 방식을 제한하는지 살펴보세요. DNS와 프로토콜을 동시에 바꾸면 비교할 수 없습니다.

직접 껐는데 다시 자동으로 연결되면 어떻게 하나요?

Settings → On Demand에서 기존 자동 연결 설정을 기록한 뒤, 점검 중에는 잠시 끄고 테스트하세요. On Demand는 자동 연결 조건을 제어할 뿐, 유효하지 않은 서버 인증이나 잘못된 규칙을 해결하지는 않습니다. 점검이 끝나면 원래 필요에 따라 설정을 복원하세요.

구독을 업데이트했는데도 연결되지 않으면 다시 설치해야 하나요?

먼저 구독 업데이트가 성공했는지, Home에서 업데이트된 항목을 선택했는지 확인하세요. 그런 다음 Config의 고정 서버나 정책 그룹이 이전 항목을 계속 가리키는지 살펴봅니다. 서버 구독 업데이트와 규칙 구성 업데이트는 별개입니다. 재설치를 첫 번째 해결 방법으로 삼지 마세요.

Shadowrocket 다운로드