Shadowrocket 연결됨으로 표시되지만 인터넷이 안 될 때: 서버·모드·DNS·규칙 점검

핵심 내용

Shadowrocket의 연결 스위치는 기기에서 터널이 시작되었음을 나타낼 뿐, 목적지 웹사이트에 접속할 수 있다는 뜻은 아닙니다. 자신의 서버 설정을 가져온 사용자를 대상으로 서버, Global Routing, DNS, 규칙 순서로 비교 테스트해 로컬 네트워크, 원격 연결, 도메인 확인, 트래픽 분기 문제를 구분합니다. 한 번에 한 항목만 변경하고 테스트가 끝나면 원래 설정으로 되돌리세요.

시작하기 전: 테스트 조건을 고정하고 로컬 네트워크 확인

먼저 Home에서 선택된 서버와 Global Routing 상태를, Config에서 사용 중인 설정을 기록하세요. 점검하는 동안 같은 기기와 네트워크, 같은 도메인을 사용해야 합니다. Wi-Fi, 서버, 설정을 동시에 바꾸면 결과에 영향을 준 항목을 알 수 없습니다. 이 안내는 사용자가 자신의 서비스 제공업체와 구독을 이미 보유한 경우를 전제로 하며, 이 사이트는 노드나 구독을 제공·판매·추천하지 않습니다.

Shadowrocket 연결 스위치를 끈 뒤 평소 직접 접속되는 웹사이트를 열어 보세요. 그래도 접속할 수 없다면 Wi-Fi에서 웹 로그인이 필요한지, 셀룰러 데이터가 작동하는지, 기기가 제한된 네트워크에 연결되어 있는지 먼저 확인하세요. 이때 프록시 규칙을 바꾸는 것은 문제 해결에 도움이 되지 않습니다. 기본 네트워크 연결을 복구한 다음 스위치를 켜고 다시 테스트하세요.

기존 상태 기록

Home에서 선택된 서버와 Global Routing을 기록하고, Config에서 현재 설정 이름을 확인하세요. 수정 전에 설정 사본을 보관하고, 원본 파일과 구독 자격 증명은 자신의 기기에만 저장하세요.
자동 연결 확인

Settings → On Demand를 열어 현재 설정을 기록하세요. 스위치를 끈 뒤에도 연결이 자동으로 다시 설정된다면, 비교 테스트를 하는 동안 On Demand를 잠시 꺼 자동 연결이 결과에 영향을 주지 않도록 하세요.
기본 네트워크 연결 확인

연결 스위치를 끄고 직접 접속이 확인된 웹사이트를 테스트하세요. 네트워크 인증이 필요하다면 먼저 네트워크에서 제공하는 로그인 절차를 완료하세요. 인증이 끝나지 않은 상태를 서버 오류로 오인하지 마세요.
재테스트 대상 고정

직접 접속이 정상인 도메인 하나와 문제가 발생하는 도메인 하나를 정하고, 스위치를 끈 상태와 켠 상태에서 각각 어떻게 표시되는지 기록하세요. 이후 설정을 하나 변경할 때마다 두 곳을 다시 방문하세요.

첫 번째: Home에서 선택한 서버가 요청을 처리할 수 있는지 확인

Home으로 돌아가 테스트하려는 서버가 선택되어 있는지 확인하세요. 이름이 비슷한 이전 항목을 선택하지 않도록 주의합니다. 해당 항목의 편집 화면에서 서버 주소, 포트, 프로토콜, 인증 정보를 확인하세요. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 입력 항목이 서로 다릅니다. 자신의 서비스 제공업체가 안내한 값을 하나씩 대조하고, Type만 바꾼 채 나머지 값을 그대로 두지 마세요.

Home에서 Connectivity Test를 실행할 때는 ‘지연 시간이 표시됨’과 ‘웹 요청이 성공함’을 구분해야 합니다. 테스트 방식마다 확인하는 단계가 다릅니다. TCP 연결 성공은 해당 포트에 접근할 수 있다는 뜻일 뿐, 인증, TLS 핸드셰이크, UDP 통신 또는 대상 웹사이트 접속까지 정상임을 증명하지 않습니다. 이후 단계까지 확인하려면 브라우저에서 실제 요청을 보내세요.

