Shadowrocket 연결됨에도 인터넷이 안 될 때: 서버·라우팅 모드·DNS·규칙 점검

이 글의 핵심

Shadowrocket의 연결 스위치를 켜면 기기의 로컬 VPN 연결은 설정되지만, 선택한 서버와 DNS가 정상인지 또는 대상 웹사이트에 접속할 수 있는지까지 확인되는 것은 아닙니다. 이미 이용 중인 서비스와 구독이 있고 연결은 되지만 웹 탐색이 원활하지 않은 경우, 네 가지 단계별로 상태를 비교해 보세요. 한 번에 한 항목만 변경하고 같은 주소로 새 요청을 보내 결과를 확인합니다.

시작하기 전에: ‘연결됨’과 ‘접속 가능’을 따로 확인하기

시스템의 VPN 상태는 기기의 해당 트래픽이 로컬 터널로 전달되고 있음을 나타냅니다. 원격 서버가 연결을 받아들이는지, 도메인이 올바르게 해석되는지, 요청에 어떤 정책이 적용되는지는 별도로 확인해야 합니다. 스위치를 반복해서 켜고 끄더라도 잘못 입력한 서버 포트나 규칙이 수정되지는 않습니다.

먼저 현재 Config를 복사해 저장하고, Home에서 선택한 서버와 Global Routing의 현재 값, 문제가 발생한 네트워크가 Wi-Fi인지 셀룰러인지 기록합니다. 점검할 때는 평소 사용하는, 정상 접속이 확인된 HTTPS 웹사이트 하나를 고정해 비교하세요. 단계마다 다른 대상을 사용하면 결과를 비교하기 어렵습니다.

4단계

서버 → 모드 → DNS → 규칙

한 번에 1개

매번 변수 하나만 변경한 뒤 새 요청 보내기

443

HTTPS에서 흔히 쓰는 포트일 뿐, 서버의 실제 포트라는 뜻은 아님

일반 DNS에서 흔히 쓰는 포트일 뿐, 모든 DNS 전송 방식에 해당하는 것은 아님

Shadowrocket 연결을 잠시 끄고 현재 네트워크에서 원래 직접 접속할 수 있었던 웹사이트가 열리는지 확인합니다. 공용 Wi-Fi에 인증 페이지가 표시되면 먼저 네트워크 인증을 완료하세요.
스위치가 저절로 다시 켜진다면 Settings → On Demand에서 현재 설정을 기록한 뒤 On Demand를 잠시 끄세요. 수동으로 비교하는 동안 설정이 개입하지 않도록 할 수 있습니다.
연결을 다시 켜고 같은 대상에 새 요청을 보냅니다. 기존 연결을 재사용해 잘못 판단하지 않도록 테스트할 앱을 종료한 뒤 다시 여세요.

1단계: 선택한 서버가 실제로 작동하는지 확인하기

Home에서 현재 선택된 서버를 확인하세요. 구독 그룹이 있는지만 확인해서는 안 됩니다. 구독을 가져왔다는 것은 설정 데이터를 읽을 수 있다는 뜻일 뿐, 포함된 모든 서버가 현재 온라인이라는 의미는 아닙니다. 구독 업데이트가 성공해도 계정 한도, 서비스 상태, 외부 접속이 정상이라고 단정할 수 없습니다.

선택 항목 확인

Home으로 이동해 이번에 테스트할 서버가 선택되어 있는지 확인합니다. 정책 그룹을 사용한다면 그룹에서 실제로 선택된 구성원도 확인해 기록한 테스트 대상과 일치하는지 살펴보세요.
매개변수 확인

해당 서버의 편집 화면을 열고 이용 중인 서비스에서 제공한 자료와 Type, 주소, Port를 대조합니다. Port에는 서비스 제공자가 안내한 값을 사용하세요. 웹사이트가 HTTPS를 사용한다는 이유만으로 443으로 바꾸면 안 됩니다.
테스트 실행

Home의 Connectivity Test로 연결 가능 여부를 확인한 다음, 대상 웹페이지도 실제로 열어 봅니다. 테스트 성공은 해당 테스트 방식과 대상에 한정되므로 실제 서비스 요청을 대신할 수 없습니다.
비교 테스트

이미 사용 중인 서버 중 하나로 바꾸되 네트워크, 모드, 대상은 그대로 유지합니다. 특정 서버만 실패한다면 Config 전체를 다시 작성하기보다 해당 서버의 매개변수와 서비스 상태부터 확인하세요.

