Shadowrocket 연결됨에도 인터넷이 안 될 때: 서버, Global Routing, DNS 및 규칙 문제 해결

이 글 한눈에 보기

이 글은 Shadowrocket이 연결됨으로 표시되고 상태 막대의 연결 표시도 정상인데, 웹페이지나 앱에서 네트워크에 접속할 수 없는 경우를 다룹니다. 먼저 로컬 네트워크 기준을 확인한 뒤 서버, Global Routing, DNS, Config 규칙을 차례로 검증하세요. 여러 설정을 동시에 바꾸지 않고 결과를 비교하면 문제가 어느 계층에 있는지 확인할 수 있습니다.

재현 가능한 네트워크 기준 만들기

연결됨은 Shadowrocket이 시스템에 네트워크 채널을 만들었다는 뜻일 뿐, 채널의 모든 구간이 정상적으로 전송된다는 의미는 아닙니다. 서버에 연결할 수 없거나 인증 정보가 만료되었거나 DNS 조회가 실패했거나 Config 규칙이 잘못된 정책을 선택하면 연결을 켜도 요청에 응답이 오지 않을 수 있습니다.

점검을 시작하기 전에 현재 서버 이름, Global Routing 상태, 사용 중인 Config를 기록하세요. 한 번에 한 항목만 변경하고, 변경할 때마다 같은 테스트 페이지를 다시 열어 보세요. 서버, DNS, 규칙을 동시에 바꾸면 네트워크가 복구되어도 어떤 변경이 원인이었는지 알 수 없습니다.

기본 네트워크 확인
먼저 Shadowrocket 연결 스위치를 끄고 현재 Wi-Fi 또는 셀룰러 네트워크에서 이전에 열어 보지 않은 웹페이지 두 개를 열어 보세요. 이때도 접속할 수 없다면 로컬 네트워크, 라우터 로그인 페이지 또는 셀룰러 데이터 권한부터 확인해야 합니다.
현재 설정 기록
Home에서 선택한 서버와 Global Routing을 기록하고, Config에서 활성화된 구성 이름을 기록하세요. Settings → DNS에서는 현재 DNS 항목을 기록해 점검 후 원래 상태로 되돌릴 수 있게 하세요.
연결 다시 설정
Home으로 돌아가 연결 스위치를 끄고 몇 초 기다린 뒤 다시 켜세요. 시스템에서 네트워크 구성 확인을 요청하면 안내에 따라 권한을 완료한 다음 연결 상태가 안정적으로 유지되는지 확인하세요.
비교 테스트 실행
Direct, Proxy, Config를 차례로 사용해 테스트하되 매번 Global Routing만 전환하고 서버는 바꾸지 마세요. 세 결과의 차이를 비교하면 로컬 네트워크, 서버 경로, 규칙 문제를 빠르게 구분할 수 있습니다.

4개 계층

서버, 라우팅 상태, DNS, Config 규칙

4가지 상태

Global Routing：Proxy / Direct / Config / Scene

일반 DNS에서 주로 사용하는 UDP 또는 TCP 포트

443

DNS over HTTPS에서 일반적으로 사용하는 HTTPS 포트

첫 번째 계층: 서버 상태와 매개변수 확인

Shadowrocket을 끈 뒤 로컬 네트워크는 정상인데 Global Routing을 Proxy로 설정하면 모든 요청이 실패한다면, 먼저 현재 서버를 확인하세요. Home의 지연 시간 결과는 제한 시간 안에 테스트 요청이 반환되었는지만 보여 주며 실제 서비스 트래픽이 반드시 정상이라는 뜻은 아닙니다. 그래도 계속된 시간 초과, 빈 지연 시간 또는 테스트 결과의 급격한 상승은 서버 경로 이상을 나타내는 중요한 신호입니다.

Home의 서버 목록을 열고 현재 서버에서 연결 가능 여부 또는 지연 시간 테스트를 실행한 다음, 사용자가 이미 보유한 서비스 구성의 다른 서버와 비교하세요. 같은 네트워크에서 한 서버만 실패하면 해당 서버, 포트 또는 인증 정보에 문제가 있을 가능성이 큽니다. 모두 실패한다면 구독 업데이트 성공 여부, 로컬 네트워크의 대상 포트 제한, 서버 도메인에 대한 DNS 확인 결과를 점검하세요.

오류:Request timed out

