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

이 글의 핵심

이 글은 Shadowrocket 연결은 켜져 있지만 브라우저나 일부 앱에서 접속할 수 없는 경우를 다룹니다. 사용 중인 서비스와 설정이 있다는 전제에서 직접 연결 상태를 기준으로 삼고, 서버를 확인한 뒤 Global Routing 모드를 바꿔 비교합니다. 이어 DNS와 규칙 적용 여부를 점검하세요. 한 번에 한 항목만 변경하고 같은 페이지의 결과를 기록한 다음, 마지막에 원래 설정으로 되돌리세요.

1. VPN 연결과 웹페이지 접속은 별개입니다

Home에서 연결 스위치를 켜면 기기의 VPN 연결이 시작된다는 뜻입니다. 원격 서버 인증이 성공했다거나 원하는 웹사이트에 접속할 수 있다는 의미는 아닙니다. 시스템에 VPN 표시가 있어도 DNS, 서버 출구, 규칙 정책이 모두 정상이라고 볼 수 없습니다. 스위치 상태만으로 문제 지점을 판단하지 마세요.

먼저 현재 네트워크에서 평소 직접 접속되는 웹페이지 하나와 문제가 발생한 웹페이지 하나를 선택하세요. 이후에는 이 두 곳을 계속 테스트합니다. 테스트할 때 페이지를 새로고침하고, 필요하면 기존 탭을 닫았다가 다시 여세요. 이미 표시된 캐시 페이지를 이번 연결의 성공으로 착각하지 않도록 합니다.

4개 항목

점검 순서: 서버 → 모드 → DNS → 규칙

한 번에 1개

매 회차 한 가지 항목만 변경하고 결과를 기록하세요

2개

테스트 대상 고정: 직접 연결 비교 페이지와 오류 페이지

현재 설정 기록

Home에서 선택된 서버와 Global Routing 모드를 기록하고, Config에서 현재 선택된 구성 파일을 확인하세요. 설정을 변경하기 전에 사본을 보관하고 기존 DNS 설정도 적어 두세요.
자동 연결 확인

Settings → On Demand로 이동해 현재 설정을 기록하세요. 테스트 중 연결이 다시 시작될 수 있다면 잠시 끄고, 점검을 마친 뒤 원래 설정으로 복원하세요.
직접 연결 상태 확인

Home으로 돌아가 연결 스위치를 끄고 연결이 실제로 중지됐는지 확인한 다음, 직접 연결 비교 페이지를 여세요. 여전히 접속되지 않으면 현재 Wi-Fi에 로그인이 필요한지, 셀룰러 데이터가 작동하는지 먼저 확인하세요.
문제 재현

연결을 다시 켜고 기존 서버, 모드, 구성을 그대로 둔 채 두 테스트 대상에 접속하세요. 모두 실패하는지, 특정 도메인이나 앱에서만 실패하는지 기록합니다.
테스트 조건 고정

먼저 같은 네트워크에서 서버와 모드를 점검하세요. Wi-Fi와 셀룰러 데이터를 바꿔 테스트하려면 별도 회차로 진행하고, 구성 업데이트나 서버 변경을 동시에 하지 마세요.

2. 서버 점검: 연결 여부를 확인한 뒤 인증 정보 확인

Home → SERVER에서 현재 선택 항목을 확인한 다음 Connectivity Test를 실행하세요. 지연 시간 결과는 해당 테스트 방식으로 응답을 받았다는 뜻일 뿐입니다. 테스트 방식마다 확인하는 연결 경로가 다르므로, 한 번의 수치만으로 모든 도메인과 전송 방식, 전체 요청이 정상이라고 판단할 수 없습니다.

모든 서버에서 시간 초과가 발생한다면 먼저 직접 연결 상태와 현재 네트워크를 다시 확인하세요. 특정 서버 하나만 실패하면 해당 항목의 주소, 포트, 프로토콜 설정을 확인합니다. 주소가 도메인일 수 있으며 도메인 자체도 DNS 확인이 필요하므로, 서버 연결 시간 초과가 원격 서비스 중단을 뜻하는 것은 아닙니다.

