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

이 글의 핵심

Shadowrocket의 연결 스위치를 켜면 기기의 연결 기능이 시작되지만, 원격 서버와 DNS, 접속하려는 웹사이트까지 모두 정상이라는 뜻은 아닙니다. 이미 서비스 제공업체와 설정을 갖고 있지만 연결 후 접속할 수 없는 사용자를 위해, 먼저 테스트 조건을 고정한 다음 서버, Global Routing, DNS, 규칙을 차례로 확인합니다. 매번 변수 하나만 바꾸고 같은 대상으로 재검사한 뒤 결과를 기록하세요.

문제 해결 전: 로컬 연결과 원격 접속 가능 여부 구분하기

상태 막대에 VPN이 표시되어도 프록시 서버 인증이 완료되었거나 웹 요청이 예상한 경로로 전달되었다고 단정할 수는 없습니다. 웹페이지에 접속하려면 도메인 확인, 경로 선택, 원격 연결, 웹사이트 응답이 모두 필요합니다. 어느 한 단계라도 실패하면 브라우저가 계속 기다리는 것처럼 보일 수 있습니다. 따라서 처음 시간 초과가 발생했을 때 구독을 새로 고치고 DNS를 바꾸고 Config까지 다시 작성하지 마세요. 어떤 변경이 효과가 있었는지 판단하기 어려워집니다.

평소 정상적으로 열리는 일반 HTTPS 페이지 하나를 비교 대상으로 정하고, 현재 접속에 실패하는 페이지도 준비하세요. 테스트할 때는 전체 도메인, Wi-Fi 또는 셀룰러 네트워크 여부, 선택한 서버, Global Routing 모드를 기록합니다. 이 글은 연결 서비스를 제공하지 않습니다. 아래 절차는 사용자가 이미 보유한 서버나 구독을 전제로 합니다.

연결을 끈 상태에서도 접속되지 않는 경우: 먼저 기기의 기본 네트워크를 확인하세요. 로그인이 필요한 Wi-Fi라면 프록시를 테스트하기 전에 네트워크 로그인을 완료해야 합니다.
연결을 끄면 정상이고 켜면 모두 실패하는 경우: 서버 연결 가능 여부, 인증 정보, 현재 라우팅 모드를 우선 확인하세요.
일부 도메인만 접속되지 않는 경우: 해당 도메인을 기록해 두고 DNS 결과와 요청에 적용된 규칙을 집중적으로 확인하세요.
스위치를 끈 뒤에도 자동으로 다시 켜지는 경우: Settings → On Demand를 확인하세요. 문제를 살펴보는 동안 On Demand를 잠시 끄고, 테스트가 끝나면 원래 설정으로 되돌리면 자동 연결이 비교를 방해하지 않습니다.

1단계: 서버 연결과 연결 매개변수 확인

Home에서 실제 선택된 서버를 확인한 다음 Home의 Connectivity Test로 연결을 테스트하세요. 테스트 결과는 해당 테스트 대상과 방식에서의 연결 가능 여부만 보여 줍니다. 지연 시간이 표시되어도 모든 웹사이트에 접속할 수 있다는 뜻은 아니며, 시간 초과가 계정 만료를 의미하는 것도 아닙니다. 테스트 결과와 실제 웹 요청을 함께 살펴보세요. 특히 지연 시간만으로 인증, TLS, 서비스 접속이 모두 성공했다고 판단해서는 안 됩니다.

선택된 항목 확인

Home을 열어 현재 선택된 서버 이름을 확인하세요. 해당 항목의 편집 화면에서 주소, 포트, 프로토콜, 인증 정보가 서비스 제공업체가 안내한 내용과 일치하는지 살펴보세요. 설명이 비슷한 항목이라도 주소가 다를 수 있으므로 표시 이름만 보고 판단하지 마세요.
테스트 실행