주소와 포트: 서버 도메인 또는 IP 주소와 서비스 포트가 원래 제공된 정보와 일치하는지 확인하세요. 443은 흔히 사용하는 HTTPS 포트일 뿐, 모든 서비스가 이 포트를 사용하는 것은 아니며 입력한다고 연결되는 것도 아닙니다.
인증과 전송: 비밀번호, UUID, TLS Server Name 등의 항목은 해당 프로토콜에서 사용하는 경우에만 확인하세요. 오류를 없애려고 인증서 검증을 임의로 끄지 말고, 먼저 서버 이름과 기기 시간, 서버 인증서를 확인하세요.
기존 구독: 자신의 구독에서 가져온 설정이라면 Home에서 해당 구독을 업데이트한 뒤 갱신된 항목을 다시 선택하세요. 업데이트 성공은 목록을 가져왔다는 뜻일 뿐, 목록에 있는 모든 서버로 대상 웹사이트에 접속할 수 있다는 의미는 아닙니다.
네트워크 차이: 같은 항목이 셀룰러 데이터에서는 작동하지만 Wi-Fi에서는 실패한다면 해당 Wi-Fi의 포트 또는 UDP 제한을 먼저 확인하세요. 네트워크 전환은 비교 테스트에만 사용하고, 프로토콜과 DNS를 동시에 바꾸지 마세요.

아래는 네트워크 로그에 나타날 수 있는 일반적인 오류 문자열입니다. 모든 프로토콜에서 같은 문구가 표시되는 것은 아닙니다. 전체 맥락을 보고 문제가 발생한 대상을 판단하세요. 오류에 나온 주소가 서버인지, DNS 확인 서버인지, 대상 웹사이트인지 확인해야 합니다.

오류: connection refused

원인: 해당 연결이 거부 응답을 받았습니다. 대상 포트에서 서비스가 실행되고 있지 않거나 연결이 명시적으로 거부된 경우에 흔히 발생합니다.

해결: 먼저 로그의 주소와 포트를 확인하세요. 자신의 서버가 대상이라면 서비스 상태와 올바른 포트를 서비스 제공업체에 문의하세요.

오류: i/o timeout

원인: 읽기 또는 쓰기 단계가 제한 시간 안에 완료되지 않았습니다. 패킷 손실, 접근할 수 없는 포트, 원격 서버의 무응답 등이 원인일 수 있습니다.

해결: 항목 설정은 그대로 두고 작동하는 다른 네트워크에서 다시 테스트하세요. 그런 다음 오류가 발생한 단계를 기준으로 서버 연결 또는 DNS 요청을 확인하세요.

오류: no such host

원인: 해당 호스트 이름을 유효한 주소로 확인하지 못했습니다. 문제가 된 이름은 서버 도메인일 수도, 대상 웹사이트 도메인일 수도 있습니다.

해결: 먼저 도메인 철자와 유효성을 확인한 뒤 DNS 문제를 점검하세요. 서버 도메인 자체를 확인할 수 없다면 프록시 정책만 바꿔서는 해결되지 않습니다.

두 번째: Global Routing으로 프록시 연결과 설정 문제 구분

Home → Global Routing에서 현재 선택 항목을 확인하세요. Proxy는 프록시 경로로 보낼 수 있는 요청을 전달하고, Direct는 직접 연결 경로를 사용합니다. Config는 현재 설정에 따라 처리하며, Scene은 장면 설정에 따라 실제 동작을 결정합니다. Scene이 항상 Proxy 또는 Config를 뜻하는 것은 아니므로, 점검할 때는 현재 장면에서 사용하는 설정을 확인해야 합니다.

같은 서버와 네트워크를 유지한 채 Proxy를 잠시 선택해 문제가 발생한 도메인을 다시 열어 보세요. 그런 다음 Config로 전환해 재시도합니다. Proxy에서는 접속되지만 Config에서는 되지 않는다면 서버 전체의 문제가 아니라 규칙, 정책 대상 또는 설정의 다른 처리 항목에 문제가 있을 가능성이 큽니다. 테스트가 끝나면 원래 모드로 되돌려 임시 비교 설정을 영구 해결책으로 사용하지 않도록 하세요.

