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

이 글의 핵심

Shadowrocket의 연결 스위치를 켰다는 것은 클라이언트가 연결을 시작했다는 뜻일 뿐, 서버와 DNS, 웹사이트가 모두 정상이라고 단정할 수는 없습니다. 서비스 제공업체와 구독을 이미 이용 중이며 앱은 열리지만 웹페이지에 접속할 수 없는 경우에 참고하세요. ‘기본 네트워크 → 서버 → Global Routing → DNS → Rule’ 순서로 점검하고, 한 번에 하나씩만 변경한 뒤 같은 URL로 다시 테스트하세요. 마지막에는 문제 원인을 설명할 수 있는 점검 기록을 남겨 두세요.

먼저 재현 가능한 기준 상태를 기록하세요

점검을 시작하기 전에 현재 네트워크, Home에서 선택한 서버, Global Routing 설정값, Config에서 사용 중인 구성 파일을 기록하세요. 설정을 변경하기 전에 백업도 해 두세요. 처음부터 구독을 업데이트하고 서버를 바꾸고 DNS까지 교체하면, 문제가 해결되더라도 어떤 조치가 효과가 있었는지 알기 어렵습니다.

아래 경로는 iPhone / iPad 화면의 Home, Config, Settings를 기준으로 안내합니다. 다른 플랫폼에서는 해당 플랫폼의 설정 항목을 확인하세요. 모바일 기기의 시스템 VPN 안내가 모든 기기에 공통으로 표시되는 것은 아닙니다. 평소 접속할 수 있지만 지금 문제가 발생한 웹사이트를 테스트 대상으로 사용하고, 출처가 불분명한 링크로 판단하지 마세요.

On Demand 일시 중지

먼저 Settings → On Demand의 기존 설정을 기록한 뒤, 점검 중에는 자동 연결을 잠시 중지하세요. 연결을 수동으로 껐는데 다시 자동으로 켜지는 상황을 막을 수 있습니다. 테스트가 끝나면 원래 설정으로 복구하세요.
기본 네트워크 확인

Home에서 연결 스위치를 끄고 평소 바로 접속할 수 있는 웹페이지를 열어 보세요. 여전히 접속되지 않는다면 Wi-Fi 로그인 인증, 라우터의 인터넷 연결, 셀룰러 데이터 권한부터 확인하고 규칙 설정은 변경하지 마세요.
테스트 대상을 고정하세요

바로 접속할 수 있는 URL 하나와 문제가 발생하는 URL 하나를 골라 각각 결과를 기록하세요. 매번 동일한 전체 주소를 새로 열어 테스트해야 웹사이트별 상태가 뒤섞이지 않습니다.
연결 다시 시작

다른 VPN 연결이 동시에 실행 중이지 않은지 확인한 뒤 Shadowrocket의 연결 스위치를 켜세요. 설정을 변경한 후에는 요청을 새로 보내 테스트하세요. 브라우저에 캐시된 페이지가 표시되는 것만으로 문제가 해결됐다고 판단하지 마세요.

서버가 실제로 작동하는지 확인

Home에 서버 항목이 있다고 해서 해당 서버가 여전히 유효한 것은 아닙니다. 먼저 사용하려는 항목이 선택되어 있는지 확인한 뒤 Connectivity Test를 실행하세요. 테스트 결과는 방식과 대상에 따라 달라집니다. 지연 시간이 표시되어도 이번 테스트가 통과했다는 뜻일 뿐, 모든 도메인·프로토콜·웹사이트에 접속할 수 있다는 의미는 아닙니다. 한 번 시간 초과가 발생했다고 구독 전체가 만료됐다고 단정할 수도 없습니다.

서버 항목의 편집 정보를 열어 서비스 제공업체가 안내한 값과 하나씩 대조하세요. 주소, 포트, 인증 정보, 암호화 방식, TLS 관련 항목이 서로 맞아야 합니다. 서버 포트에는 공통 기본값이 없으므로 웹에서 흔히 쓰는 443을 모든 프로토콜의 포트로 입력하지 마세요. 서버 주소에 도메인을 사용하는 경우 해당 도메인이 먼저 정상적으로 조회되는지도 확인해야 합니다.