원인 및 해결:대기 시간 안에 응답을 받지 못한 상태로, 서버 오프라인, 회선 패킷 손실 또는 대상 포트에 접근할 수 없는 경우에 흔히 발생합니다. 사용자가 이미 보유한 구성의 다른 서버로 전환하세요. 원래 서버만 실패한다면 서비스 제공업체에 서버 상태와 포트를 확인하세요.

오류:Failed to resolve hostname

원인 및 해결:서버 주소가 도메인으로 되어 있지만 현재 DNS가 사용할 수 있는 주소를 반환하지 못한 상태입니다. Settings → DNS에서 DNS 설정을 확인하고 서버 도메인에 불필요한 공백이나 철자 오류가 없는지 확인하세요.

오류:Network is unreachable

원인 및 해결:기기에 사용할 수 있는 네트워크 출구가 없거나 Wi-Fi 포털 인증이 완료되지 않은 상태입니다. 연결을 끈 뒤 일반 웹페이지에 접속해 기본 네트워크를 확인하고, 필요하면 Wi-Fi 로그인부터 완료한 다음 Shadowrocket을 다시 켜세요.

오류:Failed to load subscription

원인 및 해결:구독 주소가 만료되었거나 접속 시간이 초과되었거나 서버가 유효한 내용을 반환하지 않은 상태입니다. 예를 들어 https://example.com/sub?token=xxxx와 같은 형식의 본인 링크를 확인하고, 서비스 제공업체에 링크 상태를 문의한 뒤 Home으로 돌아가 아래로 당겨 업데이트하세요.

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 매개변수 구조가 서로 다릅니다. 점검할 때 한 프로토콜의 포트, 인증 필드 또는 전송 설정을 다른 프로토콜에 적용하지 마세요. 구독 업데이트가 성공했다는 것은 Shadowrocket이 구성 내용을 가져와 해석했다는 뜻일 뿐, 모든 서버가 온라인이라는 의미는 아닙니다.

서버 주소가 도메인이라면 먼저 DNS가 해당 도메인을 해석할 수 있는지 확인하세요.
서버 주소가 IP라면 서버 연결 자체에서 DNS의 영향은 비교적 작으므로 포트와 인증 정보를 먼저 확인하세요.
같은 서버가 Wi-Fi에서는 실패하고 셀룰러 네트워크에서는 성공한다면 현재 Wi-Fi 출구와 라우터 정책을 확인하세요.
두 네트워크에서 모든 서버가 실패한다면 구독 업데이트 시간, 계정 상태, 서비스 서버 상태를 확인하세요.

두 번째 계층: Global Routing으로 트래픽 경로 확인

Global Routing은 요청에 통합 정책을 적용할지 Config에 따라 매칭할지를 결정합니다. Proxy는 모든 요청에 프록시 정책을 적용하고, Direct는 직접 연결하며, Config는 규칙을 순서대로 판단합니다. Scene은 미리 설정된 시나리오에 따라 동작을 선택합니다. 문제 해결에서는 Proxy, Direct, Config 세 결과를 비교하는 것이 가장 유용합니다.

테스트 결과	우선 판단	다음 단계
Direct 성공, Proxy 실패	로컬 네트워크는 정상이며 서버 경로 또는 서버 매개변수에 문제가 있을 가능성	사용 중인 다른 서버를 테스트하고 서버 도메인, 포트, 인증 필드를 확인하세요
Proxy 성공, Config 실패	서버는 정상이며 Config 규칙 또는 정책 이름에 문제가 있을 가능성	규칙 순서, 정책 그룹 이름, FINAL을 확인하세요
Proxy와 Config 성공, Direct 실패	현재 직접 연결 네트워크에서 대상에 접근할 수 없거나 직접 연결 DNS 결과에 문제가 있을 가능성	DNS 반환 결과와 Config에서 해당 대상에 적용되는 정책을 확인하세요
세 가지 상태 모두 실패	로컬 네트워크, 시스템 네트워크 권한 또는 DNS 기본 설정을 우선 의심해야 함	연결을 끄고 기본 네트워크를 확인한 뒤 Settings → DNS를 점검하세요
Scene에서는 실패하고 수동 Config에서는 성공	Scene의 트리거 조건 또는 선택한 구성이 현재 네트워크와 맞지 않음	Wi-Fi, 네트워크 상태, 구성에 대한 Scene의 판단 조건을 확인하세요

결론: 서버를 고정한 뒤 상태를 비교하세요

같은 서버에서 Proxy는 접속되고 Config는 접속되지 않는다면 서버 문제의 우선순위를 낮춰도 됩니다. 이때 서버를 계속 바꾸면 변수가 늘어나므로 규칙 매칭과 정책 그룹 이름을 바로 확인하세요.

