Shadowrocket 연결은 됐는데 인터넷이 안 될 때: 서버·Global Routing·DNS·규칙 점검

핵심 내용

Shadowrocket의 스위치가 켜졌다는 것은 로컬 연결이 시작되었음을 뜻할 뿐, 원격 서버와 DNS, 대상 웹사이트가 모두 정상이라는 의미는 아닙니다. 설정을 가져왔지만 웹페이지가 열리지 않는 경우를 대상으로 합니다. 먼저 연결을 끈 상태의 네트워크를 확인한 뒤 서버, 라우팅 옵션, 도메인 해석, 규칙 적용을 차례로 점검하세요. 한 번에 한 항목만 변경하고 결과를 기록한 다음, 평소 사용하는 라우팅 설정으로 복원합니다.

1. 문제 범위를 확인하고 기존 설정 보존하기

점검을 시작하기 전에 현재 설정을 복사해 두고 Home에서 선택한 서버, Global Routing 옵션, Config에서 사용 중인 설정을 기록하세요. 이 문서에서는 iPhone / iPad의 Home, Config, Settings 경로를 기준으로 설명합니다. 다른 플랫폼에서는 해당 설정 항목을 확인하고, 화면 위치만으로 연결 성공 여부를 판단하지 마세요. 아래 단계는 사용자가 이미 자신의 서비스와 구독을 보유한 경우를 전제로 합니다.

현재 상태 기록

접속에 실패한 주소, 발생 시각, 사용 중인 Wi-Fi 또는 셀룰러 네트워크, 브라우저에 표시된 오류를 기록하세요. 구독 새로 고침, DNS 교체, 규칙 수정은 한꺼번에 하지 마세요. 그래야 어떤 변경이 효과를 냈는지 확인할 수 있습니다.
자동 연결 일시 중지

Settings → On Demand로 이동해 기존 설정을 기록하고 자동 연결을 일시적으로 끈 다음 Home으로 돌아가 연결을 끄세요. 기본 네트워크를 확인하는 동안 조건에 따라 연결이 자동으로 켜지는 상황을 방지할 수 있습니다.
기본 네트워크 확인

연결을 끈 상태에서 평소 바로 열리는 웹사이트에 접속하세요. 여기서도 실패한다면 먼저 Wi-Fi 로그인 페이지, 라우터 또는 셀룰러 데이터 문제를 해결하세요. 공용 네트워크에서는 먼저 네트워크 인증을 완료해야 합니다.
조건별 비교

연결을 다시 켠 뒤 원래 접속에 실패한 웹사이트와 접속 가능한 것으로 확인된 다른 웹사이트를 각각 테스트하세요. 한 도메인만 실패한다면 클라이언트를 바로 재설치하지 말고 해당 도메인의 규칙, DNS 해석, 웹사이트 상태부터 확인하세요.

셀룰러 네트워크로 바꾸자 접속이 복구되고, 같은 설정에서 Wi-Fi만 계속 실패한다면 네트워크 경로와 관련된 단서입니다. 이것만으로 프로토콜 매개변수가 올바르다고 단정할 수는 없습니다. 이후에도 같은 서버와 같은 대상 주소를 사용해 비교하고, 두 변수를 동시에 바꾸지 마세요.

2. 서버 확인: Connectivity Test 통과가 웹 접속을 보장하지는 않습니다

Home에서 실제로 선택된 서버를 확인한 다음 Connectivity Test를 실행하세요. 서버가 목록에 보인다고 기본 서버로 선택된 것은 아닙니다. 구독을 업데이트한 뒤에도 선택 상태를 다시 확인해야 합니다. 테스트 시간이 초과되면 라우팅 규칙을 바로 조정하기보다 서버 주소, 포트, 인증 정보를 먼저 점검하세요. 테스트 응답은 해당 테스트 경로를 사용할 수 있다는 뜻일 뿐, 모든 웹사이트나 전송 방식이 정상이라는 보장은 아닙니다.