프로토콜 매개변수는 서버 측 설정과 일치해야 합니다. 예를 들어 Trojan의 비밀번호와 TLS 호스트 이름, VMess 또는 VLESS의 인증 정보, 전송 방식과 경로는 핸드셰이크에 영향을 줄 수 있습니다. 한 번 시간 초과가 발생했다고 프로토콜을 임의로 바꾸지 말고, 호스트 이름이나 인증서 오류를 숨기기 위해 인증서 검증을 끄지도 마세요.

오류: Connection timed out

원인 및 해결 방법: 연결 로그에 이 문구가 표시되면 해당 작업이 제한 시간 안에 완료되지 않았다는 뜻입니다. 이것만으로 서버가 중지됐는지 네트워크 경로가 차단됐는지 판단할 수는 없습니다. 먼저 주소와 Port를 확인하고, 같은 설정으로 Wi-Fi와 셀룰러 네트워크를 비교한 뒤 이용 중인 서비스 제공자에게 서버 상태를 문의하세요.

오류: Connection refused

원인 및 해결 방법: 연결 로그에 이 문구가 표시되면 일반적으로 대상 포트에서 연결을 명시적으로 거부한 것입니다. 먼저 로그에 표시된 대상이 서버인지 웹사이트인지 확인한 뒤 해당 포트와 서비스의 수신 상태를 점검하세요. 반복해서 다시 연결해도 잘못 입력한 포트는 고쳐지지 않습니다.

2단계: Global Routing으로 모드와 서버 문제 구분하기

Home → Global Routing으로 이동해 먼저 현재 값을 기록합니다. Proxy, Direct, Config, Scene은 각각 용도가 다릅니다. Scene은 설정된 조건에 따라 라우팅 동작을 결정하므로, Scene을 선택했다는 이유만으로 요청이 어떤 경로를 지나는지 단정할 수 없습니다.

옵션	점검 목적	결과 해석
`Proxy`	프록시 경로 임시 확인	대상에 접속할 수 있다면 이번에 선택한 프록시 경로로 요청이 처리된 것입니다. 이어서 Config의 트래픽 분기 결과를 확인하세요.
`Direct`	직접 연결 경로 비교	직접 연결이 가능한 대상에도 접속할 수 없다면 로컬 네트워크와 DNS도 함께 확인해야 합니다. 서버 문제만으로 단정하지 마세요.
`Config`	현재 설정의 규칙에 따라 처리	이 모드에서만 실패한다면 현재 Config, 규칙 순서, 정책 그룹, 관련 DNS 설정을 집중적으로 확인하세요.
`Scene`	Scene 조건에 따라 처리	현재 네트워크에서 적용되는 Scene과 그 설정을 확인하세요. 비교를 위해 먼저 Proxy 또는 Config로 명확히 전환해 볼 수 있습니다.

모드를 바꾼 뒤에는 대상 앱의 연결을 새로 설정해 테스트하세요. 기존의 장시간 연결에는 전환 전 상태가 남아 있을 수 있으며, 페이지를 한 번 새로고침하는 것만으로는 캐시된 결과가 표시될 수도 있습니다. Direct 비교에는 원래 직접 접속할 수 있는 대상을 사용하세요. 특정 대상에 직접 접속되지 않는다는 사실만으로 로컬 네트워크 전체가 끊겼다고 판단할 수는 없습니다.

결론: Proxy에서 접속된다면 서버 설정은 우선 그대로 두기

같은 서버, 네트워크, 대상에서 Proxy는 접속되지만 Config는 접속되지 않는다면 Config로 돌아가 실제 적용된 정책과 DNS 설정을 확인하세요. 프로토콜, 서버 포트, 규칙을 한꺼번에 변경하지 마세요.

3단계: DNS 해석과 해석 이후의 연결을 따로 확인하기

도메인 해석은 대상에 접속하기 전에 이루어집니다. 서버 주소 자체가 도메인이라면 서버 주소도 먼저 해석해야 합니다. 따라서 DNS 문제는 대상 웹사이트뿐 아니라 프록시 연결 자체에도 영향을 줄 수 있습니다. 로그를 확인할 때는 먼저 어느 도메인의 해석이 실패했는지 구분하세요.

