Shadowrocket 인터넷 연결 안 됨 해결: 서버, Global Routing, DNS 및 규칙 점검

이 글 미리보기

Shadowrocket의 연결 스위치는 기기의 로컬 터널 상태를 나타내며, 원격 서버와 도메인 조회, 대상 웹사이트까지 모두 연결되었음을 의미하지 않습니다. 본인 서버와 구독이 이미 있는 경우를 전제로, 로컬 네트워크, 서버 매개변수, Global Routing, DNS, 규칙 순서로 문제를 확인합니다. 한 번에 한 항목만 변경하고 같은 대상으로 다시 요청해 우연히 복구된 것을 해결로 오인하지 않도록 하세요.

1. 터널 연결과 웹페이지 접속 구분하기

iPhone 또는 iPad에 VPN 표시가 나타나면 시스템에 로컬 네트워크 터널이 설정된 것입니다. 웹페이지에 접속하려면 도메인 조회, 정책 선택, 원격 연결, 대상 서버 응답 과정도 거쳐야 합니다. 이 중 어느 단계에서든 실패하면 연결 스위치가 켜져 있어도 페이지가 계속 로딩될 수 있습니다. 스위치를 반복해서 껐다 켜는 것만으로는 어느 단계에서 문제가 생겼는지 알 수 없습니다.

앱 요청 시스템 터널 도메인 조회 및 트래픽 분기 외부 연결 대상 서버 응답

모든 앱에서 실패하는지, 모든 웹페이지에서 실패하는지, 특정 도메인에서만 실패하는지 먼저 기록하세요. 실패 당시 Wi-Fi를 사용했는지 셀룰러 네트워크를 사용했는지도 함께 적어 두세요. 브라우저에서 한 페이지가 열렸다는 사실은 해당 요청이 완료되었다는 뜻일 뿐, 다른 프로토콜이나 대상에도 접속할 수 있다는 의미는 아닙니다. 아래 비교 테스트에는 평소 사용하는 동일한 테스트 페이지를 이용하면 되며, 여러 웹사이트를 연이어 방문할 필요는 없습니다.

현재 상태 기록하기

Home에서 선택된 서버, 현재 Global Routing 값, 오류 발생 시각을 기록하세요. Config에서는 현재 활성화된 구성의 이름을 확인하고, 변경 전에는 사본을 만들어 원본을 덮어쓰지 마세요.
로컬 네트워크 테스트하기

Settings → On Demand에서 기존 상태를 기록한 뒤 자동 연결을 잠시 끄고, Home의 연결 스위치도 끄세요. 프록시 없이도 접속할 수 있어야 하는 페이지를 열어 보세요. 여전히 접속되지 않는다면 Wi-Fi 로그인, 신호 세기 또는 로컬 네트워크 문제부터 해결하세요.
네트워크 변경해 보기

Wi-Fi와 셀룰러 네트워크에서 같은 페이지를 각각 테스트한 다음 Shadowrocket 연결을 다시 켜세요. 한쪽 네트워크에서만 실패한다면 서버와 구성을 변경하지 말고 해당 네트워크의 도메인 조회, 접속 제한, 연결 상태를 우선 확인하세요.
요청 다시 보내기

설정을 변경할 때마다 다시 연결한 뒤 새 페이지를 열어 요청을 보내세요. 기존 연결이나 페이지 캐시에는 이전 결과가 남을 수 있으므로, 이미 열려 있는 탭만 보고 새 설정이 적용되었는지 판단하지 마세요.

2. 서버 매개변수와 실제 외부 연결 확인하기

Home에서 현재 선택된 서버를 확인하고 해당 항목의 편집 화면을 열어 본인 서비스의 원래 매개변수와 주소, 포트, Type, 인증 정보를 대조하세요. 서버 목록에 항목이 있다고 해서 해당 서버가 아직 유효한 것은 아닙니다. 지연 시간 테스트에 응답이 있어도 웹페이지 접속에 필요한 전체 연결이 성공한다고 보장할 수 없습니다.