주소와 포트: 서버 편집 화면에서 보유한 연결 정보와 Address, Port를 대조하세요. 서버 포트는 서버 측 설정에 따라 결정됩니다. 웹사이트가 HTTPS를 사용한다는 이유만으로 포트를 일괄적으로 443으로 바꾸면 안 됩니다.
인증 정보와 프로토콜: Shadowsocks의 암호화 방식과 비밀번호, VMess / VLESS의 UUID, Trojan 비밀번호는 서버 설정과 일치해야 합니다. Type만 바꾸고 다른 프로토콜의 매개변수를 그대로 두지 마세요.
TLS와 전송 방식: TLS가 필요한 연결이라면 서버 이름과 관련 전송 설정을 확인하세요. 이름 불일치나 기기 시간 오류를 감추기 위해 인증서 검증을 끄지 마세요.
구독 변경: 서비스 제공자가 주소나 인증 정보를 변경했다면 구독을 업데이트한 뒤 서버를 다시 선택하세요. 가져오기에 성공했다는 것은 설정을 읽었다는 뜻이지, 원격 서버가 연결을 제공 중이라는 뜻은 아닙니다.

오류: `connection refused`

원인: 대상 연결이 명시적으로 거부되었습니다. 포트가 열려 있지 않거나 네트워크 장비가 연결을 차단한 경우가 많습니다. 해결 방법: 서버 측 정보와 Address, Port를 대조한 뒤 자신의 서비스 제공자에게 서버가 작동 중인지 확인하세요. DNS를 반복해서 바꿔도 포트 거부는 보통 해결되지 않습니다.

오류: `i/o timeout`

원인: 정해진 시간 안에 작업이 완료되지 않았습니다. 연결, 핸드셰이크 또는 데이터 수신 단계에서 발생할 수 있습니다. 해결 방법: 오류 주변에 기록된 대상 주소와 단계를 확인하고 다른 네트워크에서 다시 테스트하세요. timeout만으로 DNS 문제라고 단정하지 마세요.

3. Global Routing 확인: Proxy와 Config 비교하기

Home → Global Routing에서 현재 선택된 옵션을 확인하세요. Direct는 일반 대상 요청을 직접 연결합니다. 프록시로 접속해야 하는 대상이 이 설정에서 실패하더라도 서버에 문제가 있다는 뜻은 아닙니다. Config는 현재 설정에 따라 트래픽을 분기합니다. Proxy는 프록시 경로를 임시로 확인할 때 사용할 수 있습니다. Scene은 선택한 Scene의 구체적인 설정을 함께 확인해야 하며, 이름만 보고 실제 트래픽 경로를 단정할 수 없습니다.

옵션	문제 해결 시 활용	다음 단계
Proxy	일반 대상 요청을 임시로 프록시를 통해 연결해 라우팅 규칙의 영향을 줄입니다.	같은 실패 주소로 다시 테스트합니다. 계속 실패하면 서버와 DNS 해석을 확인합니다.
Direct	대상에 직접 연결할 수 있는지 확인합니다.	직접 연결 실패를 프록시 서버의 문제로 판단하지 마세요.
Config	현재 설정의 규칙에 따라 연결 방식을 결정합니다.	이 옵션에서만 실패한다면 규칙 적용 여부와 정책 대상을 집중적으로 확인하세요.
Scene	선택된 Scene의 설정을 사용합니다.	현재 Scene의 설정 내용을 확인하고, 문제 해결 중에는 동작이 분명한 비교 옵션으로 전환하세요.

결론: Proxy는 되지만 Config에서 실패하면 규칙부터 확인

같은 서버와 네트워크를 유지한 채 Global Routing을 Proxy에서 Config로 바꿔 다시 테스트하세요. 옵션을 바꿀 때마다 문제가 재현된다면 대상 도메인에 적용된 정책부터 확인하세요. 구독 전체를 바로 다시 가져오지 마세요. 설정 경로에 따라 DNS 결과도 달라질 수 있으므로 해석 결과도 확인해야 합니다.

4. DNS 확인: 도메인 해석 실패와 연결 실패 구분하기

DNS는 도메인을 IP 주소로 변환합니다. 브라우저에서 서버를 찾을 수 없다는 메시지가 표시되면 DNS 문제를 의심할 수 있지만, 로그로 실제 상황을 확인해야 합니다. 주소가 반환됐는지, IPv4와 IPv6 중 어떤 주소였는지, 이후 연결이 시작됐는지를 살펴보세요. 웹사이트 IP를 직접 입력하는 방식만으로 판단하지 마세요. HTTPS 인증서와 가상 호스트는 대개 도메인에 의존하므로, IP를 입력한 뒤 오류가 발생해도 DNS가 정상인지 비정상인지 알 수 없습니다.

