Shadowrocket 인터넷 연결 안 됨: 서버 상태, Global Routing, DNS 및 규칙 점검

이 글의 핵심 내용

Shadowrocket의 연결 스위치를 켰다는 것은 연결 기능이 활성화되었다는 뜻일 뿐, 원격 서비스와 도메인 확인, 규칙에 따른 연결 경로가 모두 정상이라는 의미는 아닙니다. 서비스 제공업체의 설정을 이미 가져왔지만 기기 전체에서 인터넷이 끊기거나 일부 앱이 열리지 않는 경우에 참고하세요. 먼저 연결을 끈 상태의 네트워크를 확인한 뒤 서버, Global Routing(전체 라우팅), DNS, Config(구성 파일)를 차례로 점검하고, 한 번에 설정 하나씩만 변경하세요.

1. 먼저 인터넷이 끊기는 범위를 확인하고 되돌릴 수 있도록 기록하세요

먼저 앱을 삭제하거나 설정을 모두 지우지 마세요. 서버 매개변수와 현재 규칙, 문제 진단에 필요한 단서가 사라질 수 있습니다. Home(홈)에서 선택된 서버, Global Routing의 현재 값, Config에서 사용 중인 구성 파일을 기록해 두세요. 인증 정보가 포함된 스크린샷은 기기 외부로 공유하지 마세요.

앱 요청시스템 터널DNS 확인 및 라우팅외부 연결대상 응답

이 경로는 문제를 점검할 범위를 나타내며, 모든 연결이 내부적으로 정확히 같은 순서로 처리된다는 뜻은 아닙니다. 규칙에 따라 일치 여부를 확인하는 과정에서 DNS 조회가 발생할 수 있고, 서버 도메인도 먼저 확인해야 할 수 있습니다. 시스템에 VPN 표시가 나타나더라도 연결의 마지막 단계에서 응답을 받았다고 단정할 수는 없습니다.

Shadowrocket 연결을 끄세요. 평소 바로 열리는 웹사이트에 접속한 다음 라우터 관리 페이지 같은 로컬 주소에도 접속해 인터넷 장애와 로컬 네트워크 장애를 구분하세요.
연결을 끈 상태에서도 인터넷이 되지 않으면 Wi-Fi 로그인 인증, 모바일 데이터 권한, 라우터 또는 통신사 연결부터 확인하세요. 이 단계에서는 규칙을 바꿔도 기본 네트워크가 복구되지 않는 경우가 많습니다.
기본 네트워크가 정상이라면 연결을 켜고 같은 주소에 다시 접속하세요. 모든 웹사이트가 실패하는지, 특정 도메인이나 앱, 영상 통화만 실패하는지 기록하세요.
Wi-Fi와 모바일 데이터에서 각각 다시 테스트하세요. 한 네트워크에서만 실패한다면 해당 네트워크에서 서버 주소, 포트 또는 UDP에 연결할 수 있는지 먼저 확인하세요.

2. 서버 상태 확인: 지연 시간 결과만으로 웹사이트 이용 가능 여부를 판단할 수 없습니다

Home에서 테스트하려는 서버가 실제로 선택되어 있는지 확인한 다음 Connectivity Test(연결 테스트) 결과를 살펴보세요. 테스트에 응답이 왔다는 것은 해당 테스트 경로가 그 시점에 응답했다는 뜻일 뿐입니다. 모든 대상, DNS 요청, UDP 트래픽이 정상적으로 통과한다고 볼 수는 없습니다. 지연 시간 숫자 하나만 보고 서버 설정 확인을 건너뛰지 마세요.

주소와 포트: 서비스 제공업체가 안내한 정보와 비교해 서버 호스트 이름과 포트를 확인하세요. 포트에는 원격 서비스가 실제로 수신 대기하는 값을 입력해야 합니다. 로컬 프록시 수신 포트를 원격 포트로 착각하지 마세요.
프로토콜과 인증 정보: Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 각각 필요한 필드가 다릅니다. 기존 프로토콜을 유지하고 비밀번호, UUID, 키 등 인증 정보를 확인하세요. 연결을 시험한다는 이유로 프로토콜을 임의로 바꾸지 마세요.
TLS 설정: 기존 설정을 기준으로 서버 이름, 인증서, 기기의 날짜와 시간을 확인하세요. 서버 주소에 연결할 수 있어도 TLS 인증이 통과된다는 뜻은 아닙니다. 인증서 검증을 끄는 방식으로 오류를 감추지 마세요.
서비스 상태: 계정이 유효하고 사용량이 남아 있으며 원격 서비스가 정상인지 확인하세요. 기존 구독 설정을 업데이트했다면 업데이트가 완료됐는지 확인한 뒤 서버를 다시 선택하세요. 이전 항목을 계속 테스트하지 않도록 주의하세요.

