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

이 글의 핵심 내용

Shadowrocket의 연결 스위치를 켜면 기기에서 연결 절차가 시작되지만, 원격 서버와 도메인 조회, 각 요청에 적용되는 정책까지 모두 정상이라는 뜻은 아닙니다. 이미 이용 중인 서비스와 구독이 있다는 전제하에 기본 네트워크부터 확인하고, 서버·Global Routing·DNS·규칙 문제를 하나씩 분리해 점검합니다. 한 번에 하나만 변경하고 같은 웹페이지와 요청 기록으로 결과를 비교하세요.

먼저 기준 상태 확인: 연결을 끄면 인터넷이 되는가

구독을 삭제하거나 앱을 다시 설치하는 것부터 시작하지 마세요. 먼저 Shadowrocket 연결을 켰을 때만 문제가 발생하는지 확인합니다. 연결을 꺼도 현재 Wi-Fi 또는 셀룰러 네트워크에서 평소 직접 접속하던 웹페이지가 열리지 않는다면 기본 네트워크, Wi-Fi 로그인 인증 또는 시스템 네트워크 권한부터 해결해야 합니다. 연결 아이콘만으로는 이 단계를 대신할 수 없습니다.

현재 상태 기록

Home에서 선택된 서버, Global Routing 옵션, Config에서 사용 중인 구성을 기록하세요. 기존 구성은 사본으로 보관하고, 기록에 비밀번호나 전체 구독 링크, 인증 정보는 포함하지 마세요.
연결 끄기

Home에서 연결을 끈 다음 Safari로 평소 직접 접속하던 HTTPS 웹페이지를 엽니다. 여전히 열리지 않으면 Wi-Fi 로그인이 필요한지, 셀룰러 데이터가 작동하는지 먼저 확인한 후 앱 내 점검을 계속하세요.
테스트 대상 고정

직접 접속할 수 있는 웹페이지 하나와 원래 Proxy가 필요한 웹페이지 하나를 정하세요. 이후 URL은 바꾸지 말고, 매번 설정을 변경한 뒤 같은 요청을 다시 보내세요. 서로 다른 웹사이트의 결과를 비교하면 안 됩니다.
자동 연결 일시 중지

수동으로 연결을 끊어도 다시 자동으로 연결된다면 Settings → On Demand를 확인하고 기존 상태를 기록한 뒤 On Demand를 잠시 끄세요. 테스트를 마친 후에는 원래대로 복구해 자동 연결이 비교 결과에 영향을 주지 않도록 합니다.

테스트할 때는 ‘웹페이지가 열리지 않는 문제’와 ‘특정 앱의 일부 기능이 작동하지 않는 문제’를 구분하세요. 특정 사이트 자체의 장애일 수 있습니다. 웹페이지는 열리지만 동영상이나 통화가 실패한다면 해당 트래픽에 UDP가 사용되는지도 확인해야 하며, 이를 근거로 전체 연결이 작동하지 않는다고 단정할 수는 없습니다.

첫 번째 점검: 서버 연결 상태와 인증 정보

Home으로 돌아가 테스트할 서버가 선택되어 있는지 확인한 다음 Connectivity Test를 실행하세요. 먼저 계속 시간 초과가 발생하는지, 응답이 안정적인지 확인합니다. 테스트 성공은 테스트에 사용된 경로나 대상에 연결할 수 있다는 뜻일 뿐, 모든 웹사이트와 UDP 트래픽, 서버 인증이 정상이라는 보장은 아닙니다. 지연 시간이 짧아도 실제 웹페이지가 열린다고 단정할 수 없습니다.

443

HTTPS에서 흔히 사용하는 대상 포트이며, Proxy 서버가 반드시 사용해야 하는 포트는 아닙니다

일반 DNS에서 흔히 사용하는 포트이며, 이름 조회와 웹페이지 연결은 서로 다른 단계입니다

항목 1

매번 변수 하나만 조정한 다음 같은 대상을 다시 테스트하세요

현재 서버의 편집 화면을 열고 주소, 포트, 인증 정보를 사용 중인 서비스 제공자가 안내한 원본 정보와 하나씩 대조하세요. Shadowsocks의 암호화 방식과 비밀번호, VMess 또는 VLESS의 ID 정보, Trojan 비밀번호, TLS가 필요한 경우의 서버 이름과 전송 설정은 서로 대체할 수 없습니다. 웹페이지에서 보통 443 포트를 쓴다는 이유만으로 서버 포트를 임의로 443으로 변경하지 마세요.