기존 DNS는 일반적으로 서버 포트를 사용하며, 보통 UDP로 통신하고 TCP도 사용할 수 있습니다.

A / AAAA

각각 IPv4와 IPv6 주소 레코드에 해당하며, 두 경로의 동작이 다를 수 있습니다.

항목

한 번에 DNS 관련 설정 하나만 변경하고 같은 도메인으로 다시 테스트하세요.

Config로 이동해 현재 활성화된 설정을 열고 [General]의 dns-server를 확인하세요. 같은 도메인에 영향을 주는 [Host] 매핑이 있는지도 살펴보세요. 활성화되지 않은 설정을 수정해도 테스트 결과에는 반영되지 않습니다.
사용자 지정 DNS를 사용하는 경우 현재 네트워크에서 해당 DNS 서버에 접속할 수 있는지 먼저 확인하세요. 접속할 수 없는 다른 주소로 DNS를 바꿔도 결과가 나아지지 않습니다. 프록시 서버와 DNS를 동시에 변경하지 마세요.
암호화 DNS를 사용하는 설정이라면 호스트 이름, 인증서, 접속 경로를 확인하세요. DNS 서비스 자체에 연결할 수 없는 경우 특정 도메인 하나가 아니라 여러 웹사이트에서 동시에 문제가 발생할 수 있습니다.
변경 후 저장하고 연결을 다시 설정한 다음, 이전에 실패했던 페이지를 닫고 새로 여세요. 브라우저, 시스템, 클라이언트가 모두 캐시를 보관할 수 있으므로 기존 탭에 표시된 오류 문구만으로 판단하지 마세요.

로그에서 대상 IP를 확인했고 이후 연결 시간이 초과됐다면 DNS를 계속 무작정 바꾸지 말고 해당 주소의 네트워크 경로, IPv6 연결 가능 여부, 최종 정책을 확인하세요. IPv6 경로가 의심되면 AAAA 결과와 연결 주소를 기록하고 임시로 비교 테스트를 진행하세요. 테스트가 끝나면 원래 설정으로 복구하고, IPv6 전체 비활성화를 일반적인 해결 방법으로 취급하지 마세요.

5. 규칙 순서 확인: 가장 먼저 적용된 정책 찾기

Config에서 실제로 활성화된 설정을 확인하세요. 파일 이름만 봐서는 안 됩니다. 일반적인 라우팅 규칙은 위에서부터 순서대로 적용되며, 앞선 규칙이 먼저 일치하면 해당 정책이 결정됩니다. 뒤쪽에 올바른 규칙이 있어도 적용되지 않을 수 있습니다. 특히 범위가 넓은 DOMAIN-SUFFIX, 대상 주소를 포함하는 IP-CIDR, 마지막에 배치된 기본 규칙 FINAL을 확인하세요.

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

이 예시는 규칙 구조를 이해하기 위한 것으로, 기존 설정을 이 내용으로 덮어쓸 필요는 없습니다. example.com은 예시 도메인이며 PROXY와 DIRECT는 정책 이름입니다. 실제 설정에서 사용자 지정 정책 그룹을 사용한다면 그룹에 사용 가능한 서버가 포함되어 있고 현재 선택된 항목이 비활성 상태가 아닌지 확인하세요.

DOMAIN-SUFFIX: DOMAIN-SUFFIX,example.com,PROXY는 해당 도메인과 하위 도메인에 적용됩니다. 별도로 처리해야 하는 특정 대상은 먼저 일치할 수 있는 범위가 넓은 규칙보다 앞에 배치하세요.
IP-CIDR: IP 주소 대역을 기준으로 적용됩니다. 예시의 no-resolve는 이 IP 규칙을 적용하기 위해 도메인을 별도로 해석하지 않는다는 뜻입니다. 연결 과정 전체에서 DNS가 전혀 필요하지 않다는 의미는 아닙니다.
GEOIP: 대상 IP의 지리적 위치 데이터에 따라 적용됩니다. 웹사이트의 표시 언어나 도메인 접미사로 위치를 판단하지 않습니다. DNS 해석 결과가 바뀌면 규칙 적용 결과도 달라질 수 있습니다.
FINAL: 앞선 규칙에 일치하지 않은 요청을 처리하며, 보통 맨 마지막에 둡니다. 기본 정책이 DIRECT라면 프록시가 필요한 미분류 대상이 직접 연결을 시도하다 실패할 수 있습니다.