오류: Connection refused

원인: 대상 또는 중간 장비에서 연결을 명시적으로 거부한 상태입니다. 포트에서 수신 대기 중인 서비스가 없거나 접근 정책에서 차단한 경우가 흔합니다.

해결 방법: 먼저 원격 포트와 서비스 상태를 확인한 다음, 서비스 제공업체에 수신 대기 및 방화벽 설정을 문의하세요. 이미 거부 응답을 받은 상황은 DNS를 반복해서 바꿔도 해결되지 않습니다.

오류: Connection timed out

원인: 제한 시간 안에 연결이 완료되지 않았습니다. 주소에 연결할 수 없거나 패킷 손실, 필터링, 원격 서버의 무응답 등이 원인일 수 있습니다.

해결 방법: 설정은 그대로 두고 네트워크를 바꿔 같은 서버를 다시 테스트하세요. 이미 보유한 다른 정상 설정과 비교해 네트워크 문제인지 서버 문제인지 범위를 좁히세요.

오류: certificate verify failed

원인: TLS 인증서 검증에 실패했습니다. 인증서 체인, 서버 이름 또는 기기 시간이 원인일 수 있습니다.

해결 방법: 시스템에서 날짜와 시간을 자동으로 설정하고 기존 TLS 매개변수를 확인하세요. 인증서 문제는 서버 관리자에게 수정을 요청하세요.

위 문구는 연결 도구나 하위 로그에 표시될 수 있는 영어 오류의 예입니다. 실제 대소문자나 접두어는 다를 수 있습니다. 문제를 문의할 때는 오류 원문을 그대로 보존하고, 브라우저·구독 업데이트·프록시 연결 중 어디에서 발생했는지 구분하세요. 세 경우의 요청 경로는 서로 다를 수 있습니다.

3. Global Routing 확인: 잠깐씩 설정을 바꿔 라우팅 문제를 구분하세요

Home에서 Global Routing을 열고 기존 선택 항목을 먼저 기록하세요. Proxy(프록시), Direct(직접 연결), Config(구성 파일), Scene(장면)은 서로 다른 라우팅 방식이지 네 가지 연결 프로토콜이 아닙니다. 서버 설정이 올바르더라도 라우팅 선택에 따라 요청이 적절하지 않은 경로로 전달될 수 있습니다.

라우팅 방식	점검할 동작	결과 확인 방법
Proxy	프록시를 통한 연결을 주 경로로 사용합니다.	같은 주소가 Proxy에서는 열리고 Config에서는 실패한다면 규칙과 정책 선택을 이어서 확인하세요.
Direct	선택한 프록시 서버를 출구로 사용하지 않고 직접 연결합니다.	대상에 프록시가 필요한 경우 이 방식에서 열리지 않는다고 해서 서버 장애로 단정할 수는 없습니다.
Config	현재 구성 파일의 규칙에 따라 연결 경로를 결정합니다.	대상에 적용된 규칙이 DIRECT인지, 프록시 정책인지, 거부 동작인지 확인하세요.
Scene	설정된 장면 조건에 따라 라우팅 동작을 결정합니다.	현재 네트워크에서 어떤 장면이 적용되는지 확인하세요. Scene이 선택되어 있다는 사실만으로 최종 연결 경로를 판단할 수는 없습니다.

서버와 테스트 주소를 그대로 유지한 채 잠시 Proxy로 전환하고 요청을 다시 보내세요.
그런 다음 Config로 돌아가 같은 대상에 다시 접속하세요. 필요하면 테스트 앱을 완전히 종료한 후 다시 열어 이전 연결이 재사용되지 않도록 하세요.
Config에서만 실패한다면 현재 구성의 규칙 순서와 정책을 확인하세요. 두 방식 모두 실패하면 서버와 DNS를 계속 점검하고, 곧바로 규칙 오류라고 단정하지 마세요.

Proxy에서 연결된다는 결과는 원인을 좁히는 단서이지, 계속 사용해야 할 해결책은 아닙니다. 테스트가 끝나면 기존 라우팅 방식을 복원하세요. 로컬 네트워크 기기에 접속해야 한다면 로컬 주소의 실제 연결 경로도 확인하세요.

4. DNS 점검: 도메인 확인 실패와 연결 실패를 구분하세요

DNS(도메인 이름 시스템)는 도메인 이름을 IP 주소로 변환합니다. 도메인 확인에 실패하면 브라우저에서 웹사이트가 열리지 않을 수 있지만, 원인이 원격 프록시에 있다고 단정할 수는 없습니다. 먼저 Settings → DNS를 확인한 다음 Config에서 활성 구성의 DNS 항목을 점검해 실제 적용되는 설정과 덮어쓰기 관계를 확인하세요. 사용하지 않는 구성 파일만 수정하지 않도록 주의하세요.