확인 항목	확인할 내용	판단 시 유의점
주소 및 포트	본인 서비스의 매개변수와 하나씩 대조하고, 주소가 만료되었거나 포트를 잘못 입력하지 않았는지 확인하세요.	원격 서버가 443 포트를 사용할 수도 있지만, 웹페이지가 열리지 않는다는 이유만으로 서버 포트를 무조건 443으로 바꾸면 안 됩니다.
Type 및 인증 정보	실제 서비스에 맞춰 Shadowsocks, VMess, VLESS, Trojan, Hysteria2 또는 WireGuard에 필요한 항목을 확인하세요.	프로토콜마다 암호, 식별자, 키 항목이 다르므로 서로 바꿔 쓸 수 없습니다.
TLS 및 전송 방식	서비스에서 TLS를 사용한다면 서버 이름과 인증서 요구 사항을 확인하고, 추가 전송 방식을 사용한다면 경로 등 관련 매개변수를 점검하세요.	서버 이름, 인증서 또는 기기 시간 문제를 해결하는 대신 인증서 검증을 끄지 마세요.
구독 상태	Home에서 본인의 Subscribe 항목을 업데이트한 뒤 현재 선택된 서버가 업데이트 후에도 유효한지 확인하세요.	업데이트에 성공했다는 것은 항목을 가져왔다는 의미일 뿐, 모든 원격 서버에 연결할 수 있다는 뜻은 아닙니다.

유효한 서버가 여러 개 있다면 Global Routing과 DNS를 변경하지 않고 서버만 바꿔 비교할 수 있습니다. 특정 항목만 실패한다면 해당 항목의 매개변수와 원격 서버 상태를 우선 확인하세요. 모든 항목이 실패한다면 로컬 네트워크와 공통으로 사용하는 도메인 조회 설정을 함께 살펴보세요. 이 글에서는 서버나 구독을 제공, 판매 또는 추천하지 않습니다.

3. Global Routing으로 문제 범위 좁히기

Home → Global Routing에서 현재 모드를 확인하세요. Proxy, Direct, Config, Scene은 각각 역할이 다르므로 문제를 확인할 때는 트래픽이 실제로 어떤 정책을 따르는지 먼저 파악해야 합니다. Proxy는 잠시 비교해 볼 수 있지만 모든 네트워크 문제를 해결하는 스위치는 아닙니다.

모드	확인할 점	비교 목적
Proxy	요청을 전역 프록시 모드로 처리하며, 사용할 서버 또는 정책도 확인합니다.	같은 대상이 Proxy에서는 열리고 Config에서는 실패한다면 규칙과 정책 참조를 중점적으로 확인하세요.
Direct	요청을 직접 연결 모드로 처리하며, 대상은 현재 로컬 네트워크에서 직접 접속할 수 있어야 합니다.	프록시 경로와 직접 연결 경로를 구분하는 데 도움이 되지만, 시스템 터널을 끄는 것과 같은 동작은 아닙니다.
Config	Config에서 현재 활성화된 구성의 트래픽 분기 규칙을 사용합니다.	Home에서 선택된 항목만 보지 말고 적용된 규칙, 정책 그룹, FINAL도 확인하세요.
Scene	직접 설정한 Scene 조건과 각 조건에 대응하는 동작을 확인하세요.	네트워크 환경에 따라 모드가 바뀐다면 Scene 전환부터 확인한 뒤 결과를 비교하세요.

비교할 때는 서버와 대상 도메인을 그대로 유지하세요. 먼저 현재 모드에서 문제가 재현되는지 확인한 뒤 Proxy로 잠시 전환해 다시 연결하고 테스트합니다. 테스트 후에는 원래 모드로 복구하세요. Proxy에서도 실패했다고 해서 DNS 문제를 배제할 수는 없습니다. Config에서는 실패하고 Proxy에서는 성공하더라도 이것만으로 FINAL의 오류라고 단정할 수 없습니다. 실제 적용된 정책이 다른 비가용 서버를 가리키는지도 확인해야 합니다.

Config에서만 실패: 현재 활성화된 구성, 대상에 적용된 규칙, 정책 그룹에서 실제로 선택된 항목을 확인하세요.
특정 Scene에서만 실패: 현재 네트워크 환경을 기록하고 Scene의 조건과 결과를 확인하세요. 네트워크를 바꾼 뒤 이전 환경에서 얻은 결론을 그대로 적용하지 않도록 주의하세요.
Proxy와 Config 모두 실패: 공통으로 사용하는 서버 매개변수, 도메인 조회 경로, 로컬 네트워크를 계속 확인하세요.

