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

빠른 안내

Shadowrocket의 연결 스위치를 켰다는 것은 기기에서 해당 연결을 활성화했다는 뜻일 뿐, 원격 서버와 DNS, 대상 웹사이트까지 모두 정상이라는 의미는 아닙니다. 이미 이용 중인 서비스 제공업체의 설정이 있는 사용자를 위한 안내입니다. 먼저 연결을 끊었을 때의 네트워크 상태를 확인한 뒤 Home에서 서버, Global Routing, DNS, Config 규칙을 점검하세요. 한 번에 한 항목만 변경하고 같은 웹페이지로 다시 테스트해 결과를 비교하세요.

1. 먼저 기기 네트워크 문제와 연결 문제 구분하기

현재 Config를 저장하고 Home에서 선택한 서버와 Global Routing 모드를 기록하세요. 처음부터 모든 설정을 삭제하지 마세요. Config를 새로 만들면 기존 규칙과 정책 선택, DNS 설정이 사라져 변경 전후 결과를 비교하기 어려워집니다.

평소 접속할 수 있는 서로 다른 웹사이트의 HTTPS 페이지 두 개를 준비하세요. IP 주소 대신 전체 도메인 이름으로 접속해야 합니다. 인증서 확인과 가상 호스트 선택에는 도메인 이름이 사용되므로, IP로 직접 접속해 발생한 오류만으로 DNS 문제라고 단정할 수 없습니다.

현재 설정 기록하기

Home → Global Routing에서 현재 선택한 옵션, 선택된 서버 이름, 사용 중인 Config를 기록하세요. 기록이나 스크린샷에 서버 주소, 비밀번호 또는 UUID가 포함된다면 본인이 관리하는 안전한 위치에만 보관하세요.
On Demand 일시 중지하기

Settings → On Demand에서 기존 활성화 상태를 기록한 뒤 문제를 확인하는 동안 잠시 비활성화하세요. 수동으로 연결을 끊은 뒤 자동으로 다시 연결되는 일을 방지할 수 있습니다. 테스트가 끝나면 원래 설정으로 복원하세요.
연결을 끊고 테스트하기

Home에서 연결 스위치를 끄고 Safari로 준비한 두 페이지에 접속해 보세요. 두 페이지 모두 열리지 않으면 먼저 Wi-Fi 로그인 인증, 라우터 또는 셀룰러 데이터 문제를 해결하세요. 규칙은 아직 변경하지 마세요.
네트워크를 바꿔 다시 테스트하기

Wi-Fi와 셀룰러 데이터 간에 전환한 뒤 같은 페이지를 다시 열어 보세요. 셀룰러 데이터 사용량에도 유의하세요. 한쪽 네트워크에서만 실패한다면 네트워크 유형을 기록하고 포트 또는 전송 방식이 제한되는지 확인하세요.

호텔이나 학교 등의 네트워크는 먼저 웹페이지에서 인증해야 할 수 있습니다. 연결을 끊고 네트워크 인증을 마친 뒤 Shadowrocket을 켜서 다시 테스트하세요. 다른 네트워크 확장 기능도 연결을 관리 중이라면 점검하는 동안 해당 연결을 일시 중지해 네트워크 설정 간 간섭을 방지하세요.

2. 서버 상태 확인하기: 지연 시간만으로 웹 접속 여부를 판단하지 마세요

Home으로 돌아가 테스트하려는 서버가 선택되어 있는지 확인하세요. 이름이 비슷한 예전 항목을 선택하지 않도록 주의하세요. 서비스 제공업체가 제공한 기존 설정을 기준으로 Type, 주소, 포트, 인증 정보를 하나씩 확인하세요. 프로토콜 유형과 매개변수는 서로 맞아야 합니다. 주소와 포트만 남긴 채 VMess를 VLESS로 바꾸거나, Trojan의 인증 방식을 Shadowsocks에 적용해서는 안 됩니다.

Home에서 Connectivity Test를 실행해 결과를 확인하세요. 지연 시간이 표시되더라도 해당 테스트 방식의 탐지가 성공했다는 뜻일 뿐, 모든 HTTPS 요청이나 UDP 트래픽, 대상 웹사이트가 정상 작동한다는 보장은 아닙니다. 실제 접속이 복구됐는지 확인하려면 같은 웹페이지로 계속 테스트하세요.

443 / TCP