일반 DNS에서 흔히 사용하는 포트이며 UDP와 TCP를 모두 사용할 수 있습니다

443

HTTPS에서 흔히 사용하는 포트이며 DNS over HTTPS도 보통 이 포트를 사용합니다

4가지

Global Routing：Proxy / Direct / Config / Scene

이 포트는 프로토콜에서 흔히 사용하는 값일 뿐, 서버 포트를 해당 숫자로 바꾸라는 뜻은 아닙니다. 암호화 DNS를 사용하려면 현재 네트워크 경로에서 상위 DNS 서비스에 연결할 수 있어야 합니다. 서버 도메인을 먼저 확인해야 프록시를 연결할 수 있는데 DNS 서비스가 아직 연결되지 않은 프록시에 의존한다면 시작 단계에서 의존성 문제가 생길 수 있습니다.

먼저 기존 값을 저장하세요: 여러 차례 설정을 바꾼 뒤에도 복원할 수 있도록 DNS 상위 서버 주소, 이름 확인 관련 옵션, 활성 구성을 기록하세요.
그다음 한 번에 하나씩 비교하세요: 이전에 작동했던 DNS 설정으로 잠시 되돌리거나 현재 네트워크에서 실제로 연결할 수 있는 DNS 서비스를 사용하세요. DNS 서비스와 규칙, 서버를 한꺼번에 바꾸지 마세요.
앱 캐시와 구분하세요: 설정을 바꾼 뒤 다시 연결하고 테스트 앱도 종료했다가 다시 여세요. 브라우저의 보안 DNS, 시스템 암호화 DNS 프로파일, 앱 캐시가 결과에 영향을 줄 수 있습니다.
IPv6를 확인하세요: 도메인에서 IPv6 주소를 받았지만 현재 연결 경로에서 IPv6를 사용할 수 없다면 DNS 결과와 라우팅이 일치하는지 확인하세요. 듀얼 스택 환경의 모든 문제를 서버 오프라인으로 단정하지 마세요.

5. 규칙 순서 확인: 일치한 규칙과 최종 연결 경로를 점검하세요

Global Routing이 Config일 때만 현재 구성 파일의 규칙이 이번 점검의 핵심입니다. 먼저 Config에서 활성 파일을 확인한 다음, 연결에 실패한 대상의 요청 기록을 살펴 도메인, 대상 주소, 일치 규칙, 실제 출구 정책을 기록하세요. 기록에 도메인이 없다면 공유 IP 하나만으로 웹사이트를 판단하지 마세요.

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

위 내용은 규칙 적용 순서를 보여주는 예시일 뿐, 그대로 가져와 사용할 수 있는 완성된 설정이 아닙니다. example.com은 예시 도메인입니다. PROXY는 실제로 사용 가능한 정책 이름이나 내장 정책에 해당해야 합니다. 192.168.0.0/16은 사설 주소 범위 하나만 포함하며 모든 로컬 네트워크를 포괄하지 않습니다.

DOMAIN-SUFFIX는 지정한 도메인과 하위 도메인에 일치합니다. 먼저 적용될 수 있는 광범위한 규칙보다 구체적인 규칙을 앞에 두세요.
IP-CIDR은 대상 IP 주소 범위를 기준으로 일치 여부를 확인합니다. 예시의 no-resolve는 이 IP 규칙을 위해 도메인 확인을 별도로 실행하지 않는다는 뜻이지, DNS를 전역적으로 끈다는 뜻은 아닙니다.
GEOIP는 IP 지리 정보 데이터를 기준으로 일치 여부를 확인합니다. 도메인 콘텐츠를 분류하는 기능이 아니며, 특정 웹사이트의 모든 연결이 같은 경로를 사용한다고 보장하지 않습니다.
FINAL은 앞선 규칙에 모두 일치하지 않았을 때 적용되는 최종 경로이므로 맨 아래에 두세요. 앞의 광범위한 규칙이 이미 일치했다면 FINAL을 바꿔도 해당 요청에는 영향이 없습니다.

홈페이지는 열리지만 로그인, 이미지 또는 동영상이 실패한다면 각 요청을 따로 확인하세요. 한 페이지에서 여러 도메인에 요청을 보낼 수 있으므로 기본 도메인 규칙이 올바르더라도 다른 리소스에 같은 정책이 적용된다고 볼 수 없습니다. 근거가 확인된 대상만 수정하고 정책 그룹에서 현재 선택한 항목이 유효한지 확인하세요. 먼저 모든 규칙을 같은 출구로 바꾸지는 마세요.

6. 자주 발생하는 증상에 따라 범위를 좁혀 보세요