현재 Scene을 사용 중이라면 문제 해결 단계에서는 수동 Direct, Proxy 또는 Config로 잠시 전환하세요. 기본 경로가 복구된 뒤 Scene으로 돌아가 트리거 조건을 확인하면 시나리오 전환과 규칙 매칭이 동시에 판단에 개입하는 것을 막을 수 있습니다.

세 번째 계층: DNS 조회 중단 여부 확인

DNS의 역할은 도메인을 주소로 변환하는 것입니다. DNS가 실패하면 서버 지연 시간 테스트에는 결과가 나오지만 도메인을 입력한 뒤 웹페이지가 오래 멈춰 있는 현상이 나타날 수 있습니다. 이미 연결되었거나 캐시에 저장된 일부 앱은 잠시 정상일 수 있으므로 ‘일부만 작동함’은 DNS 문제를 배제하지 못합니다.

Settings → DNS로 들어가 현재 항목을 먼저 기록한 뒤 접속할 수 없는 DNS 주소, 잘못된 암호화 DNS URL, 중복 설정이 있는지 확인하세요. 일반 DNS는 보통 UDP 또는 TCP 53 포트를 사용하고 DNS over HTTPS는 보통 HTTPS 443 포트를 사용합니다. 두 방식의 네트워크 경로가 다르므로 문제가 발생하면 따로 검증해야 합니다.

DNS 기록
Settings → DNS를 열고 현재 주소, 프로토콜 방식, 관련 스위치 상태를 저장하세요. 되돌려야 할 경우 점검 전 설정을 복원할 수 있어야 합니다.
형식 확인
일반 DNS에는 유효한 주소를 입력해야 하며 DNS over HTTPS에는 완전한 HTTPS URL을 사용해야 합니다. 줄 앞뒤 공백을 삭제하고 경로가 잘리지 않았는지 확인하세요.
변수 줄이기
임시로 접속 가능한 DNS 항목 하나만 남겨 테스트하고, 결과를 모르는 항목을 여러 개 동시에 추가하지 마세요. 변경 후 다시 연결해 새 설정이 현재 네트워크 세션에 적용되도록 하세요.
조회 결과 비교
이전에 접속한 적 없는 도메인과 이미 접속한 도메인을 각각 테스트하세요. 새 도메인은 실패하지만 캐시된 페이지가 열리면 DNS 조회 경로를 우선 점검할 필요가 있습니다.
요청 결과 확인
Shadowrocket에서 확인할 수 있는 요청 또는 로그 정보에서 resolve, DNS, timeout 등의 메시지를 찾고 실패한 도메인을 기록하세요. 브라우저의 일반 오류 페이지만으로 판단하지 마세요.

일반 DNS:
서버 주소 → UDP/TCP 53 → A 또는 AAAA 레코드 반환

DNS over HTTPS:
HTTPS URL → TCP 443 → 암호화된 조회 → 해석 레코드 반환

서버 자체가 도메인을 사용한다면 DNS 문제는 서버 연결을 설정하기 전에 발생합니다. 서버가 IP를 사용하지만 대상 웹사이트가 도메인을 사용한다면 서버 연결은 성공해도 대상 도메인을 해석하지 못해 웹 요청이 실패할 수 있습니다. 두 경우 모두 연결 스위치는 켜진 것으로 표시될 수 있지만 문제 위치는 서로 다릅니다.

결론: 서버 도메인과 대상 도메인을 구분하세요

로그에 서버 호스트 이름 해석 실패가 먼저 나타난다면 연결 설정 전 DNS를 처리해야 합니다. 서버가 이미 연결되었고 대상 도메인에 접속할 때만 실패한다면 터널 내부의 대상 조회 경로와 Config의 DNS 요청 처리 방식을 확인하세요.

네 번째 계층: Config 규칙 순서와 FINAL 확인

Proxy로는 접속되지만 Config에서는 접속되지 않는다면 규칙을 중점적으로 확인하세요. Shadowrocket의 Config는 일반적으로 순서대로 매칭하며 먼저 일치한 규칙이 정책을 결정합니다. FINAL은 앞선 규칙에 매칭되지 않은 요청을 처리하므로 보통 규칙의 마지막에 위치합니다.

다음 조각은 지정된 도메인 접미사에 PROXY를 적용하고, 로컬 네트워크 주소와 GEOIP 조건에 맞는 주소에는 DIRECT를 적용하며, 나머지 요청은 FINAL을 통해 PROXY로 전달합니다. PROXY는 현재 Config에 실제로 존재하는 정책 또는 정책 그룹 이름이어야 합니다. 구성에서 다른 이름을 사용한다면 규칙과 정책 이름을 완전히 일치시켜야 합니다.

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