모든 서버 테스트 실패: 연결을 껐을 때의 네트워크 상태와 먼저 비교한 뒤 구독 상태, 계정 유효 기간, 서버 주소가 변경되었는지 확인하세요.
서버 하나만 실패: 현재 목록에서 사용 가능한 것으로 확인된 다른 서버를 선택해 다시 테스트하세요. 문제가 해결되면 모든 규칙을 다시 작성하기보다 기존 서버부터 점검하세요.
테스트는 성공했지만 서비스 이용 실패: Global Routing과 DNS를 이어서 확인하세요. 테스트가 TCP만 확인했으며 실제 서비스는 UDP에 의존하는지도 살펴보세요.
구독 갱신 후 문제 발생: 갱신 전후의 주소와 프로토콜 설정을 비교하세요. 구독 갱신 성공은 데이터가 정상적으로 가져와졌다는 뜻일 뿐, 구독에 포함된 모든 서버를 사용할 수 있다는 의미는 아닙니다.

결론: 서버 하나씩 분리해 확인

같은 네트워크와 웹페이지, 동일한 Global Routing 옵션에서 사용 중인 다른 서버로 바꾼 뒤 접속이 복구된다면 기존 서버의 서비스 상태와 설정부터 확인하세요. 이때 DNS와 FINAL을 동시에 변경하지 마세요.

두 번째 점검: Global Routing으로 모드와 규칙 문제 구분

Home → Global Routing에서 현재 옵션을 확인하세요. Proxy, Direct, Config, Scene은 네 가지 프로토콜이 아니라 트래픽을 처리하는 서로 다른 방식입니다. 진단을 위해 임시로 전환했다면 테스트 후 원래 사용 방식으로 되돌리세요. Proxy 테스트 한 번의 성공만으로 모든 분기 규칙이 올바르다고 판단해서는 안 됩니다.

옵션	주요 의미	점검할 내용
Proxy	트래픽을 Proxy로 처리합니다. 우회 대상 등의 설정은 별도로 확인해야 합니다	현재 선택된 서버가 대상 요청을 처리할 수 있는가
Direct	트래픽을 직접 연결 방식으로 처리합니다	현재 기본 네트워크에서 원래 접속할 수 있는 대상인가
Config	현재 구성의 규칙에 따라 요청 정책을 결정합니다	어떤 규칙이 일치했고 최종적으로 어떤 정책이 적용되었는가
Scene	구성된 Scene 설정에 따라 해당 라우팅 방식을 적용합니다	옵션 이름만 보지 말고 현재 Scene에서 실제로 어떤 설정을 사용하는지 확인하세요

기존 옵션을 먼저 기록한 다음 Proxy를 임시로 선택하고, 앞서 실패한 동일한 웹페이지를 다시 여세요. Proxy에서는 접속되지만 Config에서는 안 된다면 현재 구성과 규칙 일치 여부를 우선 점검해야 합니다. 다만 두 모드에서 DNS 경로가 다를 가능성도 고려하세요. 두 방식 모두 실패한다면 규칙에만 집중하지 말고 서버와 DNS부터 다시 확인하세요.

세 번째 점검: DNS 조회 완료 여부와 경로 접근성

DNS 조회는 요청 과정의 일부입니다. DNS 실패와 서버 연결 실패 모두 ‘웹페이지가 계속 로드 중’인 것처럼 보일 수 있습니다. 요청 기록을 열어 도메인 조회 단계에서 실패했는지, 주소를 받은 뒤 대상 연결에 실패했는지 구분하세요. Safari의 일반적인 오류 메시지만으로 DNS 문제라고 단정하지 마세요.

Config에서 현재 사용 중인 구성을 열고 텍스트의 [General]과 dns-server를 확인하세요. 조회 서버를 직접 입력한 적이 있다면 주소가 올바른지, 현재 네트워크에서 접근 가능한지, 아직 연결되지 않은 Proxy 경로에 의존하는지 점검합니다. 낯선 DNS 설정을 여러 개 한꺼번에 추가하지 마세요. 먼저 이전에 정상 작동하던 구성 사본으로 되돌린 다음 항목별로 비교하세요.