모든 항목에서 시간 초과: Wi-Fi에서 셀룰러 네트워크로 바꿔 다시 테스트하세요. 한 네트워크에서만 실패한다면 서버 설정을 일괄 변경하기보다 해당 네트워크의 접속 제한을 확인하세요.
항목 하나만 실패: 이미 사용 가능한 것으로 확인된 다른 구독 항목과 비교하세요. 문제가 있는 항목의 상태, 사용량 한도, 유효 기간은 해당 서비스 제공업체에 문의하세요.
업데이트 후에도 이전 주소가 표시됨: Home에서 구독을 업데이트하고 업데이트 결과와 항목 내용을 확인하세요. 업데이트 성공은 데이터를 가져와 해석했다는 뜻이지, 원격 서버가 작동한다는 뜻은 아닙니다.
업데이트 자체가 실패함: 기존 구성을 보존하고 구독 URL의 유효성과 네트워크 연결부터 확인하세요. 비공개 구독 URL을 공개 게시판에 올리지 마세요. URL에 포함된 token이 계정 권한을 가질 수 있습니다.

오류 세부 정보에 아래 문구가 표시되면 해당 방향으로 원인을 좁혀 보세요. 프로토콜과 시스템에 따라 오류 문구는 다를 수 있으며, 이는 오류를 추적하기 위한 단서이지 앱 화면에 반드시 표시되는 고정 문구는 아닙니다.

오류: connection refused

원인 및 해결: 원격 서버 또는 중간 장비가 연결을 명시적으로 거부한 상태입니다. 포트에서 서비스가 수신 대기 중이 아니거나 접속 정책에 의해 차단된 경우가 흔합니다. 서버 주소와 포트를 확인하고 서비스 제공업체에 수신 상태를 문의하세요. 포트 연결 거부 문제를 DNS를 반복해서 변경해 해결하려 하지 마세요.

오류: i/o timeout

원인 및 해결: 제한 시간 안에 작업이 완료되지 않았다는 뜻입니다. 네트워크 경로, 원격 서버 응답, 이름 조회 대기 등이 원인일 수 있습니다. 로그에서 어느 단계에서 시간 초과가 발생했는지 확인한 뒤 네트워크를 바꾸거나 기존에 사용 가능한 다른 항목과 비교하세요. 이 문구만으로 비밀번호가 틀렸다고 판단할 수는 없습니다.

오류: no such host

원인 및 해결: 도메인 조회에서 사용할 수 있는 결과를 얻지 못한 상태입니다. 오류에 표시된 도메인이 서버 도메인인지 대상 웹사이트 도메인인지 먼저 확인한 뒤 철자, DNS 설정, 해당 도메인의 존재 여부를 점검하세요.

모드로 규칙 문제 분리하기

Home → Global Routing에서 현재 값을 확인한 다음 짧게 비교 테스트하세요. Proxy, Direct, Config, Scene은 연결 품질을 나타내는 단계가 아니며, 뒤에 있는 항목일수록 더 안정적이라는 뜻도 아닙니다. 연결 스위치가 켜져 있어도 현재 요청이 반드시 프록시 서버를 거친다고 볼 수 없습니다.

설정값	의미	점검 방법
`Proxy`	요청을 프록시 경로로 처리하며, 일반적인 구성 규칙에 따라 항목별로 분기하지 않습니다.	선택한 서버로 대상에 접속할 수 있는지 확인하는 데 사용합니다. DNS, 프로토콜, 시스템 라우팅 등의 영향도 고려해야 합니다.
`Direct`	요청을 직접 연결 경로로 처리합니다.	현재 네트워크에서 직접 접속할 수 있는지 비교하는 데 사용합니다. 연결 스위치를 켰다고 자동으로 프록시를 통한 접속으로 바뀌지는 않습니다.
`Config`	현재 구성된 규칙에 따라 요청 처리 방식을 결정합니다.	Proxy에서는 정상인데 Config에서 실패한다면 먼저 규칙 일치 결과와 선택된 정책을 확인하세요.
`Scene`	설정된 Scene 조건에 따라 동작을 선택합니다.	현재 활성화된 Scene과 관련 설정을 확인하세요. 변수를 줄이려면 Proxy 또는 Config로 잠시 전환해 비교 테스트할 수 있습니다.

판단 기준: 성공한 경로부터 유지

같은 네트워크와 서버, URL을 사용했을 때 Proxy에서는 열리지만 Config에서는 열리지 않는다면 서버 설정은 유지하고 현재 구성의 일치 규칙과 정책 그룹을 확인하세요. 앱을 재설치하거나 구독을 전부 다시 가져오는 조치부터 할 필요는 없습니다.