주소와 포트: 선택한 서버의 편집 화면을 열고 서비스 제공업체가 안내한 정보와 항목별로 대조하세요. 포트 443은 HTTPS에 자주 쓰이지만 서버가 실제로 이 포트를 사용하는지는 설정을 확인해야 합니다. TLS가 보인다는 이유만으로 포트를 443으로 바꾸지 마세요.
인증 정보: Shadowsocks의 비밀번호와 암호화 방식, VMess 및 VLESS의 UUID, Trojan의 비밀번호를 각각 확인하세요. 주소와 포트만 입력했다고 설정이 완성된 것은 아닙니다.
전송 설정: TLS, WebSocket 등을 사용하는 경우 TLS 서비스 이름, Host, Path를 확인하세요. 서버 주소와 값이 다를 수 있으므로 임의로 통일하지 말고 원본 설정에 따라 입력해야 합니다.
구독 설정: 서비스 제공업체가 구성이 변경됐다고 안내한 경우에만 기존 구독을 업데이트하세요. 업데이트 후 선택 항목을 다시 확인합니다. 업데이트 성공은 구성을 가져왔다는 뜻이지, 구성에 포함된 모든 서버가 작동한다는 뜻은 아닙니다.

로그 원문은 오류가 발생한 단계를 파악하는 데 도움이 됩니다. 아래에는 흔히 볼 수 있는 네트워크 오류 문구를 정리했습니다. 프로토콜이나 시스템 환경에 따라 문구 앞뒤에 주소나 오류 도메인이 붙을 수 있습니다. 실제 로그에 해당 문구가 있을 때만 알맞은 원인을 참고하세요. 브라우저에 빈 화면이 떴다는 이유만으로 특정 오류라고 단정하지 마세요.

오류: connection refused

원인 및 해결: 대상 또는 중간 장치가 연결을 명시적으로 거부한 상태입니다. 포트에서 서비스가 대기 중이지 않거나 주소·포트가 맞지 않을 때 흔히 발생합니다. 먼저 서버 주소와 포트를 확인하고 서비스 제공업체에 해당 접속 지점의 상태를 문의하세요. 이 오류만으로 비밀번호가 틀렸다고 단정할 수는 없습니다.

오류: connection timed out

원인 및 해결: 제한 시간 안에 연결이 완료되지 않은 상태입니다. 네트워크 경로, 포트 차단, 서버 무응답 등이 원인일 수 있습니다. 먼저 같은 구성을 다른 네트워크에서 테스트하고, 사용 가능한 다른 서버가 있다면 한 가지 조건만 바꿔 비교하세요.

오류: certificate verify failed

원인 및 해결: TLS 인증서 확인에 실패한 상태입니다. 기기 시간, 서비스 이름 불일치, 인증서 체인 문제가 원인일 수 있습니다. 시스템 날짜와 구성에 입력된 TLS 서비스 이름을 확인하고 서비스 제공업체에 인증서를 확인해 달라고 요청하세요. 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요.

3. Global Routing: 모드를 비교해 문제 범위 좁히기

Home → Global Routing에서 현재 모드를 확인하세요. 문제를 진단할 때 Proxy와 Direct를 비교하면 프록시 경로와 직접 연결 경로를 구분하는 데 도움이 됩니다. 평소 Config 모드를 사용한다면 구성에 지정된 개별 규칙도 확인해야 합니다. Scene은 선택된 장면의 설정을 함께 살펴야 하며 이름만으로 트래픽 경로를 판단할 수 없습니다.

모드	점검 목적	결과 해석
Proxy	일반적인 대상 요청을 현재 프록시 정책으로 보내 단시간 비교합니다.	Proxy에서는 작동하지만 Config에서 실패한다면 규칙과 정책 선택을 우선 확인하세요. DNS 경로 차이도 확인해야 합니다.
Direct	대상에 직접 연결해 현재 네트워크에서 접속할 수 있는지 확인합니다.	Direct에서는 작동하지만 Proxy에서 실패한다면 서버와 프록시 경로를 우선 확인하세요. 그렇다고 모든 대상이 직접 연결되어야 한다는 뜻은 아닙니다.
Config	현재 선택된 구성의 규칙에 따라 트래픽을 분기합니다.	Config에서 선택된 파일, 규칙 순서, 규칙이 지정하는 정책의 사용 가능 여부를 확인하세요.
Scene	현재 장면 설정에 따라 라우팅합니다.	실제로 선택된 장면과 해당 설정을 확인하세요. 장면의 영향을 배제하려면 기존 값을 기록한 뒤 명확한 비교 모드를 잠시 사용합니다.

판단 기준: Proxy에서 성공하면 Config를 다시 확인하세요

같은 서버, 네트워크, 대상에서 Proxy는 성공하고 Config는 실패한다면 Config로 돌아가 실제로 적용된 규칙과 정책을 확인하세요. 서버 설정 전체를 바로 다시 만들 필요는 없습니다. 비교가 끝나면 원래 모드로 복원하세요.

