Shadowrocket 연결됨에도 웹페이지가 열리지 않을 때: 서버·Global Routing·DNS·규칙 점검

이 글의 핵심 내용

연결 스위치가 켜졌다는 것은 기기에서 연결 기능이 시작됐다는 뜻일 뿐, 원격 서버와 도메인 조회, 웹 요청이 모두 성공했다는 의미는 아닙니다. 사용자가 이미 보유한 서비스와 구독이 있다는 전제로 기본 네트워크, 서버, Global Routing, DNS, 규칙 순서로 확인합니다. iPhone / iPad의 Home, Config, Settings를 기준으로 설명하며, Mac·Windows·Android·Linux에서도 같은 순서로 해당 설정을 확인할 수 있습니다. 메뉴 위치는 플랫폼마다 다를 수 있습니다.

1. 먼저 기본 네트워크에서 웹사이트에 접속되는지 확인

Shadowrocket 연결됨으로 표시되는데 브라우저가 계속 로딩된다면 서버, DNS, 구성 파일을 한꺼번에 바꾸지 마세요. 한 번에 한 가지 조건만 변경하고, 같은 웹페이지가 변경 전후에 어떻게 표시되는지 기록하면 문제가 현재 네트워크에 있는지 프록시 연결이나 트래픽 분기 설정에 있는지 구분할 수 있습니다.

테스트할 때는 평소 직접 접속할 수 있는 HTTPS 웹페이지와 기존 서버를 거쳐야 접속할 수 있는 웹페이지를 각각 이용하세요. 특정 사이트의 점검 상태, 계정 상태, 접속 제한을 전체 연결 장애로 오해하지 마세요. 캐시된 페이지가 표시된다는 이유만으로 네트워크가 정상이라고 판단해서도 안 됩니다.

자동 연결 일시 중지

Settings → On Demand에서 현재 조건을 기록한 뒤 자동 연결을 잠시 끄고, Home으로 돌아가 연결 스위치를 끄세요. 이렇게 하면 수동으로 연결을 해제한 뒤 네트워크 전환 조건에 따라 다시 연결되는 일을 방지할 수 있습니다.
기본 네트워크 확인

브라우저에서 직접 접속할 수 있는 웹페이지를 새로고침하세요. 연결을 끈 상태에서도 접속할 수 없다면 Config를 바로 수정하지 말고 Wi-Fi 로그인 인증, 모바일 데이터 권한 또는 현재 네트워크 자체를 먼저 확인하세요.
네트워크를 바꿔 재확인

가능하다면 같은 기기에서 Wi-Fi와 Cellular에 각각 연결해 동일한 주소에 접속해 보세요. 한 네트워크에서만 실패한다면 네트워크 환경과 관련된 문제일 수 있지만, 서버 포트와 DNS, 인증 제한을 추가로 구분해야 합니다.
초기 상태 기록

Home에서 현재 선택한 서버와 Global Routing 모드, Config에서 현재 활성화된 파일을 기록하세요. 연결을 다시 켠 뒤 다음 항목을 확인하고, 테스트 중에는 전체 구성을 한꺼번에 업데이트하지 마세요.

2. 서버 확인: 지연 시간 수치가 웹페이지 접속을 보장하지는 않습니다

Home에서 실제 선택된 서버가 본인이 보유한 유효한 구독에 포함된 항목인지 확인하세요. 목록에 서버가 표시된다는 것은 구성이 가져와졌다는 뜻일 뿐입니다. 구독 내용이 바뀌었거나 계정이 만료됐거나 원격 주소가 더 이상 유효하지 않으면 기기에는 이전 항목이 계속 표시될 수 있습니다. 먼저 본인의 구독을 업데이트한 다음 선택한 서버가 여전히 유효한지 확인하세요.

서버 주소, 포트, 프로토콜, 인증 정보가 본인의 서비스 제공자가 안내한 정보와 일치하는지 확인하세요. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 필요한 입력 항목이 서로 다릅니다. 한 프로토콜의 비밀번호, UUID, 키를 다른 프로토콜에 그대로 입력하지 마세요. TLS 연결은 서버에서 요구하는 서버 이름과 기기 시간을 확인해야 합니다. 인증서 검증을 끄는 것으로 문제를 우회하지 마세요.

일반 DNS에서 자주 사용하는 포트입니다. 모든 DNS 요청이 이 포트를 사용하는 것은 아닙니다.

443