모드	점검 목적	결과 해석
Proxy	선택된 프록시 경로 테스트	접속되면 현재 조건에서 해당 요청이 프록시를 통해 처리된다는 뜻입니다. 모든 도메인이 작동한다는 의미는 아닙니다.
Direct	직접 연결 기준 확인	직접 접속이 확인된 웹사이트만 테스트하세요. 대상이 현재 환경에서 직접 연결을 지원하지 않는다면, 실패만으로 원인을 특정할 수 없습니다.
Config	현재 설정 확인	Proxy 결과와 다르다면 규칙 적용, 정책 대상, DNS 등 설정 차이를 추가로 확인하세요.
Scene	장면 선택 확인	먼저 현재 장면의 실제 설정을 확인한 다음 고정 모드와 비교하세요. 장면 변경으로 변수가 더해지는 것을 방지할 수 있습니다.

결론: Proxy가 정상이라면 규칙을 확인하세요

같은 대상이 Proxy에서는 정상이고 Config에서는 실패한다면, 작동하는 서버는 그대로 두고 현재 설정과 적용된 정책을 확인하세요. 이미 유효한 비교 조건을 잃지 않도록 서버 항목을 동시에 다시 만들지 마세요.

세 번째: 서버 도메인 확인과 웹사이트 도메인 확인 구분

DNS는 최소 두 곳에서 사용될 수 있습니다. 먼저 서버 도메인을 주소로 확인하고, 이후 접속할 대상의 주소를 확인합니다. 첫 단계가 실패하면 서버 연결이 차단되고, 두 번째 단계가 실패하면 연결은 되었지만 웹페이지가 로드되지 않을 수 있습니다. 로그를 확인할 때는 DNS라는 단어만 보고 모든 확인 설정을 바꾸지 말고, 오류가 발생한 전체 도메인을 먼저 찾으세요.

Config에서 현재 설정을 열고 [General]의 dns-server를 확인하세요. 대상 도메인에 영향을 주는 [Host] 매핑이 있는지도 살펴보세요. 오래된 내부 DNS, 접근할 수 없는 확인 서버, 만료된 주소로 연결하는 도메인 매핑 등이 결과에 영향을 줄 수 있습니다. DNS 설정이 여러 곳에 있다면 현재 적용 중인 설정을 확인해 사용하지 않는 파일을 수정하지 않도록 하세요.

2곳

서버 도메인과 대상 도메인의 확인 결과를 각각 점검

일반 DNS는 UDP 또는 TCP 포트를 사용합니다

443

DoH는 대개 HTTPS 포트를 사용하며, 모든 DNS에 적용되는 포트는 아닙니다

먼저 오류에 나온 도메인의 철자가 올바른지 확인하고, 만료된 서버 도메인이나 잘못된 웹 주소가 문제의 원인이 아닌지 살펴보세요.
설정 사본을 보관한 뒤 dns-server = system을 임시로 사용해 시스템 DNS 결과와 비교할 수 있습니다. 이는 모든 상황에 권장되는 값이 아니며 시스템 DNS도 현재 네트워크의 영향을 받을 수 있습니다.
[Host]에 문제가 있는 도메인의 이전 주소가 등록되어 있는지 확인하세요. 문제가 있다고 확인된 매핑만 되돌리고, 다른 용도의 기록까지 전부 삭제하지 마세요.
저장한 뒤 해당 설정이 선택되어 있는지 확인하고 연결을 다시 설정하세요. 같은 도메인에 다시 접속한 후 변경 전과 달라진 점을 기록하세요.

네 번째: Config에서 규칙 순서와 실제 정책 확인

Proxy는 작동하지만 Config에서 실패한다면 Config에서 선택된 파일을 확인한 뒤 [Rule]을 살펴보세요. 규칙은 일반적으로 위에서 아래로 확인하며, 일치하는 규칙이 있으면 해당 정책을 적용합니다. 앞쪽의 포괄적인 규칙이 뒤쪽의 구체적인 규칙보다 먼저 적용될 수 있습니다. 사용하지 않는 파일을 수정해도 현재 연결에 적용되는 규칙은 바뀌지 않습니다.

DOMAIN-SUFFIX는 지정된 도메인과 하위 도메인을 일치시킵니다. IP-CIDR은 IP 주소 대역을, GEOIP는 IP 위치 데이터베이스에 따른 분류를 대상으로 합니다. FINAL은 앞선 규칙과 일치하지 않은 요청을 처리합니다. 도메인 규칙과 IP 규칙은 서로 다른 대상을 기준으로 합니다. IP 분류를 사용하는 경우에는 주소가 이미 확인되었는지도 고려해야 하므로, 규칙 순서를 DNS와 무관한 단계로 볼 수는 없습니다.

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