Config에서 현재 사용 중인 구성 파일을 확인한 다음 DNS 설정과 원본 텍스트의 [General]을 살펴봅니다. 일반적인 설정 항목인 dns-server는 DNS 해석기를 지정합니다. 시스템 DNS, 사용자 지정 일반 DNS, 암호화 DNS는 각각 접속 경로가 다르므로 주소 문자열만 비교해 같은 결과를 낸다고 판단할 수 없습니다.

[General]
dns-server = system

위 내용은 DNS 설정 예시일 뿐, 완전한 구성 파일이 아닙니다. 시스템 DNS를 임시로 비교 테스트하려면 백업한 설정 사본에서 기존 dns-server 항목을 수정하세요. 같은 이름의 항목을 여러 개 추가하거나 기존 규칙을 덮어쓰지 마세요. 시스템 DNS는 현재 네트워크에 따라 달라지므로 모든 대상에 적용되는 만능 해결책은 아닙니다.

해석 결과 확인: 방금 보낸 새 요청에 대해 로그에서 도메인 해석 실패가 표시되는지, A／AAAA 주소를 받았는지 확인합니다. 주소를 받았다는 것은 해석 단계에서 결과가 나왔다는 뜻일 뿐, 해당 주소에 연결할 수 있다는 의미는 아닙니다.
DNS 경로 확인: 일반 DNS는 보통 UDP 또는 TCP 53을 사용하고, DoH는 대개 HTTPS 443을 사용합니다. 일반 웹페이지가 열린다고 해서 특정 사용자 지정 DNS 서비스에도 접속할 수 있는 것은 아닙니다.
IPv4／IPv6 차이 확인: AAAA 주소를 받았더라도 현재 네트워크에서 IPv6 경로가 작동하지 않으면 일부 요청이 시간 초과될 수 있습니다. 먼저 Wi-Fi와 셀룰러 네트워크의 결과를 비교한 뒤 관련 설정을 조정하세요.
캐시 배제: 설정을 저장하고 다시 연결한 다음 대상 앱에서 새 연결을 시작합니다. 이전과 이후의 해석 결과를 기록해 캐시에 남은 이전 주소를 새 설정의 결과로 착각하지 않도록 하세요.

4단계: 현재 Config와 실제 적용된 규칙 확인하기

Home → Global Routing이 Config로 돌아와 있는지 확인한 뒤 Config에서 현재 사용 중인 파일을 확인합니다. 특정 사본을 편집했다고 해서 그 사본이 현재 구성으로 적용되는 것은 아닙니다. 규칙은 보통 순서대로 평가되며 먼저 일치하는 규칙이 요청에 적용될 정책을 결정합니다. 대상 도메인이 파일에 있는지만 검색하지 말고 실제로 적용된 규칙을 확인하세요.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

이 예시는 규칙 순서만 설명합니다. example.com과 하위 도메인은 DOMAIN-SUFFIX에 일치하면 PROXY로 전달되고, 나머지 미일치 요청은 FINAL,DIRECT로 처리됩니다. 여기서 PROXY는 현재 구성에서 사용할 수 있는 프록시 정책이어야 합니다. 사용자 지정 정책 그룹을 사용한다면 규칙 끝에 정의된 그룹 이름을 입력하세요. 이 조각을 완전한 Config로 그대로 대체하지 마세요.

도메인 범위 확인: DOMAIN-SUFFIX,example.com,PROXY는 전혀 다른 리소스 도메인까지 포함하지 않습니다. 웹페이지 본문은 열리지만 이미지나 로그인이 실패한다면 실패한 리소스의 실제 호스트 이름을 확인하세요.
앞선 규칙 확인: 대상 규칙보다 먼저 요청을 DIRECT 또는 REJECT로 보내는 규칙이 있는지 확인합니다. 도메인 규칙을 FINAL 뒤에 추가하면 원하는 대로 적용되지 않습니다.
IP 규칙 확인: GEOIP와 IP-CIDR은 IP를 기준으로 판단하므로 도메인 접미사 규칙처럼 사용할 수 없습니다. 요청의 해석 결과와 구성의 DNS 옵션을 기준으로 규칙 적용 여부를 확인하고, 웹사이트 이름만으로 추측하지 마세요.
정책 경로 확인: 로그에서 정책 그룹이 적용된 것을 확인한 뒤에는 그룹 내에서 현재 선택된 구성원도 확인해야 합니다. 그룹 이름이 올바르게 일치해도 그룹에서 선택된 서버가 작동한다는 보장은 없습니다.