HTTPS에서 자주 사용하는 포트입니다. 프록시 서버가 반드시 이 포트를 사용해야 하는 것은 아닙니다.

4가지

Global Routing 모드: Proxy / Direct / Config / Scene

서버 테스트에 지연 시간이 표시되더라도 웹페이지 요청 전체가 성공했다는 뜻은 아닙니다. 테스트는 특정 방식과 주소만 확인할 수 있으며, 실제 웹 탐색에는 도메인 조회, 핸드셰이크, 인증, 대상 사이트의 응답도 필요합니다. 반대로 테스트가 시간 초과됐다는 이유만으로 계정이 만료됐다고 단정할 수는 없습니다. 실제 요청 기록과 함께 확인하세요.

오류: Connection timed out

원인: 제한 시간 안에 연결이 완료되지 않았습니다. 네트워크 패킷 손실, 포트에 연결할 수 없는 상태 또는 원격 서버의 무응답이 원인일 수 있습니다.

해결 방법: 기록에 표시된 대상 주소와 포트를 확인하고, 네트워크를 바꿔 다시 테스트한 뒤 본인이 보유한 다른 유효 서버와 비교하세요. 이 오류만으로 인증 정보를 바꾸지는 마세요.

오류: Connection refused

원인: 대상 포트가 연결을 명시적으로 거부했습니다. 포트를 잘못 입력했거나 서비스가 포트에서 대기 중이 아니거나 중간 장비가 연결을 차단했을 수 있습니다.

해결 방법: 본인의 서비스 정보를 기준으로 포트를 확인하세요. 설정이 일치하는데도 오류가 계속되면 서비스 제공자에게 해당 포트의 서비스 상태를 문의하세요.

위 내용은 네트워크 진단에서 나타날 수 있는 영문 오류 메시지입니다. 플랫폼이나 로그 출처에 따라 대소문자와 앞뒤 문구가 다를 수 있습니다. 오류를 판단할 때는 대상 주소도 함께 확인하세요. 프록시 서버 연결 실패와 대상 웹사이트 연결 실패는 발생 위치가 다릅니다.

3. Global Routing 확인: Proxy와 Config를 하나씩 비교 테스트

Home → Global Routing에서 현재 모드를 확인하세요. Direct는 요청이 직접 연결로 나간다는 뜻이지, 사용 가능한 서버를 자동으로 선택한다는 의미가 아닙니다. Config에서는 현재 구성 파일의 규칙에 따라 정책을 결정합니다. Scene은 설정된 시나리오 조건에 따라 작동하므로 Config와 항상 같은 방식이라고 볼 수 없습니다.

모드	문제 해결 시 역할	다음 단계
Proxy	일반적인 웹 요청을 현재 선택된 프록시로 보내 분기 규칙이 결과에 미치는 영향을 줄입니다.	Home에서 현재 선택된 항목을 확인하세요. 고정 서버가 아니라 정책 그룹일 수 있습니다.
Direct	프록시 서버를 거치지 않는 직접 연결과 비교합니다.	대상에 원래 직접 접속할 수 없다면 이 모드에서 실패해도 서버 장애를 의미하지 않습니다.
Config	현재 Config의 규칙을 매칭해 해당 정책을 실행합니다.	실패한 요청에 실제로 적용된 규칙과 최종 정책을 확인하세요.
Scene	설정된 시나리오 조건에 따라 해당 동작을 선택합니다.	현재 네트워크에 해당하는 시나리오를 확인하고, 문제 해결 도중 조건을 추가하지 마세요.

잠시 Proxy로 전환하되 서버, 네트워크, 테스트 주소는 그대로 둔 채 웹페이지 요청을 다시 보내세요. Proxy에서는 접속되지만 Config에서는 실패한다면 규칙과 정책 그룹을 우선 확인하세요. 둘 다 실패한다면 FINAL이 잘못됐다고 단정하지 말고 서버와 DNS를 계속 점검하세요. 테스트가 끝나면 원래 모드로 되돌려 임시 진단 설정을 최종 구성으로 남기지 마세요.

결론: 모드에 따른 차이부터 확인

같은 네트워크, 서버, 주소에서 Proxy는 성공하고 Config만 실패한 경우에 한해 규칙 매칭과 정책 선택을 우선 점검할 근거가 충분합니다.

4. DNS 확인: 도메인 조회 실패와 연결 실패 구분