Home에서 Connectivity Test를 실행해 선택한 서버의 결과를 기록한 다음, 정해 둔 테스트 페이지를 여세요. ‘테스트에는 응답이 있지만 웹페이지는 실패’와 ‘테스트와 웹페이지 모두 실패’를 구분해 기록하세요. 다음에 확인할 항목이 달라집니다.
네트워크 전환

서버와 설정은 그대로 둔 채 Wi-Fi와 셀룰러 네트워크를 바꿔 다시 테스트하세요. 한쪽 네트워크에서만 실패한다면 모든 프로토콜 매개변수를 바로 바꾸기보다 해당 네트워크의 로그인 인증, 외부 연결 제한, UDP 연결 가능 여부를 먼저 확인하세요.
기존 설정 확인

서비스 제공업체가 주소나 인증 정보 변경을 알렸다면 기존 구독을 업데이트한 뒤 서버를 다시 선택하세요. 업데이트가 성공했는지도 확인해야 합니다. 구독 업데이트 실패와 기존 서버 연결 실패는 별개의 문제이므로 설정을 반복해서 삭제하는 대신 각각 확인하세요.

프로토콜마다 필요한 항목이 다릅니다. Shadowsocks는 암호화 방식과 비밀번호가 일치해야 합니다. VMess와 VLESS는 사용자 정보와 전송 설정이 서버와 일치해야 하며, Trojan도 비밀번호와 TLS 설정이 맞아야 합니다. Hysteria2와 WireGuard를 사용할 때는 현재 네트워크에서 UDP를 지원하는지도 확인하세요. 연결 하나가 실패했다고 프로토콜 이름을 임의로 바꾸지 마세요. 서버가 해당 설정을 지원해야 합니다.

오류: connection refused

원인: 대상 서버나 중간 장비가 연결을 명시적으로 거부한 상태입니다. 해당 포트에서 서비스가 수신 중이 아니거나 접근이 차단된 경우에 흔히 발생합니다.

해결: 서버 주소, 포트, 전송 유형을 확인하세요. 기존 설정과 일치한다면 해당 서버 접속 지점이 아직 운영 중인지 서비스 제공업체에 문의하세요. 근거 없이 기기의 DNS를 바꾸지 마세요.

오류: i/o timeout

원인: 네트워크 읽기 또는 쓰기 과정 중 한 단계에서 대기 시간이 초과된 상태입니다. 로컬 네트워크, 원격 서버 연결 가능 여부, 프로토콜 핸드셰이크 등이 원인일 수 있으며, 이 메시지만으로는 문제가 발생한 위치를 특정할 수 없습니다.

해결: 오류 전후의 맥락을 보관하고, 같은 서버를 사용해 네트워크를 바꿔 재검사한 뒤 실패한 단계를 기준으로 살펴보세요. 시간 초과를 곧바로 비밀번호 오류라고 단정하지 마세요.

오류: no such host

원인: 현재 이름 확인 과정에서 해당 호스트의 주소를 얻지 못했습니다. 오류에 표시된 호스트가 서버 도메인인지, 접속하려는 웹사이트 도메인인지 먼저 확인해야 합니다.

해결: 도메인 철자와 DNS 연결 가능 여부를 확인하세요. 서버 도메인을 확인하지 못했다면 먼저 기본 도메인 확인 문제를 해결해야 합니다. 아직 연결되지 않은 프록시를 통해 필요한 선행 작업을 모두 처리할 수는 없습니다.

위 내용은 네트워크 오류에 자주 표시되는 문구입니다. 실제 오류에는 주소, 포트 또는 더 자세한 시스템 안내가 포함될 수 있으므로 전체 오류 맥락을 기준으로 확인하세요. 인증서 검증 오류가 발생하면 기기 날짜, 서버 도메인, TLS 설정을 살펴보세요. 인증서 검증을 끄는 방법을 일반적인 해결책으로 사용하지 마세요.

2단계: Global Routing으로 프록시와 규칙 문제 구분하기