HTTPS에서 흔히 사용하는 포트입니다. 서버 수신 포트는 기존 설정을 확인하세요.

53 / UDP、TCP

기존 DNS에서 흔히 사용하는 포트입니다. 네트워크를 바꿀 때 접속 가능한지 확인하세요.

회당 1개 항목

한 번에 변수 하나만 변경하고, 다시 연결한 뒤 재테스트하세요.

기존 서버가 모두 시간 초과되는 경우: 먼저 접속 네트워크를 바꿔 보고 서비스 제공업체 계정 상태와 서버 점검 여부를 확인하세요. 관련 없는 설정을 여러 개 연달아 바꾸지 마세요.
항목 하나만 실패하는 경우: 정상 작동하는 다른 설정과 비교해 해당 항목의 포트, 인증, TLS, 전송 매개변수를 확인하세요.
구독은 업데이트됐지만 연결에 실패하는 경우: 구독을 가져오는 요청과 서버에 연결하는 요청은 서로 다른 경로를 사용합니다. 업데이트에 성공해도 목록의 모든 서버가 정상이라는 뜻은 아닙니다.
Hysteria2를 사용하는 경우: 현재 네트워크에서 UDP를 제한하는지 확인하세요. 특정 Wi-Fi에서만 실패한다면 설정을 그대로 둔 채 다른 네트워크에서 테스트하세요. 문제를 곧바로 DNS 탓으로 돌리지 마세요.

결론: 먼저 작동하는 연결 경로 확인하기

같은 서버가 셀룰러 데이터에서는 작동하고 Wi-Fi에서는 작동하지 않는다면 Wi-Fi의 접속 제한을 우선 확인하세요. 두 네트워크 모두에서 실패한다면 서버 설정과 서비스 상태를 점검하세요. 이 경우 DOMAIN-SUFFIX나 FINAL을 변경해도 서버 핸드셰이크 실패가 해결되는 경우는 드뭅니다.

3. Global Routing으로 서버 문제와 트래픽 분기 문제 구분하기

Home → Global Routing으로 이동해 현재 선택 항목을 확인한 다음 전환하세요. Proxy는 복잡한 분기 규칙의 영향을 잠시 줄여 테스트할 때 적합합니다. Direct는 직접 연결 경로를 확인할 때 사용하고, Config는 현재 설정에 따라 트래픽을 분기합니다. Scene을 사용하는 경우에는 현재 Scene에 실제로 적용된 설정도 확인하세요. 옵션 이름만으로 요청 경로를 판단해서는 안 됩니다.

옵션	점검 목적	재테스트 후 판단
Proxy	프록시 경로로 테스트해 Config 분기 규칙의 영향을 먼저 줄입니다.	여전히 실패하면 선택한 서버, DNS, 대상 웹사이트를 우선 확인하세요.
Direct	원격 프록시를 거치지 않고 현재 네트워크의 직접 접속 가능 여부를 확인합니다.	Direct로 접속된다고 서버가 정상이라는 뜻은 아니며, 모든 대상에 직접 연결이 적합한 것도 아닙니다.
Config	현재 Config의 규칙과 정책에 따라 요청을 처리합니다.	Proxy에서는 성공하고 Config에서는 실패한다면 규칙 적용과 정책 선택을 중점적으로 확인하세요.
Scene	Scene 설정을 사용하는 경우 현재 Scene에 적용된 설정을 확인하세요.	Scene 조건과 최종 요청 기록을 함께 확인하세요. 고정된 출구 경로로 간주해서는 안 됩니다.

“Proxy로 한 번 테스트 → Config로 한 번 테스트” 순서로 진행하고, 전환할 때마다 요청을 새로 보내세요. 필요하면 연결을 끊었다가 다시 켜서 새 설정으로 테스트하세요. 브라우저의 기존 연결은 이전 경로를 계속 사용할 수 있으므로 이미 로드된 페이지만 확인하지 마세요.

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

DNS는 도메인 이름을 IP 주소로 변환합니다. 원격 서버 주소를 도메인 이름으로 입력했다면 연결을 시작하기 전에 해당 이름을 해석해야 할 수도 있습니다. 이때 DNS가 작동하지 않으면 “서버에 연결할 수 없음”처럼 보일 수 있습니다. 대상 웹사이트의 도메인 해석이 실패하면 연결 스위치는 켜져 있어도 웹페이지가 계속 로드 중인 것처럼 보일 수 있습니다.