도메인 조회에 실패하면 연결에 사용할 대상 주소를 아직 얻지 못한 상태입니다. 서버 연결 실패는 도메인 조회가 성공한 뒤에 발생할 수 있습니다. 두 경우 모두 브라우저에는 웹페이지를 열 수 없다고 표시될 수 있으므로 브라우저 메시지나 연결 스위치만 보지 말고 실제 요청 기록을 확인하세요.

Config에서 현재 활성화된 파일의 [General]에 DNS 관련 매개변수가 있는지 확인하고, Settings의 DNS 설정과 두 설정의 우선 적용 관계도 살펴보세요. 먼저 기존 값을 기록하고 구성 파일과 DNS 주소를 동시에 바꾸지 마세요. 사용자 지정 DNS도 접속 가능해야 합니다. 암호화 DNS를 사용하는 경우 연결 경로와 초기 도메인 조회도 고려해야 합니다.

도메인 관련 요청만 실패: 조회 오류가 발생했는지 확인하고 현재 DNS 서버에 이 네트워크에서 접속할 수 있는지 확인하세요. IP 주소로 직접 접속하는 테스트는 참고용일 뿐 HTTPS 도메인 테스트를 대신할 수 없습니다.
조회 결과가 있지만 연결 시간 초과: 대상 IP, 적용된 정책, 서버 연결을 계속 확인하세요. DNS를 반복해서 바꾸지는 마세요.
Wi-Fi에서만 오류 발생: 먼저 네트워크 인증이 완료됐는지 확인한 다음 Cellular와 비교하세요. 네트워크의 DNS 제한은 서버 장애와 비슷하게 나타날 수 있습니다.
변경 후에도 결과가 같음: 기존 웹 연결을 종료하고 다시 연결한 뒤 같은 주소를 불러오세요. 캐시된 결과나 재사용된 연결을 새 설정의 효과로 오인하지 않도록 합니다.

오류: Could not resolve host

원인: 요청을 보낸 구성 요소가 도메인에 해당하는 주소를 얻지 못했습니다. 로컬 DNS 조회나 원격 DNS 조회 과정에서 오류가 발생했을 수 있습니다.

해결 방법: 먼저 도메인 철자와 DNS 접속 가능 여부를 확인한 뒤 요청이 이동한 경로를 살펴 오류가 어느 쪽에서 발생했는지 판단하세요. 테스트 도구에서 발생한 오류라면 해당 도구의 연결 경로를 기준으로 확인하세요.

5. 규칙 확인: 요청이 실제로 FINAL에 도달하는지 확인

Global Routing → Config로 돌아가 현재 활성화된 구성 파일의 [Rule]을 확인하세요. 규칙은 일반적으로 위에서 아래 순서로 매칭됩니다. 요청이 앞쪽의 유효한 규칙에 일치하면 FINAL까지 계속 확인하지 않습니다. FINAL은 앞선 규칙에 일치하지 않은 요청에 적용되는 기본 정책이지, 모든 트래픽이 반드시 거치는 단계가 아닙니다.

아래는 규칙 구조를 보여 주는 예시일 뿐 완전한 구성 파일이 아닙니다. example.com과 192.0.2.0/24는 문서용 예시 주소입니다. 이 내용으로 본인의 Config 전체를 덮어쓰지 마세요. 정책 이름도 실제 구성에서 사용할 수 있는 정책과 일치해야 합니다.

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

DOMAIN-SUFFIX: 지정한 도메인과 하위 도메인에 매칭됩니다. 실패한 웹페이지의 도메인이 앞쪽 DIRECT 규칙에 매칭됐다면 FINAL을 수정해도 해당 요청에는 영향이 없습니다.
IP-CIDR: 대상 IP 대역에 매칭됩니다. 예시의 no-resolve는 이 규칙을 매칭하기 위해 도메인 조회를 일부러 수행하지 않는다는 뜻이지, 앱 전체의 DNS를 끈다는 뜻은 아닙니다.
GEOIP: 대상 IP의 지리 정보에 따라 매칭합니다. 웹페이지 언어나 도메인 접미사로 판단하지 않으며, 도메인 조회 결과가 바뀌면 이후 매칭에도 영향을 줄 수 있습니다.
FINAL: 앞선 규칙에 매칭되지 않은 요청에 최종 정책을 적용합니다. 정책 그룹을 지정한 경우 그룹에서 현재 선택된 서버가 유효한지도 확인하세요.