Proxy와 Config 모두 실패하더라도 곧바로 규칙 문제라고 단정하지 마세요. 먼저 서버를 다시 테스트한 뒤 DNS를 확인하세요. 비교를 마치면 원래 필요한 Global Routing 값으로 복구하고, 임시 테스트 모드를 해결된 정식 설정으로 착각하지 마세요.

도메인 조회 문제와 연결 문제 구분하기

DNS는 도메인을 주소로 변환하지만, 그 뒤에도 서버·TLS·대상 웹사이트 단계에서 연결이 실패할 수 있습니다. 브라우저가 계속 로딩된다는 이유만으로 DNS 오류라고 볼 수는 없습니다. 반대로 DNS에서 주소를 받았다고 해당 주소의 서비스에 접속할 수 있다는 뜻도 아닙니다. 요청 기록의 도메인, 조회 결과, 오류가 발생한 단계를 함께 확인하세요.

일반 DNS에 흔히 쓰이는 포트이며 UDP 또는 TCP를 사용할 수 있습니다.

443

HTTPS에 흔히 쓰이는 포트로, 모든 프록시 서버가 사용하는 포트는 아닙니다.

도메인 유형 2가지

서버 도메인과 대상 웹사이트 도메인의 조회 결과를 각각 확인하세요.

Config에서 현재 사용 중인 구성을 찾아 편집 내용을 열고 [General] 아래의 dns-server를 확인하세요. 사용자 지정 DNS가 이미 설정되어 있다면 먼저 기존 값을 백업한 뒤 하나씩 비교하세요. 아래는 시스템 DNS를 사용하는 구성 예시일 뿐, 구성 파일 전체를 이 두 줄로 교체하라는 뜻은 아닙니다.

[General]
dns-server = system

먼저 시스템 DNS로 테스트: 변경 사항을 저장하고 연결을 다시 시작한 뒤 같은 문제의 URL에 접속해 보세요. 정상으로 돌아오면 기존 사용자 지정 DNS의 연결 가능 여부와 접속 경로를 확인하세요. 모든 사용자 지정 DNS에 문제가 있다고 단정하지 마세요.
도메인 조회의 선행 조건 확인: 서버 주소가 도메인이라면 프록시에 연결하기 전에 해당 도메인을 조회해야 할 수 있습니다. 이 단계에서 실패하면 대상 웹사이트 규칙만 바꿔서는 서버에 연결할 수 없습니다.
캐시 영향 배제: 요청을 새로 보내고, 필요한 경우 연결을 다시 시작하거나 관련 앱을 재시작하세요. DNS를 여러 번 연달아 바꾼 뒤 한 번 성공한 결과만으로 모든 원인을 단정하지 마세요.
HTTPS 도메인 대신 IP를 바로 입력하지 마세요: 인증서 이름 또는 SNI가 일치하지 않아 새로운 오류가 발생할 수 있습니다. 일반적인 DNS 검증 방법으로 사용할 수 없습니다.

규칙 순서와 FINAL 확인

Global Routing이 Config일 때 Config로 들어가 실제 활성화된 파일을 확인하세요. 선택되지 않은 복사본만 편집하지 않도록 주의합니다. 규칙은 보통 순서대로 일치 여부를 확인하므로 앞쪽의 포괄적인 규칙이 뒤쪽의 구체적인 규칙보다 먼저 적용될 수 있습니다. 마지막의 FINAL은 앞선 규칙에 일치하지 않은 요청에 적용할 기본 정책입니다.

아래는 규칙이 일치하는 순서를 이해하기 위한 최소 예시입니다. example.com은 예시 도메인이므로 실제로 문제가 발생한 웹사이트 대신 사용하지 마세요. 테스트에 적용하기 전에 구성 파일을 백업하세요. 이 예시는 일상적인 접속에 필요한 모든 규칙을 포함하지 않으며 서버나 DNS 문제를 자동으로 해결하지도 않습니다.

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

규칙 키워드	예시의 의미	놓치기 쉬운 확인 사항
`DOMAIN-SUFFIX`	지정된 도메인과 하위 도메인을 일치시킵니다.	프로토콜, 경로, 포트 없이 도메인만 입력하세요. 웹사이트에서 실제로 요청하는 다른 도메인도 확인해야 합니다.
`IP-CIDR`	IPv4 대역과 일치합니다. 예시는 사설 주소 범위입니다.	`no-resolve`는 이 IP 규칙에서 도메인 조회를 능동적으로 시작하지 않는다는 뜻이지, DNS를 전체적으로 끈다는 뜻은 아닙니다.
`GEOIP`	IP 지리 데이터베이스를 기준으로 일치 여부를 판단합니다.	분류 결과는 조회 결과와 데이터베이스에 따라 달라질 수 있으며, 도메인이 속한 지역과 같은 의미가 아닙니다.
`FINAL`	앞선 규칙과 일치하지 않은 요청에 적용할 정책을 지정합니다.	규칙 목록의 마지막에 배치하세요. 예시의 정책은 DIRECT이며, 앞선 규칙에 일치하지 않은 요청은 직접 연결됩니다.