Settings → DNS에서 현재 설정을 확인하고, 사용 중인 Config에 DNS 관련 설정이 있는지도 살펴보세요. Settings만 변경하면 현재 연결의 DNS 동작이 모두 바뀐다고 단정하지 마세요. 실제로 활성화된 설정과 요청 기록을 함께 확인해야 합니다. 변경하기 전에 기존 값을 기록해 두면 되돌릴 수 있습니다.

도메인 이름을 해석할 수 없는 경우: 해석 오류가 표시되는지 확인한 다음 DNS 주소 형식과 현재 네트워크에서 해당 주소에 접속할 수 있는지 점검하세요. 출처를 알 수 없는 DNS 주소를 여러 개 한꺼번에 입력하지 마세요.
암호화 DNS를 사용하는 경우: DNS 서비스 도메인의 초기 해석이 가능한지 확인하세요. 요청이 아직 연결되지 않은 프록시 경로로 전달되어 시작 과정에서 의존성 순환이 발생하는지도 살펴보세요.
IP 주소가 반환된 경우: 다음 단계의 TCP 연결이나 TLS 핸드셰이크를 확인하세요. DNS 해석 결과가 있다는 것만으로 대상 주소에 연결할 수 있다고 볼 수는 없습니다.
일부 웹사이트에서만 실패하는 경우: 반환된 주소가 IPv4인지 IPv6인지 기록하세요. IPv6 경로에 문제가 있다는 근거가 있을 때만 주소 체계를 바꿔 임시 비교 테스트를 하고, 원래 설정으로 복구하는 방법도 기록해 두세요.

오류: connection refused

원인과 해결 방법: 대상 포트에서 연결을 명시적으로 거부했습니다. 포트 입력이 잘못됐거나 서비스가 해당 포트에서 대기 중이지 않을 때 흔히 발생합니다. 기존 설정의 포트를 확인하고 서비스 제공업체에 서비스 상태를 문의하세요. DNS부터 변경하지 마세요.

오류: i/o timeout

원인과 해결 방법: 네트워크 작업이 제한 시간 안에 완료되지 않았습니다. 인접한 기록을 함께 확인해 DNS 해석, 연결, 데이터 읽기 중 어느 단계에서 발생했는지 판단하세요. 먼저 접속 네트워크를 바꿔 테스트한 뒤 해당 단계의 설정을 점검하세요.

오류: no such host

원인과 해결 방법: 도메인 이름에서 사용할 수 있는 해석 결과를 얻지 못했습니다. 주소 철자, 도메인의 유효 여부, 현재 DNS에 접속할 수 있는지를 확인하세요. 서버 도메인이 잘못됐다면 원본 설정을 다시 확인해야 합니다.

위 오류는 네트워크 오류 메시지에서 흔히 볼 수 있는 일부 문구입니다. 실제로는 앞에 다른 정보나 주소가 추가될 수 있습니다. 전체 맥락을 기록하되 인증 정보나 전체 구독 링크를 공개된 곳에 올리지 마세요. TLS 오류를 해결하려고 인증서 확인을 끄지 마세요. 먼저 기기 시간, 서버 도메인, TLS 매개변수가 서로 일치하는지 확인하세요.

5. Config 규칙 순서와 최종 정책 확인하기

Proxy에서는 같은 페이지가 열리지만 Config에서는 열리지 않는다면 Config로 이동해 실제로 활성화된 파일을 확인하세요. 관련 도메인에 어떤 규칙이 적용됐는지, 규칙이 어떤 정책을 지정하는지, 해당 정책에서 선택한 서버가 작동하는지 점검하세요. 파일 이름이 같아도 내용이나 현재 활성 상태까지 같다는 뜻은 아닙니다.

규칙은 일반적으로 순서대로 적용되며 먼저 일치한 규칙이 이후 처리를 결정합니다. 범위가 넓은 규칙이 앞에 있으면 뒤에 있는 더 구체적인 규칙이 적용되지 않을 수 있습니다. 아래 예시는 문법과 순서를 설명하기 위한 것으로, 기존 Config를 그대로 덮어쓸 수 있는 완성된 설정이 아닙니다. 정책 이름은 현재 설정에서 정상적으로 확인될 수 있어야 합니다.

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