웹페이지는 메인 도메인, 정적 리소스, 인증 도메인에 동시에 연결할 수 있습니다. 문서는 불러왔는데 페이지가 계속 로딩된다면 실패한 요청과 해당 요청에 적용된 정책을 기록하세요. 모든 트래픽을 Proxy로 바꾼 채 계속 사용하는 것은 피해야 합니다. 모드를 잠시 바꾸면 차이를 찾는 데 도움이 되며, 최종적으로는 실제로 조정해야 하는 규칙을 수정하세요.

자주 묻는 질문: 다음에 확인할 항목은 어떻게 판단하나요?

Connectivity Test 결과가 있는데 웹페이지가 열리지 않는 이유는 무엇인가요?

테스트 결과는 사용된 테스트 방식과 대상만 반영합니다. 같은 웹페이지에 새 요청을 보내 대상 도메인의 해석 결과, 실제 적용된 정책, 연결 오류를 각각 확인하세요. 특히 서버에 연결할 수 있는지, 프로토콜 핸드셰이크가 성공했는지, 대상 웹사이트에 접속할 수 있는지 구분해야 합니다.

Wi-Fi에서만 안 되고 셀룰러 네트워크에서는 된다면 무엇부터 바꿔야 하나요?

서버, Global Routing, Config는 그대로 두고 네트워크만 바꿔 다시 테스트하세요. Wi-Fi 인증을 완료하고 해당 네트워크의 DNS와 IPv6 상태도 확인합니다. 같은 서버가 특정 네트워크에서만 실패한다면 구독을 다시 만들기보다 해당 네트워크 경로부터 점검하세요.

구독을 업데이트해도 인터넷이 안 되는데 계속 새로고침해야 하나요?

먼저 Home에서 업데이트 후 실제 선택된 항목을 확인하고, 서비스 제공자가 안내한 매개변수 및 계정 상태와 대조하세요. 새로고침은 설정 데이터를 가져올 뿐 중지된 서비스를 복구하거나 로컬 Config의 부적절한 트래픽 분기 규칙을 자동으로 수정하지 않습니다.

스위치를 끈 뒤 다시 켜지는데 어떻게 비교 테스트하나요?

Settings → On Demand에서 현재 설정을 기록한 뒤 On Demand를 잠시 끄고 연결을 수동으로 제어하세요. 점검이 끝나면 원래 설정으로 복원하고, 평소 사용하는 Wi-Fi와 셀룰러 네트워크에서 자동 연결 동작을 각각 확인합니다.

마무리: 재현 가능한 기록을 저장하고 평소 설정 복원하기

점검이 끝나면 필요한 Global Routing과 On Demand 설정을 복원하고 수정된 Config가 실제로 사용 중인지 확인합니다. 한 번 접속에 성공했다고 모든 앱이 정상인 것은 아닙니다. 처음 실패했던 웹페이지와 페이지의 주요 리소스, 평소 사용하는 다른 앱의 요청도 한 번 이상 다시 테스트하세요.

조건 기록: 네트워크 유형, 선택한 서버의 로컬 메모, Global Routing 값, 현재 Config 이름, 테스트 시간.
차이 기록: 예를 들어 ‘같은 대상이 Proxy에서는 성공하고 Config에서는 시간 초과’처럼 기록하면 막연히 ‘연결이 안 됨’이라고 적는 것보다 원인을 찾기 쉽습니다.
오류 기록: 해당 요청의 대상 도메인, 적용된 정책, 원본 오류 문구를 보관하세요. 이용 중인 서비스 제공자에게 문의할 때는 필요한 정보만 전달합니다.
민감 정보 숨기기: 로그를 외부에 보내기 전에 구독 토큰, 비밀번호, UUID, 개인 키 등의 인증 정보를 삭제하고 전체 구독 링크를 공개하지 마세요.

그 밖의 설정 방법은 사용 튜토리얼을 참고하세요. 설정을 항목별로 확인하려면 설정 상세 안내를 읽어 보세요. 클라이언트 구매와 사용자가 별도로 이용하는 네트워크 서비스는 각각 관리되며, 클라이언트의 일회성 구매에 네트워크 이용권이 포함되는 것은 아닙니다.