모드를 바꾼 뒤 요청을 새로 시작하세요. 브라우저나 앱이 기존 연결을 유지할 수 있으므로 화면만 새로고침한다고 새 연결이 만들어지는 것은 아닙니다. 특정 앱에서만 문제가 발생한다면 앱을 완전히 종료한 뒤 다시 열고, 브라우저에서 같은 서비스를 비교해 앱 캐시 문제와 연결 경로 문제를 구분하세요.

4. DNS 점검: 지연 시간 응답만으로 도메인 확인을 판단할 수 없습니다

DNS는 도메인을 주소로 변환합니다. 서버에 연결되거나 Connectivity Test 결과가 나오는 것과 대상 도메인이 정상적으로 확인되는 것은 별개의 문제입니다. 주소를 받았더라도 접속할 수 없는 IPv6 주소나 잘못된 주소, 현재 네트워크에 맞지 않는 결과가 반환되면 웹페이지가 계속 시간 초과될 수 있습니다.

Config에서 현재 선택된 구성을 열고 DNS 관련 설정을 확인하세요. 먼저 DNS 서버 주소, 암호화 DNS 사용 여부, DNS 요청이 의존하는 네트워크 경로를 기록합니다. 선택되지 않은 구성 파일만 확인하거나 DNS와 서버를 동시에 변경하지 마세요. 어떤 변경이 영향을 줬는지 판단하기 어려워집니다.

주소 형식 확인: 일반 DNS는 보통 포트 53을 사용하고, DoH는 대개 HTTPS의 443 포트로 접속합니다. 다른 포트를 설정했다면 실제 서비스 요구사항을 따르세요. 포트가 정상이어도 프로토콜이나 주소 형식이 올바르다는 보장은 없습니다.
DNS 서버 연결 확인: DNS 서버에 특정 프록시 경로를 통해서만 접속할 수 있고, 프록시 서버의 도메인도 해당 DNS 서버에 의존한다면 시작 단계에서 순환 의존 문제가 생길 수 있습니다. 원본 설정 안내를 바탕으로 DNS 경로를 확인하고 연결을 반복해서 껐다 켜지 마세요.
실패 범위 확인: 서로 관련 없는 여러 도메인에서 DNS 오류가 발생한다면 DNS 서버를 우선 확인하세요. 도메인 하나에서만 실패한다면 전체 도메인과 반환된 결과를 기록한 뒤 해당 도메인의 규칙과 대상 서비스 상태를 확인합니다.
변경 적용 여부 확인: 구성을 저장한 뒤 다시 연결하고 테스트할 앱도 새로 여세요. DNS 캐시가 결과에 영향을 줄 수 있으므로 기존 연결에서 계속 접속된다는 이유만으로 새 설정이 검증됐다고 판단하지 마세요.

5. 규칙 점검: REJECT 검색에 그치지 말고 실제 적용 여부 확인

Home으로 돌아가 Global Routing을 Config로 복원한 뒤 Config에서 현재 선택된 파일을 확인하세요. 규칙은 보통 순서대로 확인하며, 먼저 일치하는 규칙이 해당 연결의 처리 방식을 결정합니다. 파일에 REJECT가 있다고 모든 요청이 차단되는 것은 아닙니다. 실제 대상이 해당 규칙과 일치할 때만 원인이 될 수 있습니다.

아래는 문법 설명을 위한 예시이며 완전한 구성 파일이 아니므로 기존 규칙을 그대로 대체하는 용도로 권장하지 않습니다. 예시 도메인과 문서용 주소는 필드 설명에만 사용합니다. 첫 번째 항목은 규칙 유형, 두 번째 항목은 보통 일치 조건, 마지막 항목은 정책입니다. FINAL에는 일치 조건 항목이 없습니다.

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

DOMAIN-SUFFIX: DOMAIN-SUFFIX,example.com,REJECT는 example.com과 하위 도메인에 적용됩니다. 실제 서비스 도메인이 같은 유형의 규칙과 일치한다면 서버만 바꿔도 차단 결과는 달라지지 않을 수 있습니다.
IP-CIDR: 대상 IP 대역과 일치하는지 확인합니다. 예시의 192.0.2.0/24는 문서용 예시 대역입니다. no-resolve는 이 규칙을 적용하기 위해 도메인을 별도로 확인하지 않는다는 뜻이지, 구성 전체에서 DNS를 끈다는 의미는 아닙니다.
GEOIP: 대상 IP의 지리적 위치 데이터에 따라 일치 여부를 판단합니다. 웹페이지 언어나 도메인 접미사를 기준으로 하지 않습니다. DNS 결과가 바뀌면 이후 IP 기반 규칙의 적용 결과도 달라질 수 있습니다.
FINAL: 앞선 규칙과 일치하지 않은 연결을 처리합니다. 예시는 PROXY를 지정합니다. 실제 구성에서 사용자 지정 정책 그룹을 사용한다면 규칙 끝의 이름만 보지 말고 해당 그룹에서 현재 선택된 항목도 확인하세요.