DOMAIN-SUFFIX,example.com,PROXY: 예시 도메인과 그 하위 도메인에 일치합니다. 실제 웹사이트를 점검할 때는 먼저 실제 요청 도메인을 확인하세요. 페이지 리소스가 여러 도메인에서 제공될 수 있습니다.
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve: 해당 IPv4 대역에 일치합니다. no-resolve는 이 IP 규칙을 위해 도메인 해석을 별도로 요청하지 않는다는 뜻이며, DNS 전체를 비활성화한다는 의미는 아닙니다.
GEOIP,CN,DIRECT: IP 지리 위치 데이터베이스를 기준으로 일치 여부를 판단합니다. 웹페이지 언어, 도메인 접미사 또는 서버 이름을 기준으로 판단하는 것이 아닙니다.
FINAL,PROXY: 앞선 규칙에 일치하지 않은 요청을 처리합니다. FINAL을 앞에 배치하면 뒤에 있는 규칙이 제대로 적용되지 않습니다.

규칙이 정책 그룹을 지정한다면 그룹에서 현재 선택한 항목도 확인하세요. 규칙 자체가 유효해도 작동하지 않는 서버로 요청을 보낼 수 있습니다. 문제를 해결할 때는 실패한 대상과 관련된 항목만 변경하고, 다시 연결한 뒤 같은 페이지에 접속하세요. 새 요청 기록이 예상한 결과와 일치하는지도 확인해야 합니다.

6. 증상별로 다시 확인하고 재현 가능한 결과 기록하기

접속이 복구되면 원래 필요했던 On Demand를 다시 켜고 Global Routing을 평소 사용하던 모드로 되돌리세요. 먼저 웹페이지를 다시 테스트한 뒤 이전에 실패했던 앱도 확인하세요. 캐시된 페이지가 정상적으로 보인다는 이유만으로 네트워크가 복구됐다고 판단하지 마세요. 새 요청이 성공적으로 완료됐는지 확인해야 합니다.

스위치는 켜져 있는데 왜 연결되지 않나요?

연결 상태만으로 전체 요청 경로가 정상이라고 판단할 수 없습니다. 먼저 Home에서 선택한 서버를 확인하고 Connectivity Test를 실행하세요. 이어서 Proxy와 Config를 비교한 다음 DNS와 규칙 적용 여부를 점검하세요.

특정 웹사이트 하나만 열리지 않는데 앱을 다시 설치해야 하나요?

먼저 다시 설치하지 마세요. 다른 웹사이트와 비교한 뒤 실패한 사이트의 실제 요청 도메인, DNS 해석 결과, 규칙 및 정책을 확인하세요. 한 사이트에서만 실패한다면 대상 서비스 상태나 연결 출구의 접속 제한도 고려해야 합니다.

Wi-Fi에서는 연결되지 않지만 셀룰러 데이터에서는 정상이라면 어떻게 해야 하나요?

서버와 Config는 그대로 둔 채 Wi-Fi 웹 인증을 마치고 다시 시도하세요. Wi-Fi에서만 계속 실패한다면 연결이 실패한 단계와 전송 유형을 기록한 뒤 네트워크 관리자나 본인의 서비스 제공업체에 문의하세요.

구독을 업데이트했는데도 접속할 수 없다면 어떻게 해야 하나요?

Home에서 업데이트된 유효 항목을 선택했는지 확인하고 계정 사용량, 유효 기간, 서버 상태를 점검하세요. 구독 업데이트는 설정 데이터를 갱신할 뿐 서버 측 장애나 로컬 규칙 오류를 자동으로 해결하지 않습니다.

문의 전에 다음 네 가지 정보를 기록하세요

접속 네트워크 기록: Wi-Fi 또는 셀룰러 데이터, 그리고 네트워크를 바꾼 뒤 달라진 점.
Global Routing 모드와 Config 이름, Proxy와 Config 비교 결과를 기록하세요.
오류가 발생한 단계 기록: DNS, 서버 연결, TLS 핸드셰이크, 대상 응답.
민감 정보를 가린 오류 원문과 재현 절차를 보관하세요. 비밀번호, UUID, 구독 토큰 및 기타 인증 정보는 삭제하세요.

시간 초과 원인을 더 구분하려면 문제 진단의 시간 초과 안내를 확인하세요. 규칙 용어를 확인하려면 용어 해설을 참고하세요. 이 점검은 사용자가 이미 서비스 제공업체와 설정을 보유하고 있다는 전제입니다. 클라이언트 구매와 회선 서비스는 별개의 항목입니다.