스위치와 VPN 표시가 켜졌는데 왜 인터넷이 전혀 안 되나요?

먼저 연결을 끄고 기본 네트워크가 정상인지 확인한 다음 Home에서 선택된 서버를 확인하세요. 같은 주소에서 Proxy와 Config를 비교해 보세요. 둘 다 실패한다면 시스템의 VPN 표시만 보지 말고 서비스 상태, 인증 정보, DNS를 먼저 확인하세요.

웹페이지는 열리는데 음성 통화나 게임은 연결되지 않나요?

실패한 앱이 UDP에 의존하는지, 현재 프로토콜 설정과 서버, 사용 중인 네트워크에서 해당 트래픽을 허용하는지 확인하세요. TCP 웹페이지가 정상이라고 UDP도 작동하는 것은 아닙니다. 서버는 그대로 둔 채 Wi-Fi와 모바일 데이터를 바꿔 비교하고 해당 요청 기록도 확인하세요.

구독 업데이트가 성공했는데 연결 시간이 초과되는 이유는 무엇인가요?

구독 업데이트 성공은 구성 주소에 접속해 내용을 가져왔다는 뜻일 뿐, 구성에 포함된 모든 서버가 작동한다는 의미는 아닙니다. Home으로 돌아가 선택된 항목을 다시 확인하고 서비스 제공업체가 안내한 상태와 비교하세요. 구독 주소를 개별 서버의 주소 입력란에 넣지 마세요.

화면을 잠그거나 Wi-Fi를 바꾼 뒤 다시 연결되지 않나요?

문제가 발생한 시점과 네트워크 전환을 기록하고 Settings → On Demand의 조건과 Global Routing에서 Scene을 사용하는지 확인하세요. 네트워크를 잠시 고정하고 라우팅 방식을 명확히 설정해 테스트한 뒤 자동 연결 조건을 하나씩 복원하세요.

앱 하나에서만 문제가 생기는데 Shadowrocket을 다시 설치해야 하나요?

먼저 브라우저와 해당 앱에서 같은 서비스에 접속한 결과를 비교하고 앱의 네트워크 권한, 별도 DNS 설정, 요청 기록을 확인하세요. 다른 앱이 정상이라면 해당 앱의 연결 경로를 먼저 살펴보세요. 앱을 다시 설치하면 문제의 단서가 사라질 수 있으므로 원인 확인을 대신할 수는 없습니다.

7. 설정을 복원하고 재현 가능한 문제 보고를 준비하세요

원인을 찾았다면 문제와 관련 없는 시험 설정부터 되돌리세요. 필요한 On Demand 조건과 라우팅 방식을 복원하고, 효과가 확인된 수정만 남기세요. 다시 연결한 뒤 평소 사용하는 네트워크에서 웹페이지와 로그인을 테스트하고 UDP가 필요한 앱도 확인해 다른 연결에 문제가 생기지 않았는지 살펴보세요.

시스템 플랫폼, 네트워크 유형, 문제가 발생한 시간, 네트워크 전환 여부를 기록하세요. 버전 정보는 기억에 의존하지 말고 앱 화면에서 확인해 적으세요.
예를 들어 “연결을 끄면 접속 가능, 연결을 켜면 Config에서 실패, 같은 서버의 Proxy에서는 접속 가능”처럼 재현 순서를 적으세요. 각 단계에서 연결을 새로 설정했는지도 함께 알려주세요.
필요한 영어 오류 문구, 일치한 규칙, 출구 정책을 첨부하세요. 보내기 전에 구독 token, 비밀번호, UUID, 개인 키, 개인 네트워크 정보를 가리세요.
서버를 사용할 수 없거나 계정 상태에 문제가 있다면 서비스 제공업체에 문의하세요. 설정을 이해하는 데 도움이 필요하면 이 사이트의 사용 설명서와 자주 묻는 질문을 확인하세요.

이 글은 사용자가 이미 자신의 서비스 제공업체와 구독을 보유한 경우를 전제로 합니다. 이 사이트는 클라이언트 설정과 문제 해결만 안내합니다. 앱 구매와 회선 서비스는 별개이며, 앱 일회성 구매가 회선 요금제를 포함하지는 않습니다.

Shadowrocket 다운로드 및 설정 방법

iPhone/iPad 버전은 App Store에서 받을 수 있으며, $2.99 일회성 결제입니다. 시스템 요구 사항은 App Store 페이지를 기준으로 확인하세요. Mac(Apple 실리콘/Intel), Windows, Android, Linux 버전은 무료입니다. 다운로드 페이지에서 플랫폼을 선택한 뒤 안내에 따라 보유한 서비스 설정을 가져오세요.

다운로드 페이지 사용법 보기