앱의 요청 기록이나 로그에서 문제가 발생한 도메인, 적용된 규칙, 최종 정책을 확인하세요. 웹페이지는 주 도메인 외에도 로그인 도메인과 정적 리소스 도메인에 요청을 보낼 수 있습니다. 메인 페이지는 열리지만 로그인 버튼이 반응하지 않는다면 주소창의 주 도메인만 확인하지 말고 실패한 실제 요청을 살펴보세요.

6. 자주 묻는 질문: 일부만 실패하는 경우, 자동 연결, 설정 복원

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

지연 시간 테스트와 웹페이지 접속은 같은 대상이나 전체 경로를 사용하지 않을 수 있습니다. Home에서 선택된 서버를 확인한 뒤 Proxy 모드로 문제가 발생한 페이지를 테스트하세요. 그래도 실패한다면 서버 인증 정보와 DNS를 점검합니다. 지연 시간 수치만으로 웹페이지에 접속할 수 있다고 판단하지 마세요.

웹사이트 하나만 열리지 않아도 서버를 바꿔야 하나요?

먼저 해당 사이트에서 실패한 도메인을 기록하고 Proxy와 Config 결과를 비교하세요. Config에서만 실패한다면 해당 도메인에 적용된 규칙을 우선 확인합니다. 두 모드에서 모두 실패한다면 DNS 결과, 대상 서비스 상태, 프록시 출구 경로를 점검하세요.

스위치를 껐는데 다시 자동으로 연결되는 이유는 무엇인가요?

Settings → On Demand에서 자동 실행 조건이 설정되어 있는지 확인하세요. 점검 중에는 기존 값을 기록한 뒤 잠시 끄고 Home으로 돌아가 연결이 중지됐는지 확인합니다. 테스트가 끝나면 원래 설정을 복원해 자동 재연결을 스위치 고장으로 오해하지 않도록 하세요.

셀룰러 데이터에서는 정상인데 서버에 문제가 없다는 뜻인가요?

같은 구성이 다른 네트워크에서는 작동한다는 뜻이므로 문제 범위는 원래 네트워크 경로에 더 가까울 수 있습니다. 기존 Wi-Fi로 돌아가 네트워크 로그인, DNS 서버 연결, 포트 제한을 확인하세요. 같은 서버와 모드를 유지해 다시 테스트하되, 이 결과만으로 모든 네트워크에서 연결할 수 있다고 보장할 수는 없습니다.

7. 복구 확인: 나중에 검토할 수 있도록 결과 기록

복구 기준은 스위치 표시가 다시 켜지는 것이 아니라, 이전에 실패한 대상에서 예상한 모드로 요청을 완료하는 것입니다. 평소 사용하는 Global Routing, 구성 파일, On Demand 설정을 복원한 뒤 직접 연결 비교 페이지와 오류 페이지를 다시 테스트하세요. 원래 설정으로 되돌린 뒤 문제가 재현된다면 임시 비교 과정에서 문제를 우회했을 뿐, 해결된 것은 아닙니다.

최종적으로 작동한 네트워크 유형, 선택된 서버, 구성 파일, Global Routing 모드를 기록하세요.
문제가 발생했던 앱을 다시 열어 페이지 로딩, 로그인, 리소스 요청을 확인하세요. 홈 화면 제목이 표시되는지만 확인해서는 안 됩니다.
임시 DNS 변경, 규칙 예외, 자동 연결 설정이 평소 사용 목적에 맞는지 확인하고 변경 전 구성 사본을 보관하세요.
서비스 제공업체에 문의해야 한다면 실패한 시간, 프로토콜 유형, 오류 문구, 모드 비교 결과를 전달하세요. 비밀번호, UUID, 구독 토큰 등 민감한 정보는 가려야 합니다.

Shadowrocket은 Apple 플랫폼용 유료 클라이언트이며 App Store에서만 받을 수 있습니다. 개발자는 Shadow Launch Technology Limited입니다. 클라이언트 구매와 회선 요금제는 별개입니다. 이 글은 이미 구성을 보유한 사용자를 위한 점검 안내이며, 서버, 구독 또는 서비스 제공업체를 제공하거나 판매·추천하지 않습니다. 시스템 요구 사항은 App Store 페이지를 확인하세요.