DOMAIN-SUFFIX: 도메인 접미사로 매칭하며 기본 도메인과 하위 도메인을 함께 적용할 수 있습니다.
DOMAIN-KEYWORD: 도메인에 지정한 키워드가 포함될 때 매칭하며, 일반적으로 접미사 규칙보다 범위가 넓습니다.
IP-CIDR: 주소 대역으로 매칭합니다. no-resolve를 추가하면 매칭을 위해 별도의 도메인 조회를 실행하지 않습니다.
GEOIP: 대상 IP의 지리 데이터베이스 결과로 매칭하므로 일반적으로 먼저 대상 IP를 확인해야 합니다.
FINAL: 앞선 규칙에 매칭되지 않은 나머지 요청을 처리합니다. 누락되었거나 정책이 잘못되면 미매칭 트래픽이 예상과 다르게 처리될 수 있습니다.

규칙에서 가장 흔한 문제는 문법 수가 부족한 것이 아니라 순서가 충돌하는 것입니다. 예를 들어 범위가 넓은 DOMAIN-KEYWORD가 정확한 DOMAIN-SUFFIX보다 앞에 있으면 요청을 먼저 가로챌 수 있습니다. 적용 범위가 큰 IP-CIDR이 대상 규칙보다 앞에 있어도 뒤의 규칙이 매칭되지 않을 수 있습니다.

Config에서 현재 선택한 항목이 실제로 편집 중인 구성인지 확인하세요. 수정 후 저장하고 다시 연결한 다음 Config 상태로 테스트하세요. Shadowrocket의 요청 상세 정보에 대상이 DIRECT로 매칭되었지만 PROXY로 보내야 한다면 규칙 순서 또는 내용을 조정하세요. 정책 이름이 존재하지 않는다고 표시되면 규칙 참조를 수정해야 합니다.

현상:Proxy는 작동하지만 Config에서는 접속할 수 없음

원인 및 해결:통합 프록시를 통해 서버 경로가 확인되었으므로 Config에 잘못된 DIRECT, REJECT 또는 정책 참조가 있을 수 있습니다. 대상 요청의 매칭 결과를 확인하고 첫 번째 관련 규칙부터 순서를 점검하세요.

현상:일부 도메인만 열리지 않음

원인 및 해결:실패한 도메인이 범위가 지나치게 넓은 DOMAIN-KEYWORD에 매칭되었거나 예상한 DOMAIN-SUFFIX에 포함되지 않았을 수 있습니다. 전체 호스트 이름을 기록하고 정확한 규칙을 추가한 뒤 넓은 규칙보다 앞에 배치해 테스트하세요.

현상:구성을 수정해도 결과가 바뀌지 않음

원인 및 해결:활성화되지 않은 Config를 편집했거나 현재 Global Routing이 여전히 Proxy, Direct, Scene에 머물러 있을 수 있습니다. Home으로 돌아가 Config 상태와 선택된 구성을 확인한 뒤 다시 연결하세요.

다섯 번째 계층: On Demand, 구독, 로컬 네트워크 간섭 배제

Settings → On Demand는 네트워크 조건에 따라 연결을 실행할 수 있습니다. 수동으로 끈 직후 다시 연결되거나 Wi-Fi를 전환한 뒤 상태가 예상과 다르다면 On Demand를 잠시 끄고 기준 테스트를 진행하세요. 수동 연결이 정상임을 확인한 뒤 트리거 조건을 하나씩 복원하세요.

구독 업데이트도 별도의 단계입니다. 클라이언트가 열리는 것과 구독 주소가 현재 유효한 것은 별개이며, 구독 업데이트가 성공해도 그 안의 모든 서버가 작동한다는 뜻은 아닙니다. 구독 유효성, 계정 상태, 서버 유지보수 여부는 사용자가 보유한 서비스 제공업체 정보를 기준으로 확인하세요.

연결 스위치가 계속 자동으로 다시 켜지나요?

Settings → On Demand로 들어가 요구 시 연결을 잠시 끈 다음 Home으로 돌아가 수동으로 연결을 끊으세요. 자동 연결이 멈추면 트리거가 On Demand에서 발생한 것입니다. 이후 Wi-Fi, 네트워크 상태 등의 조건을 확인하고 하나씩 복원하며 테스트하세요.