도메인 주소를 조회하지 못함: DNS 접근성, 주소 입력, 현재 구성의 조회 설정을 우선 점검하세요.
주소는 받았지만 연결 시간 초과: 대상 연결 경로, 서버 상태, 규칙 정책을 이어서 확인하세요. 조회 서버만 바꾸는 것으로 해결되지 않을 수 있습니다.
도메인 하나만 실패: 도메인 자체와 관련 규칙을 확인하고, 해당 사이트가 다른 리소스 도메인에 의존하는지도 살펴보세요.
네트워크를 바꾼 뒤에만 실패: Wi-Fi와 셀룰러 네트워크에서 각각 다시 테스트해 현재 네트워크가 조회 서버나 서버에 대한 접근을 제한하는지 확인하세요.

오류: `Could not resolve host`

원인 및 해결 방법: 흔히 발생하는 도메인 조회 실패 메시지이며 진단 도구에 따라 문구가 다를 수 있습니다. 먼저 대상 도메인과 DNS 설정을 확인한 뒤 현재 네트워크에서 조회 서버에 접근할 수 있는지 점검하세요. 서버 인증 정보는 바로 변경하지 마세요.

오류: `Connection timed out`

원인 및 해결 방법: 제한 시간 안에 연결이 완료되지 않았으며 서버 또는 대상 경로에서 발생했을 수 있습니다. 기록에서 실패한 대상과 포트를 확인한 뒤 같은 네트워크에서 사용 중인 다른 서버로 테스트해 특정 지점의 문제인지 네트워크 전체 문제인지 구분하세요.

오류: `Connection refused`

원인 및 해결 방법: 대상 또는 중간 장치가 연결을 명시적으로 거부했을 때 흔히 나타납니다. 기록에 표시된 대상이 Proxy 서버인지 웹사이트인지 확인하고 해당 포트와 서비스 상태를 점검하세요. 웹페이지를 반복해서 새로 고쳐도 잘못된 포트는 해결되지 않습니다.

네 번째 점검: 규칙 순서, 정책 참조, FINAL

Global Routing에서 Config를 사용하면 요청의 경로는 현재 구성의 규칙에 따라 결정됩니다. 먼저 Config에서 선택된 파일을 확인하고 [Rule]을 점검하세요. 규칙은 일반적으로 위에서부터 순서대로 적용되며 앞쪽 규칙과 일치한 요청은 뒤쪽의 더 구체적인 규칙까지 진행하지 않습니다. 따라서 규칙 내용이 올바르더라도 위치가 잘못되면 접속 문제가 생길 수 있습니다.

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

위 예시는 문법을 설명하기 위한 것으로, 기존 구성에 그대로 적용할 수 있는 일반적인 해결책이 아닙니다. example.com은 예시 도메인입니다. PROXY는 현재 구성에 정의되어 있고 사용할 수 있는 정책 또는 정책 그룹이어야 하며, 정의 없이 이름만 복사해서는 작동하지 않습니다. FINAL,PROXY의 실제 동작은 해당 정책에서 최종적으로 선택하는 서버에도 영향을 받습니다.

키워드	일치 기준	주요 점검 항목
DOMAIN-SUFFIX	도메인 및 하위 도메인	앞쪽의 광범위한 규칙에 먼저 걸렸는지, 리소스 도메인이 누락되었는지 확인하세요
IP-CIDR	대상 IP 주소 대역	네트워크 대역과 마스크가 올바른지, no-resolve 설정이 의도에 맞는지 확인하세요
GEOIP	대상 IP의 지리 데이터베이스상 위치	브랜드 소재지로 추정하지 말고 실제 조회된 IP를 데이터베이스에서 확인하세요
FINAL	앞선 규칙과 일치하지 않은 요청에 적용되는 기본 규칙	규칙이 마지막에 있는지, 참조된 정책이 정의되어 있고 사용 가능한지 확인하세요

no-resolve는 해당 IP 규칙과 일치시키기 위해 도메인을 추가 조회하지 않도록 하는 옵션이지, 앱 전체의 DNS를 끄는 설정이 아닙니다. REJECT는 해당 요청을 차단합니다. 기본 페이지는 열리지만 이미지나 로그인 API가 실패한다면 모든 규칙을 바로 삭제하기보다 해당 리소스 도메인이 차단 규칙에 일치했는지 확인하세요.

결론: 규칙 일치 기록을 확인해 조정

실패한 요청이 잘못된 정책과 일치했다는 점을 확인한 뒤에 해당 규칙을 이동하거나 수정하세요. 요청이 FINAL까지 도달하지 않았다면 FINAL을 수정해도 문제가 해결되지 않습니다. 예상한 Proxy 정책과 이미 일치했다면 해당 정책이 실제로 어떤 서버를 선택했는지 이어서 추적하세요.