4. DNS 확인하기: 조회 성공이 연결 성공을 뜻하지는 않습니다

서버 주소가 도메인인 경우 해당 주소도 먼저 조회해야 합니다. 대상 웹사이트의 도메인 조회는 별도의 요청입니다. 따라서 “서버 지연 시간을 측정할 수 있음”과 “웹사이트 도메인을 조회할 수 있음”은 같은 의미가 아닙니다. DNS를 점검할 때는 서버 도메인과 대상 도메인 중 어느 쪽에서 실패했는지 구분한 뒤 해당 조회 경로를 확인하세요.

일반 DNS는 보통 UDP 또는 TCP의 이 포트를 사용합니다

443

DoH는 보통 HTTPS를 통해 이 포트를 사용합니다

1개 항목

DNS 설정은 매번 하나씩만 바꾸고 다시 테스트하세요

Config에서 현재 활성화된 구성을 열어 DNS 항목을 확인하세요. Settings → DNS의 관련 설정도 점검해 비활성화된 다른 구성의 값을 현재 설정으로 착각하지 않도록 하세요.
DNS 서버 주소, 사용 방식, 연결 가능 여부를 확인하세요. 암호화된 DNS도 네트워크 연결이 필요합니다. HTTPS 조회 주소를 입력했다고 해서 현재 경로에서 반드시 접속할 수 있는 것은 아닙니다.
이전에 DNS를 변경했다면 기존 값을 기록한 다음 본인이 사용 가능한 것으로 확인한 설정으로 잠시 되돌려 같은 대상으로 새 요청을 보내세요. 서버, DNS 서버, 규칙을 한꺼번에 바꾸지 마세요.
로그에 대상 IP를 받았다고 표시된 뒤 연결 시간이 초과된다면 외부 연결 경로와 대상 서비스를 확인하세요. 명확하게 도메인 조회 단계에서 멈췄다면 DNS 서버 연결과 도메인 자체를 점검하세요.

브라우저에 대상 IP를 직접 입력하는 방법만으로 확인하지 마세요. HTTPS 서비스는 도메인, TLS 서버 이름, 가상 호스트 설정에 의존하는 경우가 많아 IP로 직접 접속하면 인증서 오류가 발생하거나 다른 콘텐츠가 표시될 수 있습니다. IPv4와 IPv6의 연결 상태가 다를 수도 있으므로 로그에 표시된 주소 유형을 기준으로 원인을 찾으세요. 네트워크 문제를 가리기 위해 특정 주소 체계를 계속 꺼 두지 마세요.

5. 규칙 순서에 따라 FINAL과 정책 참조 확인하기

Global Routing이 Config일 때 실제로 활성화된 구성을 열고 규칙 순서를 확인하세요. 일반적인 트래픽 분기 규칙은 순서대로 적용되므로 앞쪽 규칙이 일치하면 뒤쪽 규칙은 적용되지 않을 수 있습니다. FINAL은 앞선 규칙에 일치하지 않은 요청을 처리하는 규칙이며, 앞선 모든 규칙을 대체하거나 서버 인증 실패를 해결하지는 않습니다.

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

아래 내용은 문법 설명용이며 그대로 교체해 사용할 수 있는 완성된 구성이 아닙니다. example.com은 예시 도메인입니다. PROXY는 현재 구성에서 유효한 프록시 정책 또는 정책 그룹을 가리켜야 합니다. 구성에서 이 이름이 다른 대상을 가리킨다면 실제 정의를 기준으로 확인하세요. 영어 이름만 보고 최종 연결 경로를 추측해서는 안 됩니다.