Wi-Fi에서는 실패하지만 셀룰러 네트워크에서는 정상인가요?

먼저 Shadowrocket을 끄고 해당 Wi-Fi에서 일반 페이지에 접속해 포털 로그인이 필요한지 확인하세요. 기본 네트워크가 정상화된 뒤 같은 서버와 같은 Global Routing 상태를 고정해 테스트하면 현재 Wi-Fi가 대상 경로를 제한하는지 판단할 수 있습니다.

구독 업데이트는 성공했는데 왜 여전히 연결되지 않나요?

업데이트 성공은 구성 내용을 가져와 해석했다는 뜻일 뿐입니다. Home으로 돌아가 특정 서버를 테스트하고 Proxy 상태에서 실제 요청을 확인하세요. 여러 서버의 결과가 다르면 각각 기록하고 구독 업데이트 상태를 서버 온라인 상태와 동일하게 보지 마세요.

Direct는 작동하지만 Config와 Proxy는 모두 작동하지 않나요?

로컬 네트워크의 기본 연결은 정상일 가능성이 큽니다. 먼저 서버 하나를 고정하고 Proxy로 서버 경로를 확인하세요. Proxy도 실패한다면 서버 상태, 도메인, 포트, 인증 정보를 점검하고 Config 규칙은 당분간 수정하지 마세요.

앱 하나만 네트워크에 연결되지 않으면 어떻게 하나요?

먼저 Shadowrocket을 끈 상태에서 해당 앱이 네트워크에 연결되는지 확인한 다음 요청 도메인과 규칙 매칭 결과를 확인하세요. 같은 상태에서 다른 앱은 정상이라면 대상 도메인, IP-CIDR, REJECT 규칙, 해당 앱의 네트워크 권한을 중점적으로 점검하세요.

시스템 시간이 정확한지도 확인할 수 있습니다. 일부 프로토콜은 TLS 또는 시간 관련 검증을 사용하므로 기기 시간의 오차가 크면 핸드셰이크가 실패할 수 있습니다. 시스템의 날짜 및 시간 자동 설정을 사용한 뒤 연결을 다시 설정하세요. Wi-Fi와 셀룰러 네트워크를 전환한 뒤에도 라우팅과 DNS 세션을 새로 만들 수 있도록 연결을 끊었다가 다시 연결하는 것이 좋습니다.

결과를 바탕으로 점검을 마무리하고 설정 복원

위 테스트를 마친 뒤 결과를 ‘네트워크 조건 + 서버 + Global Routing + DNS + Config’ 조합으로 기록하세요. 예: ‘같은 Wi-Fi에서 Direct는 성공했지만 고정한 서버가 Proxy에서 시간 초과되었고, 이미 보유한 다른 서버로 바꾸자 복구됨.’ 이런 기록은 문제를 막연히 인터넷 불가로 설명하지 않고 서버 경로 문제로 명확히 좁혀 줍니다.

서비스 제공업체에 문의해야 한다면 발생 시간, 네트워크 유형, 서버 이름, 프로토콜 유형, 포트, 오류 원문, 비교 결과를 제공하면 됩니다. 구독 링크의 token, 비밀번호, Private Key 등의 인증 정보는 스크린샷이나 공개 기록에 포함하지 마세요.

기본 네트워크 실패: 먼저 Wi-Fi, 셀룰러 네트워크 또는 포털 인증을 처리하세요.
Direct 성공, Proxy 실패: 서버 상태, 포트, 인증 정보, 서버 도메인 해석을 확인하세요.
Proxy 성공, Config 실패: 규칙 순서, 정책 이름, FINAL, 현재 활성화된 Config를 확인하세요.
도메인은 실패하지만 기존 연결은 작동함: Settings → DNS와 해석 오류를 확인하세요.
수동 설정은 정상이고 자동 시나리오는 실패함: Settings → On Demand와 Scene 조건을 확인하세요.
복구 후에는 임시 상태, DNS, 테스트 규칙을 확인된 구성으로 되돌리세요.

Shadowrocket은 App Store를 통해서만 제공되며 제품 페이지의 개발자명은 Shadow Launch Technology Limited, 앱 ID는 932747118로 표시되어야 합니다. iPhone과 iPad가 주요 사용 기기이며 호환 범위와 시스템 요구 사항은 App Store 페이지 표기를 기준으로 확인하세요. 다시 설치하기 전 구성 백업과 구매 복원 방법을 먼저 확인해 재설치를 첫 번째 문제 해결 단계로 삼지 않도록 하세요.