다시 테스트할 때는 같은 도메인에 적용된 규칙과 최종 정책을 확인하세요. 페이지는 이미지, API, 로그인 도메인도 요청할 수 있습니다. 기본 페이지는 열리지만 로그인이 실패한다면 홈페이지 도메인에만 규칙을 추가하지 말고 실패한 하위 요청을 확인하세요. 점검이 끝나면 Config로 복원하고 진단용 임시 규칙은 삭제하세요.

6. 자주 묻는 질문: 구독 업데이트, 자동 연결, 일부 기능 실패

구독 업데이트에 성공했는데도 연결되지 않는 이유는 무엇인가요?

업데이트 성공은 구독 내용을 가져왔다는 뜻일 뿐입니다. Home에서 기본 서버를 다시 확인하고 Connectivity Test를 실행하세요. 이어서 서비스 제공자의 자료와 계정 상태 및 연결 매개변수를 대조하세요. 업데이트 전 항목이 작동했다고 해서 업데이트 후 항목도 자동으로 작동한다고 볼 수는 없습니다.

스위치를 껐는데 왜 다시 자동 연결되나요?

Settings → On Demand로 이동해 현재 네트워크에 맞는 연결 조건이 활성화되어 있는지 확인하세요. 문제를 해결하는 동안에는 기존 설정을 기록한 뒤 일시적으로 끄고, 기본 네트워크 비교를 마친 후 복원하세요. 자동 재연결로 테스트 결과가 달라지는 상황을 방지할 수 있습니다.

웹페이지는 열리지만 동영상이나 통화가 실패하면 어떻게 해야 하나요?

먼저 실패한 기능이 다른 도메인이나 UDP를 사용하는지 확인한 뒤 해당 요청에 적용된 정책과 서버 측 지원 여부를 살펴보세요. 웹페이지의 TCP 연결이 성공했다고 UDP도 사용할 수 있는 것은 아닙니다. Hysteria2와 WireGuard는 UDP 경로에 의존하므로 네트워크 제한 여부를 특히 확인해야 합니다.

모든 설정을 바꿔 봐도 실패하면 재설치해야 하나요?

먼저 저장해 둔 설정 사본을 복원한 뒤 서버, Global Routing, DNS, 규칙 순서로 다시 테스트하세요. 실패 시각, 네트워크 유형, 대상 도메인, 민감 정보를 가린 로그를 보관해 자신의 서비스 제공자에게 원격 서버 상태를 확인해 달라고 요청하세요. 재설치로는 원격 서버의 미개방 포트나 만료된 인증 정보를 해결할 수 없습니다.

7. 평소 설정으로 복원하고 재현 가능한 결과 기록하기

문제가 해결되면 어떤 변경이 효과가 있었는지 확인한 뒤 임시 변경 사항을 복원하세요. Proxy로 전환한 뒤에만 접속된다면 문제가 해결됐다고 결론 내리지 말고 Config로 돌아가 필요한 라우팅 규칙이 작동하는지 확인해야 합니다. 네트워크를 바꾼 뒤 복구됐다면 원래 네트워크에서 발생한 문제 범위를 기록해 네트워크 제한을 설정 손상으로 오해하지 않도록 하세요.

평소 사용하는 Global Routing 옵션으로 복원하고 현재 활성화된 Config와 기본 서버를 확인하세요.
기록해 둔 설정대로 Settings → On Demand를 복원하고 네트워크 전환 후 예상대로 연결되는지 확인하세요.
직접 연결이 필요한 대상 하나, 프록시가 필요한 대상 하나, 원래 실패했던 기능을 각각 테스트하세요.
수정 후 설정 사본을 저장하고 변경 항목과 비교 결과를 기록하세요. 인증 정보가 포함된 로그를 공개적으로 저장하거나 공유하지 마세요.

클라이언트를 다시 다운로드해야 한다면 다운로드 페이지에서 해당 플랫폼을 선택하세요. iPhone / iPad 앱의 개발자는 Shadow Launch Technology Limited이며, 시스템 요구 사항은 App Store 페이지에 표시된 내용을 기준으로 합니다. 클라이언트 구매 비용과 사용자가 별도로 이용하는 네트워크 서비스는 별개이며, 클라이언트를 구매해도 네트워크 서비스 요금이 포함되는 것은 아닙니다.