DOMAIN-SUFFIX: 대상 호스트 이름이 해당 접미사에 포함되는지 확인하세요. 한 페이지에서 여러 리소스 도메인을 요청할 수 있으므로 본문 페이지가 열렸다고 이미지, API, 로그인 요청도 같은 경로를 사용하는 것은 아닙니다.
IP-CIDR: IP 대역을 기준으로 일치 여부를 확인합니다. 예시의 no-resolve는 이 규칙에서 도메인 조회를 별도로 수행해 매칭하지 않는다는 뜻입니다. 요청에 이미 포함된 주소 정보를 고려해 결과를 해석하세요.
GEOIP: IP 지리 위치 데이터베이스를 기준으로 일치 여부를 확인합니다. 페이지에 표시된 문자, 도메인 접미사 또는 사용자 위치만으로 일치 여부를 판단할 수는 없습니다.
FINAL: 앞선 규칙에 일치하지 않은 요청을 처리합니다. 사용할 수 없는 정책 그룹을 가리키면 앞쪽 규칙에 일치하지 않은 페이지가 한꺼번에 실패할 수 있습니다.

변경 전에 구성을 복사해 두세요. 그런 다음 실패한 대상과 관련된 규칙 또는 정책 한 곳만 조정하고 다시 활성화해 연결을 테스트하세요. 복구되더라도 요청 기록에서 예상한 규칙이 실제로 적용되었는지 확인해야 합니다. 페이지가 우연히 열렸다는 이유로 모든 규칙을 교체하거나 Proxy를 영구적으로 사용하지 마세요.

6. 오류 기록에 따라 다시 테스트하고 설정 복구하기

앱의 연결 기록이나 로그에서 문제가 재현된 시각과 대상 도메인에 해당하는 요청을 찾아 조회 결과, 적용된 정책, 오류 정보를 확인하세요. 다음은 네트워크 로그에 나타날 수 있는 오류 문구입니다. 실제 기록에는 주소나 추가 문맥이 포함될 수 있습니다. 오류 문구는 실패 단계를 파악하는 데 도움이 되지만, 특정 설정 오류를 직접 증명하지는 않습니다.

오류: connection refused

원인 및 해결: 대상 포트에서 연결을 거부했거나 중간 장비가 연결을 차단했을 수 있습니다. 먼저 기록이 프록시 서버와 대상 사이트 중 어디를 가리키는지 확인한 다음 해당 주소와 포트, 서비스의 연결 대기 상태를 점검하세요.

오류: i/o timeout

원인 및 해결: 네트워크 작업이 제한 시간 안에 완료되지 않았다는 뜻이며, 이것만으로 암호 오류라고 판단할 수는 없습니다. 같은 기록에 표시된 연결 단계를 확인하고 네트워크, 서버, DNS 서버를 각각 점검한 뒤 다시 테스트하세요.

오류: no such host

원인 및 해결: 도메인 조회에서 사용할 수 있는 결과를 얻지 못한 상태입니다. 도메인 오타, DNS 레코드 상태 또는 조회 경로가 원인일 수 있습니다. 먼저 어느 도메인에서 실패했는지 확인하고 주소와 DNS 설정을 점검하세요. 관련 없는 규칙은 변경하지 마세요.

명확한 오류가 없다면 “네트워크, 서버, Global Routing, 대상 도메인, 발생 시각, 증상”을 한 줄로 기록하세요. 예를 들어 “Wi-Fi에서 Config로 연결하면 시간 초과, 서버를 그대로 두고 Proxy로 전환하면 같은 페이지가 열림”이라고 적으면 “연결됐지만 작동하지 않음”보다 문제를 파악하기 쉽습니다. 이는 기록 예시일 뿐, 이 글에서 실제 테스트한 결과가 아닙니다.

테스트 중 임시로 변경한 Global Routing, DNS, 구성을 복구하고 비교를 통해 필요한 것으로 확인된 변경만 유지하세요.
수동 연결이 안정적인 것을 확인한 다음 원래 설정에 따라 Settings → On Demand를 복구하고 네트워크를 전환했을 때의 동작을 확인하세요.
원래 직접 접속할 수 있었던 페이지와 이전에 실패한 페이지를 각각 테스트하고, 페이지에 포함된 API와 리소스도 정상적으로 작동하는지 확인하세요.
본인 서비스 제공자에게 문의할 때는 프로토콜, 포트, 시각, 개인정보를 가린 오류 기록을 전달하세요. 구독 전체 주소, 암호, 키, 계정 식별 정보는 숨기세요.