Home → Global Routing으로 이동해 현재 모드를 먼저 기록하세요. Proxy, Direct, Config, Scene은 연결 품질을 나타내는 등급이 아니라 서로 다른 라우팅 방식입니다. Proxy는 프록시 경로를 확인할 때, Direct는 직접 연결 경로를 확인할 때 사용합니다. Config는 현재 설정의 규칙에 따라 처리하고, Scene은 설정된 장면에 따라 작동합니다. 문제를 확인할 때 Scene 모드에서 결과를 추측하지 마세요. 현재 적용 중인 장면과 설정을 확인하거나, 비교하기 쉬운 모드로 잠시 전환하세요.

테스트 모드	결과	다음 단계
Proxy	같은 웹페이지에 계속 접속할 수 없음	규칙을 다시 작성하기보다 서버, DNS 또는 웹사이트 자체를 계속 확인하세요.
Direct	일반 웹페이지는 정상, Proxy에서는 실패	프록시 경로를 집중적으로 확인하세요. 직접 연결이 성공해도 서버가 정상이라는 뜻은 아닙니다.
Config	Proxy는 정상, Config에서는 실패	현재 적용 중인 설정, 규칙 순서, 요청에 최종 적용된 정책을 확인하세요.
Scene	네트워크를 바꾸면 결과가 달라짐	Scene에서 실제로 선택한 라우팅 설정을 확인하고, 모드를 고정한 뒤 다시 테스트하세요.

정리: Proxy 성공 여부를 확인한 다음 Config 점검

같은 네트워크, 같은 서버, 같은 웹페이지가 Proxy에서는 열리지만 Config에서는 실패한다면 서버 설정은 그대로 두고 현재 설정과 요청 기록을 확인하세요. 이렇게 하면 규칙 문제를 서버 장애로 잘못 처리하는 일을 줄일 수 있습니다.

모드를 바꿀 때마다 웹페이지 요청을 새로 보내세요. 필요하다면 연결을 끊었다가 다시 연결해 기존 연결 재사용의 영향을 줄일 수 있습니다. 테스트가 끝나면 평소 사용하는 모드로 되돌리세요. Proxy는 비교를 위한 도구일 뿐, 웹페이지가 열리지 않는 모든 문제의 최종 설정은 아닙니다.

3단계: DNS 실패와 이후 연결 실패 구분하기

DNS는 도메인을 주소로 변환합니다. 주소 확인이 끝나지 않으면 보통 다음 연결 단계로 넘어갈 수 없습니다. 하지만 주소를 얻었다고 해서 해당 주소에 연결할 수 있거나 인증서가 유효하다는 뜻은 아닙니다. Settings에서 DNS 설정을 열고 현재 값을 먼저 기록하세요. 시스템 DNS, 사용자 지정 DNS, DNS over HTTPS 중 무엇을 사용 중인지 확인한 다음 현재 설정을 항목별로 점검하세요.

일반 DNS가 주로 사용하는 서비스 포트입니다. UDP 또는 TCP를 사용할 수 있습니다.

443

HTTPS의 기본 포트이며, DNS over HTTPS는 보통 HTTPS를 통해 전송됩니다.

항목

매 테스트마다 설정을 하나씩만 바꾸고 같은 도메인으로 다시 확인하세요.

이 포트는 프로토콜에서 흔히 사용하는 기본값입니다. 자신의 서버 포트를 53이나 443으로 바꾸라는 뜻은 아닙니다. 사용자 지정 DNS를 쓰려면 기기에서 지정한 DNS 서버에 연결할 수 있어야 합니다. DNS over HTTPS도 해당 HTTPS 서비스에 연결할 수 있어야 합니다. DNS 서비스 자체가 도메인을 사용한다면 그 도메인을 먼저 확인해야 할 수도 있습니다. 암호화 DNS로 바꾸기만 하면 모든 선행 연결 문제가 자동으로 해결된다고 볼 수는 없습니다.