일부 웹사이트만 열리지 않는다면 요청 기록에서 일치한 규칙과 최종 정책을 확인하세요. 프록시로 접속해야 하는 웹사이트가 FINAL,DIRECT에 일치했다면 먼저 해당 도메인의 분기 규칙을 수정해야 합니다. 사용자 지정 정책 그룹에 일치한 경우에는 그 그룹에서 현재 선택한 서버도 유효한지 확인하세요. 규칙이 제대로 일치해도 정책 그룹의 출구 서버가 작동한다는 보장은 없습니다.

구체적인 도메인 규칙을 관련 포괄 규칙보다 앞에 배치해 먼저 적용되도록 하세요.
사용자 지정 정책 이름이 실제로 존재하는지, 철자가 일치하는지 확인하세요. 주석에 적힌 이름을 유효한 정책으로 오인하지 마세요.
수정한 뒤 저장하고 해당 파일이 계속 활성화되어 있는지 확인하세요. 요청을 새로 보내 일치 결과가 예상대로 바뀌었는지 살펴보세요.

증상에 따라 마무리 테스트

문제 범위를 좁힌 다음 On Demand 등의 일상 설정을 복구하고 한 번 더 테스트하세요. 특히 Wi-Fi에서 셀룰러 네트워크로 바꾼 뒤에는 Scene 조건과 자동 연결이 앞서 내린 판단을 무효로 만들지 않았는지 확인해야 합니다. 아래 질문을 참고해 어떤 설정을 유지하고 무엇을 더 확인할지 판단하세요.

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

지연 시간 테스트와 실제 웹페이지 접속은 대상과 진행 과정이 다를 수 있습니다. 서버를 그대로 유지한 채 Home → Global Routing에서 Proxy로 잠시 전환해 문제가 있는 URL을 테스트하고, DNS와 오류 발생 단계를 확인하세요. 지연 시간이 표시된다고 전체 접속이 성공한 것은 아닙니다.

웹사이트 하나만 열리지 않는데 앱을 다시 설치해야 하나요?

먼저 다시 설치하지 마세요. Config에서 해당 웹사이트에 실제로 적용된 규칙과 정책을 확인하세요. Proxy에서도 그 웹사이트만 실패한다면 웹사이트 자체의 상태, 인증서 시간, 접속 제한 안내가 있는지 살펴보세요.

Wi-Fi에서는 안 되는데 셀룰러 네트워크에서는 됩니다. 무엇을 바꿔야 하나요?

서버와 구성을 그대로 둔 채 두 네트워크에서 같은 URL을 테스트하세요. 먼저 Wi-Fi 로그인 인증을 마친 뒤 해당 네트워크의 DNS와 접속 제한을 확인하세요. 이어서 Settings → On Demand와 Scene의 네트워크 조건을 점검하고 구독 설정을 한꺼번에 바꾸지 마세요.

구독을 업데이트했는데도 연결되지 않습니다. 다음 단계는 무엇인가요?

Home에서 새 항목이 선택되어 있는지 확인하고 서비스 유효 기간, 사용량 한도, 주소를 점검하세요. 기존의 다른 항목은 작동한다면 실패한 시간, 네트워크 유형, 민감 정보를 가린 오류 내용을 서비스 제공업체에 보내세요. 전체 구독 URL이나 인증 정보는 공개하지 마세요.

계속 원인을 찾아야 한다면 ‘네트워크 유형, Global Routing 값, 서버 테스트 결과, DNS 비교 결과, 일치 규칙, 최종 정책, 원문 오류’ 일곱 가지를 정리하세요. 공유하기 전에 구독 token, 비밀번호, UUID 및 기타 인증 정보를 삭제하세요. 구성 키워드의 의미는 구성 필드에서 확인할 수 있습니다. 원인을 찾지 못한 상태를 감추기 위해 출처를 모르는 전체 구성을 붙여 넣지 마세요.