자주 묻는 질문: 테스트는 성공했는데 일부 기능만 실패할 때

Connectivity Test에 결과가 있는데도 웹페이지가 열리지 않는 이유는 무엇인가요?

테스트 대상과 웹페이지 대상이 다를 수 있으며, 테스트가 인증·TLS·DNS·웹페이지에 필요한 모든 연결을 확인하지 않을 수도 있습니다. 먼저 Home → Global Routing에서 Proxy를 임시로 선택해 다시 테스트한 다음, 실패한 요청이 조회·연결·정책 선택 중 어느 단계에서 멈췄는지 확인하세요.

Proxy에서는 인터넷이 되지만 Config로 바꾸면 실패합니다. 무엇부터 확인해야 하나요?

먼저 Config에서 현재 선택된 파일을 확인하고 실패한 요청의 규칙 일치 및 정책 그룹 선택을 살펴보세요. 요청이 실수로 DIRECT로 연결되거나 REJECT에 일치했는지, 사용할 수 없는 정책을 참조했는지 확인합니다. DNS 경로가 다를 가능성도 고려하고 모든 요청을 바로 하나의 정책으로 바꾸지 마세요.

Wi-Fi에서는 되는데 셀룰러 네트워크에서는 실패합니다. 프로토콜을 지원하지 않는 건가요?

먼저 같은 서버와 같은 URL로 다시 테스트하고 셀룰러 데이터 권한, Settings → On Demand, Scene 설정을 확인하세요. 네트워크에 따라 포트나 UDP를 다르게 처리할 수 있습니다. 한 번 실패했다는 이유만으로 프로토콜 자체가 지원되지 않는다고 판단할 수는 없습니다.

웹페이지는 열리는데 통화나 동영상이 안 되면 어떻게 해야 하나요?

해당 기능이 UDP를 사용하는지 확인한 뒤 현재 프로토콜과 서버 측 설정 및 필요한 전달 기능을 점검하세요. Hysteria2는 UDP에 의존합니다. 다른 프로토콜의 UDP 지원 여부도 서버 설정에 따라 다를 수 있으므로 프로토콜 이름만 보고 판단하면 안 됩니다.

구독 갱신에 성공하면 서비스 문제도 없다고 볼 수 있나요?

아닙니다. 갱신 성공은 구독 내용을 가져와 처리했다는 뜻일 뿐입니다. Home으로 돌아가 현재 서버의 주소, 인증 정보, 연결 상태를 확인하세요. 이용 중인 서비스 제공자에게 문의해야 한다면 민감 정보를 가린 오류 단계, 네트워크 유형, 재현 절차를 전달하세요.

마무리: 설정을 복구하고 재현 기록 보관

문제를 찾으면 확인된 필수 변경 사항만 남기세요. 임시로 끈 On Demand를 복구하고 Global Routing을 평소 사용하던 옵션으로 되돌린 다음, 기본 웹페이지와 기존에 실패했던 대상을 각각 테스트합니다. 특정 네트워크나 서버에서만 재현된다면 문제를 앱 전체로 확대해 설명하지 말고 해당 조건을 기록하세요.

환경 기록: Wi-Fi 또는 셀룰러 네트워크, 네트워크 로그인을 완료했는지, 연결을 껐을 때 기본 웹페이지에 접속할 수 있는지 기록하세요.
선택 항목 기록: 서버의 사용자 지정 이름, Global Routing 옵션, Config 파일 이름을 기록하고 비밀번호와 구독 인증 정보는 제외하세요.
오류 단계 기록: 조회 실패, 연결 시간 초과, 인증 실패 또는 예상과 다른 정책 일치 여부와 함께 민감 정보를 가린 원본 오류 메시지를 보관하세요.
변경 사항 기록: 이번에 변경한 항목이 무엇인지, 같은 대상에 다시 접속할 수 있었는지, 원래 설정으로 복구한 뒤 문제가 다시 발생하는지 기록하세요.

각 항목을 하나씩 확인하려면 구성 필드 설명을 참고하세요. 처음 가져온 구성이거나 출처가 확실하지 않다면 먼저 시작 가이드에서 작업 순서를 확인하세요. 앱 일회성 구매는 회선 이용 요금제와 별개이므로 앱 구매 상태와 사용 중인 서비스의 유효 상태를 각각 확인해야 합니다.