아래 설정은 문법을 설명하기 위한 예시입니다. example.com은 예시 도메인이고 192.0.2.0/24는 문서용 예시 네트워크 대역입니다. 실제 서비스 접속 여부를 확인하는 데 사용하거나 자신의 운영 설정 전체를 이 내용으로 덮어쓰지 마세요. no-resolve는 해당 IP 규칙에서 확인 절차를 능동적으로 시작하지 않는다는 뜻입니다. 전역 DNS를 끄는 스위치가 아닙니다.

DIRECT와 일치: 요청이 직접 연결 경로를 사용합니다. 현재 네트워크에서 대상에 직접 접속할 수 없다면 지나치게 넓은 도메인 규칙이나 주소 규칙이 먼저 적용되지 않았는지 확인하세요.
REJECT와 일치: 규칙이 요청을 거부했습니다. 구체적인 규칙과 용도를 찾아 오작동이 확인된 경우에만 정확히 조정하세요. 모든 거부 규칙을 한꺼번에 삭제하지 마세요.
PROXY와 일치: 현재 사용 중인 프록시 대상을 추가로 확인하세요. 규칙이 사용자 지정 정책 그룹을 가리킨다면 해당 그룹에서 실제로 선택된 구성원도 확인해야 합니다. Home의 선택 표시만으로는 충분하지 않습니다.
FINAL로 처리: 앞선 규칙 중 일치하는 항목이 없었다는 뜻입니다. 마지막 정책이 예상한 동작인지 확인하고, 꼭 필요한 구체적인 규칙은 이를 덮어쓸 수 있는 포괄적인 규칙보다 앞에 두세요.

다시 테스트할 때 Shadowrocket의 요청 기록 또는 로그에서 같은 대상 도메인을 찾아 적용된 규칙과 최종 정책을 확인하세요. 하나의 웹페이지에서 이미지, 스크립트, 로그인 API를 추가로 요청할 수 있습니다. 기본 도메인은 열리지만 페이지가 비어 있다면 기본 도메인에 규칙을 반복해서 추가하지 말고 실패한 리소스 도메인을 확인하세요.

자주 묻는 질문: 증상에 따라 다음 단계 선택

지연 시간이 표시되는데 브라우저에서 열리지 않는 이유는 무엇인가요?

먼저 Connectivity Test에서 사용한 테스트 방식을 확인하고 실제 웹페이지 요청으로 검증하세요. 포트 연결만 되고 인증이 실패해도 이런 현상이 나타날 수 있습니다. Home에서 프로토콜과 인증 매개변수를 확인하고 연결, 핸드셰이크, 요청 중 어느 단계에서 실패하는지 살펴보세요.

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

서버와 Global Routing은 그대로 두고 Wi-Fi의 기본 연결 상태와 인증 페이지를 먼저 확인한 다음 DNS와 포트 접근성을 비교하세요. 서비스가 UDP에 의존한다면 해당 네트워크에서 UDP를 제한하는지도 확인하세요. 네트워크 차이만으로 계정이 만료되었다고 판단하지 마세요.

웹사이트 하나만 열리지 않는데 모든 설정을 초기화해야 하나요?

먼저 Proxy와 Config를 비교한 뒤 해당 도메인의 확인 결과와 적용된 정책을 살펴보세요. 다른 웹사이트가 정상이라면 연결 경로의 적어도 일부는 작동하고 있다는 뜻입니다. 두 모드 모두 같은 대상에서만 실패한다면 대상 사이트의 응답과 접속 제한도 고려해야 합니다.

설정을 바꿨는데 달라진 점이 없다면 어디를 확인해야 하나요?

Config에서 수정한 파일이 실제로 선택되어 있는지 확인하고, Home으로 돌아가 Global Routing이 Config인지 확인한 뒤 연결을 다시 설정해 테스트하세요. Scene을 사용 중이라면 먼저 해당 장면의 실제 설정을 확인하세요. 테스트가 끝나면 Settings → On Demand를 원래대로 복원하세요.

문제를 찾지 못했다면 발생 시간, 네트워크 종류, 프로토콜 이름, Global Routing 상태, 실패한 도메인, 민감 정보를 가린 오류 일부를 정리해 자신의 서비스 제공업체에 문의하세요. 구독 링크 전체, 비밀번호, UUID, 개인 키, 접근 토큰이 포함된 스크린샷을 공개하지 마세요. 이런 정보는 문제 확인에 필요한 증상 기록과 분리해 보관해야 합니다.