모든 도메인을 확인할 수 없는 경우: DNS 주소를 올바르게 입력했는지 확인하고, 변경 전 설정을 복구해 비교하세요. 기기의 기본 네트워크도 정상인지 확인해야 합니다.
도메인 하나만 실패하는 경우: 도메인 철자가 맞는지, 특정 하위 도메인에서만 문제가 발생하는지 확인하고 구체적인 조회 결과를 기록하세요. 곧바로 전체 DNS 설정을 바꾸지 마세요.
주소를 얻은 뒤 연결 시간이 초과되는 경우: 해당 주소에 적용되는 경로와 원격 연결을 계속 확인하세요. 이제는 단순히 ‘주소 확인에 성공했는지’만의 문제가 아닙니다.
설정을 바꿔도 달라진 것 같지 않은 경우: 설정을 저장하고 연결을 새로 만든 뒤 요청을 다시 보내세요. 기존 연결이나 앱 캐시가 이전 결과를 계속 사용할 수 있습니다.

4단계: Config와 실제 적용 규칙 확인

서버와 DNS가 기본적으로 정상인지 확인한 다음 Config에서 현재 실제로 적용 중인 설정을 살펴보세요. 파일을 편집했다고 해서 연결에 그 파일이 적용되고 있다는 뜻은 아닙니다. 먼저 선택된 설정을 확인한 뒤 [Rule]의 순서를 살펴보세요. 규칙은 보통 위에서 아래로 확인하며, 일치하는 규칙을 찾으면 해당 정책이 적용됩니다. FINAL은 구체적인 규칙 뒤에 배치해야 합니다.

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

이 최소 예시는 example.com과 그 하위 도메인의 요청을 PROXY로 보내고 나머지 요청은 DIRECT로 처리합니다. 규칙 매칭 방식을 설명하기 위한 예시일 뿐, 모든 사용자에게 적합한 완성형 설정이 아니며 사용할 수 있는 서버를 만들어 주지도 않습니다. 대상 페이지에서 다른 도메인에도 요청을 보내면 그 요청은 첫 번째 규칙과 일치하지 않을 수 있습니다. 메인 페이지는 열리지만 이미지, 로그인 또는 API 요청이 실패한다면 주소창의 기본 도메인만 볼 것이 아니라 실제 실패한 요청을 확인하세요.

DOMAIN-SUFFIX: 도메인 자체와 하위 도메인을 일치시킵니다. 임의의 문자열이 포함되는지를 검사하는 규칙은 아닙니다. 실제 요청 도메인이 지정한 접미사에 해당하는지 먼저 확인하세요.
IP-CIDR: 주소 대역을 기준으로 일치시킵니다. 예: IP-CIDR,192.168.0.0/16,DIRECT. 도메인 접미사가 아니라 IP 주소 조건입니다.
GEOIP: 주소의 지리 정보 데이터베이스상 위치를 기준으로 일치시킵니다. 예: GEOIP,CN,DIRECT. 결과는 확인된 주소와 데이터베이스에 따라 달라지므로 웹사이트 콘텐츠의 언어나 운영 지역을 추정하는 근거로 삼을 수 없습니다.
FINAL: 앞선 규칙에 일치하지 않은 요청을 처리합니다. FINAL,DIRECT를 앞쪽에 두면 뒤에 있는 구체적인 프록시 규칙은 확인되지 않습니다.

Data에서 확인할 수 있는 요청 또는 연결 기록을 살펴보고 시간, 대상 도메인, 대상 주소, 최종 정책을 대조하세요. 실제 표시되는 항목은 현재 화면에 따라 다를 수 있습니다. 화면에서 일치한 규칙을 직접 확인할 수 없다면 같은 요청을 Proxy와 Config에서 각각 테스트한 결과를 보조 근거로 활용하세요. 대상 규칙보다 앞에 있는 규칙과 정책 그룹이 예상한 서버를 가리키는지도 확인해야 합니다.