실패한 요청을 한 번 재현한 뒤 연결 기록에서 대상 도메인, 매칭된 규칙, 최종 정책을 확인하세요. 웹페이지 하나가 여러 도메인에 요청을 보낼 수 있습니다. 기본 문서는 열렸지만 스크립트나 이미지 요청이 실패하면 화면이 비어 있거나 일부만 로드될 수 있습니다. 이때는 홈페이지 도메인 전체의 정책을 바꾸지 말고 실패한 리소스 도메인을 각각 확인하세요.

기록에 FINAL이 표시되지만 최종 정책이 사용할 수 없는 서버라면 서버나 정책 그룹 선택을 바로잡으세요. 앞쪽의 범위가 너무 넓은 DIRECT 규칙에 매칭됐다면 먼저 백업한 뒤 해당 규칙의 범위를 좁히세요. 한 번에 규칙 하나만 수정하고 다시 테스트해야 전체 규칙을 삭제해 문제를 파악할 근거를 잃지 않습니다.

6. 자주 묻는 질문과 점검 후 복구

지연 시간은 표시되는데 웹페이지가 계속 로딩되는 이유는 무엇인가요?

지연 시간 테스트는 웹 요청의 모든 단계를 확인하지 않습니다. 같은 서버를 유지한 채 Home → Global Routing에서 Proxy를 잠시 선택하고 같은 주소를 다시 열어 보세요. 그런 다음 요청이 도메인 조회와 원격 연결을 완료했는지 확인하세요. 지연 시간 수치만 보고 서버를 계속 바꾸지는 마세요.

Proxy로 바꾸면 해결되는데 계속 이렇게 사용해야 하나요?

Config의 규칙과 정책을 우선 확인해야 한다는 뜻이지, Proxy를 계속 사용해야 한다는 의미는 아닙니다. Config에서 실패한 요청에 적용된 규칙을 확인하고 수정한 뒤 Global Routing → Config로 되돌려 동일한 웹페이지와 리소스를 다시 테스트하세요.

구독 업데이트에 성공했는데도 연결할 수 없는 이유는 무엇인가요?

업데이트 성공은 구독 내용을 가져와 처리했다는 뜻일 뿐, 모든 서버가 그 시점에 사용 가능하다는 보장은 아닙니다. Home으로 돌아가 현재 선택된 항목을 확인하고 주소, 포트, 서비스 유효 기간을 점검한 다음 본인의 서비스 정보를 기준으로 인증 항목을 확인하세요.

연결을 껐는데 다시 저절로 켜지면 어떻게 하나요?

Settings → On Demand에서 자동 연결 조건을 확인하고 잠시 끈 뒤 수동으로 테스트하세요. 점검이 끝나면 필요한 조건을 다시 설정하고 Wi-Fi와 Cellular를 전환할 때 예상대로 작동하는지 확인하세요.

점검이 끝나면 임시로 변경한 Global Routing, DNS, On Demand 설정을 복구하세요. 문제를 안정적으로 재현할 수 있도록 기기 플랫폼, 네트워크 유형, 발생 시간, 대상 도메인, 오류 메시지, 매칭된 규칙, 최종 정책을 기록하세요. 본인의 서비스 제공자에게 문의할 때 전체 구독 링크, 인증 비밀번호, 키를 공개하지 마세요.

기본 네트워크에서 실패: 네트워크 로그인, 라우팅 또는 기기의 네트워크 접속 권한부터 확인하세요.
Proxy와 Config에서 모두 실패: 서버 매개변수, 원격 접속 가능 여부, DNS 조회 과정을 우선 확인하세요.
Config에서만 실패: 앞쪽 규칙, FINAL, 정책 그룹에서 현재 선택된 항목을 확인하세요.
일부 리소스만 실패: 리소스 도메인별 요청 결과를 확인하고 유효한 규칙은 유지하면서 원인을 찾은 항목만 수정하세요.

재설치하거나 플랫폼별 설치 방법을 확인하려면 이 사이트의 전체 플랫폼 다운로드 페이지를 이용하세요. Shadowrocket은 폐쇄형 상용 앱입니다. 앱 구매와 회선 서비스는 별개입니다. 앱을 구매해도 회선 이용권이 포함되지 않으며, 가져오기와 테스트에는 사용자가 이미 보유한 구독이 필요합니다. iPhone / iPad의 시스템 요구 사항은 App Store 페이지를 기준으로 확인하세요. Mac은 Apple 칩용과 Intel용 버전을 제공합니다.