예상과 달리 DIRECT가 적용됐다면 대상 규칙과 순서를 먼저 조정하세요. 이미 PROXY가 적용됐는데도 실패한다면 같은 규칙을 계속 추가하지 말고 서버와 대상 연결 단계를 다시 확인하세요. 규칙 하나를 바꾼 뒤 저장하고 해당 Config가 실제로 사용 중인지 확인한 다음, 다시 연결해 테스트하세요. 기록을 남기지 않은 채 설정을 한꺼번에 바꾸지 마세요.

자주 묻는 질문: 일부 웹페이지, 구독, 자동 재연결

테스트에 지연 시간이 표시되는데 브라우저가 계속 로딩되는 이유는 무엇인가요?

Connectivity Test 결과만으로 웹페이지 접속 경로 전체가 정상이라고 볼 수는 없습니다. 같은 서버를 유지한 채 Global Routing에서 Proxy를 선택하고 원래 페이지를 다시 열어 보세요. 이어서 DNS와 연결 오류를 확인하세요. 웹사이트 하나만 실패한다면 해당 사이트와 관련 도메인도 확인해야 합니다. 지연 시간만으로 모든 것이 정상이라고 판단하지 마세요.

Wi-Fi에서는 안 되는데 셀룰러 네트워크에서는 되나요?

다른 설정은 그대로 두고 네트워크에 따른 차이가 반복되는지 확인하세요. Wi-Fi 로그인이 필요한지, 대상 포트 또는 UDP를 제한하는지 살펴보세요. 네트워크가 바뀔 때 Scene이나 Settings → On Demand가 연결 동작을 변경하는지도 확인해야 합니다. 특정 네트워크에서만 발생하는 문제를 구독 만료로 바로 단정하지 마세요.

구독 새로 고침에 실패하면 모든 항목을 먼저 삭제해야 하나요?

먼저 삭제할 필요는 없습니다. 기존 설정을 보관하고 서비스 제공업체가 안내한 구독 주소가 여전히 유효한지 확인한 다음 Home에서 해당 구독을 업데이트하세요. 구독 주소에 접속할 수 있는지와 기존 서버를 사용할 수 있는지는 각각 테스트해야 합니다. 문의할 때는 링크의 token을 가려 인증 정보가 노출되지 않도록 하세요.

스위치를 끈 뒤 자동으로 다시 연결되면 어떻게 비교하나요?

Settings → On Demand로 이동해 원래 설정을 기록하고 자동 연결을 잠시 끈 다음, 연결을 끈 상태의 기본 네트워크를 테스트하세요. 점검이 끝나면 원래 설정을 복구합니다. 스위치 동작이 계속 예상과 다르다면 기기에 다른 자동 연결 관리 설정이 있는지 확인하세요. 앱을 반복해서 재설치하지 마세요.

원인을 찾기 어렵다면 최소한의 점검 기록을 정리하세요. 발생 시간, 네트워크 유형, 선택한 서버의 식별 정보(민감 정보는 가림), Global Routing 모드, Proxy와 Config 비교 결과, 실패한 도메인, DNS에서 주소를 받았는지 여부, 전체 오류 맥락을 포함하면 됩니다. 서버 상태를 서비스 제공업체에 문의할 때는 ‘스위치가 켜져 있다’는 설명보다 이런 정보가 문제 위치를 파악하는 데 도움이 됩니다.

점검을 마친 뒤 On Demand, 평소 사용하는 라우팅 모드, 유지할 설정을 복구하고 임시 테스트 규칙을 삭제하세요. 지연 테스트 한 번이나 상태 막대의 표시만 볼 것이 아니라, 실제 웹페이지 접속과 예상한 정책, 새 요청을 여러 차례 보낸 결과를 함께 확인해야 복구 여부를 판단할 수 있습니다.