2026-11-06 · 문제 해결 · 약 10분

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

서버 연결 및 지연 시간, Global Routing 모드, DNS 설정, REJECT 또는 DIRECT로 트래픽을 보내는 규칙을 차례로 확인하세요.

이 글의 핵심

Shadowrocket의 연결 스위치를 켰다는 것은 기기에서 로컬 연결 절차가 시작됐다는 뜻일 뿐, 서버와 도메인 이름 확인, 트래픽 라우팅 규칙이 모두 정상이라는 뜻은 아닙니다. 직접 이용 중인 서비스와 구독이 있지만 연결 후에도 웹페이지가 열리지 않는다면, 서버 → Global Routing → DNS → 규칙 순서로 원인을 좁혀 보세요. 같은 대상을 반복해서 테스트하면 여러 설정을 한꺼번에 바꿔 원인을 놓치는 일을 줄일 수 있습니다.

먼저 테스트 조건을 고정해 로컬 네트워크 문제와 프록시 문제를 구분하세요

시스템에 VPN 상태가 표시되더라도 원격 서버 인증이 완료됐거나 대상 웹사이트에 접속할 수 있다는 뜻은 아닙니다. Shadowrocket은 먼저 기기에 네트워크 터널을 만들고, 요청이 발생하면 서버에 연결할 수 있습니다. 따라서 서버 주소에 도달하지 못해도 연결 스위치는 켜진 상태로 남을 수 있습니다. 문제를 확인할 때는 스위치를 반복해서 전환하지 말고 실제 요청 결과를 살펴보세요.

평소 직접 접속할 수 있는 웹페이지 하나와 현재 열리지 않는 대상 하나를 고르세요. 브라우저에서 두 페이지를 새로 요청한 뒤 실패 시각, 사용 중인 네트워크, 선택한 서버를 기록합니다. 이미 열어 둔 탭이나 앱의 첫 화면만으로 판단하지 마세요. 캐시된 콘텐츠가 인터넷이 끊긴 상태에서도 표시될 수 있습니다. 아래 절차는 iPhone / iPad의 메뉴 이름을 기준으로 하며, 다른 플랫폼에서는 같은 이름의 설정을 확인하세요.

  1. 기본 네트워크 확인

    Home에서 연결을 끈 다음 평소 직접 접속할 수 있는 웹페이지를 열어 보세요. 여전히 열리지 않는다면 먼저 Wi-Fi 로그인 인증을 마치고, 셀룰러 데이터 권한을 확인하거나 라우터의 인터넷 연결을 복구하세요. 이 상태에서는 트래픽 라우팅 규칙을 바꿔도 기본 네트워크 연결 문제가 해결되지 않습니다.

  2. 테스트 대상 고정

    같은 대상 도메인, 현재 사용 중인 Wi-Fi 또는 셀룰러 네트워크, Home에서 선택한 서버를 기록하세요. 이후에는 한 번에 한 항목만 바꾸고 같은 대상을 다시 요청합니다. 서로 다른 웹사이트의 결과로 비교하지 마세요.

  3. 자동 연결 일시 중지

    Settings → On Demand로 이동해 기존 상태를 기록한 다음 자동 연결을 잠시 끄세요. 이렇게 하면 수동으로 연결을 끊었을 때 시스템이 즉시 다시 연결하지 않습니다. 테스트가 끝나면 원래 설정으로 복원하세요.

  4. 기존 설정 보존

    변경하기 전에 Global Routing, 현재 Config, 사용자 지정 DNS를 기록하세요. 규칙을 편집해야 한다면 설정 사본을 먼저 보관해 진단용 임시 설정이 일상 설정으로 남지 않도록 하세요.

첫 번째: 서버에 연결해 실제 요청을 처리할 수 있는지 확인

Home에서 선택된 항목을 확인하세요. 구독 그룹 이름만 보지 마세요. Connectivity Test를 실행한 뒤 결과가 지연 시간 값인지 시간 초과인지 구분하고, 브라우저에서 실제 요청도 확인합니다. 테스트 방식과 대상에 따라 결과가 달라질 수 있습니다. 지연 시간이 표시되더라도 연결 과정 일부만 성공했을 수 있으며, 계정 인증, TLS 핸드셰이크, 대상 웹사이트 접속까지 모두 성공했다는 뜻은 아닙니다.

직접 이용 중인 구독이 있다면 업데이트 후 서버 주소, 포트, 선택된 항목을 다시 확인하세요. 이전 항목이 목록에 남아 있어도 여전히 유효하다는 보장은 없습니다. 수동으로 추가한 항목은 프로토콜과 인증 정보를 하나씩 확인하세요. 예를 들어 Trojan의 비밀번호와 TLS 매개변수, VLESS의 UUID, Shadowsocks의 암호화 방식과 비밀번호는 서로 바꿔 쓸 수 없습니다. 포트는 본인 설정을 기준으로 하며, TLS를 사용한다고 모두 443으로 바꾸면 안 됩니다.

오류: connection timed out

원인: 제한 시간 안에 필요한 응답을 받지 못한 상태입니다. 서버에 연결할 수 없거나, 네트워크에서 패킷이 손실되거나, 네트워크 필터링이 적용됐을 수 있습니다. 시간 초과만으로 비밀번호 오류라고 단정할 수는 없습니다.

해결 방법: 먼저 서버 주소와 포트를 확인한 다음 같은 항목으로 네트워크를 바꿔 재테스트하세요. 해당 항목에서만 계속 시간 초과가 발생한다면 서비스 제공업체에 서버 상태를 문의하세요.

오류: connection refused

원인: 대상 포트가 연결을 수락하지 않았습니다. 포트 입력 오류, 서비스 미실행 또는 중간 장비의 능동적인 거부가 원인일 수 있습니다.

해결 방법: 기존 설정을 기준으로 포트와 프로토콜을 확인하세요. 명확한 포트 연결 거부 문제를 DNS 변경으로 해결하려고 하지 마세요.

위 내용은 네트워크 로그에서 자주 볼 수 있는 오류 원문 예시이며, 실패할 때마다 고정된 팝업으로 표시되는 것은 아닙니다. 오류를 기록할 때는 발생 시각과 대상도 함께 남기세요. 진단 자료를 외부에 전달하기 전에는 구독 token, 비밀번호, UUID 및 기타 인증 정보를 가리세요.

두 번째: Global Routing 모드가 테스트 목적에 맞는지 확인

Home → Global Routing에서 현재 모드를 확인하세요. 모드는 요청을 어떤 경로로 처리할지 결정하며, 연결 스위치가 켜져 있는지와는 별개의 설정입니다. 규칙을 살펴보기 전에 모드부터 확인하세요. Direct 모드라면 연결 스위치가 켜져 있어도 일반 요청이 현재 프록시 서버를 통해 전달되지는 않습니다.

4개 항목
Global Routing：Config / Proxy / Direct / Scene
53
일반 DNS에서 흔히 사용하는 포트로, UDP와 TCP 모두 사용 가능
443
HTTPS에서 흔히 사용하는 포트. 포트에 연결된다고 웹페이지 요청까지 성공하는 것은 아닙니다.
모드처리 방식문제 해결 시 용도
Config현재 Config의 규칙에 따라 정책을 선택합니다.일상적인 트래픽 라우팅이 올바른지 확인할 때 사용합니다. 현재 사용 중인 Config도 함께 확인해야 합니다.
Proxy일반 트래픽을 현재 프록시 경로로 보냅니다.일반 트래픽 라우팅 규칙의 영향을 줄이면서 Config와 임시로 비교합니다.
Direct직접 연결 경로를 사용합니다.프록시 경로와 비교할 때 사용합니다. 이 모드만으로 원격 프록시 서버가 작동한다고 판단할 수는 없습니다.
SceneConfig에 설정된 Scene 조건에 따라 실제 처리 방식을 결정합니다.현재 네트워크에서 어떤 Scene이 적용됐는지 확인하세요. Scene이라는 이름만으로 트래픽의 외부 연결 경로를 판단하지 마세요.

기존 모드를 기록한 다음 잠시 Proxy로 전환해 같은 서버로 같은 대상에 접속하고, 다시 Config로 돌아와 재시도하세요. Proxy에서는 접속되지만 Config에서는 실패한다면 Config의 규칙과 정책 선택을 우선 확인합니다. 두 모드 모두 실패한다면 원인을 규칙만으로 단정할 수 없습니다. Proxy 비교만으로 모든 네트워크 설정이 완전히 분리되는 것도 아닙니다. DNS, 서버 매개변수, 기본 연결 경로가 함께 영향을 줄 수 있습니다.

정리: 모드를 비교해 원인 범위를 좁히세요

같은 네트워크, 서버, 대상으로 Proxy에서는 접속되고 Config에서는 실패한다면 성공한 서버 매개변수는 그대로 두고 Config의 일치 규칙과 정책 경로를 확인하세요. 프로토콜과 DNS를 동시에 바꾸지 마세요.

세 번째: DNS 오류가 어느 단계의 이름 확인에서 발생하는지 확인

웹페이지 요청은 보통 도메인 이름을 주소로 확인한 뒤 연결을 시작합니다. DNS 시간 초과로 연결에 사용할 대상 주소를 얻지 못할 수 있습니다. 서버 도메인도 먼저 확인해야 할 수 있으므로, 프록시 서버 도메인을 확인하지 못하는지 웹사이트 도메인을 확인하지 못하는지 구분하세요. 이후 점검 방향이 달라집니다.

Settings → DNS에서 현재 설정을 확인하고, Config에 DNS에 영향을 주는 설정이 있는지도 살펴보세요. 화면의 옵션 하나만 바꿨다고 모든 요청이 해당 리졸버를 사용한다고 단정하지 마세요. 앱 자체의 암호화 DNS, 기존 캐시, 서로 다른 이름 확인 경로 때문에 실제 결과가 예상과 다를 수 있습니다.

  1. 오류가 발생한 대상을 확인하세요. 로그에서 이름을 확인할 수 없었던 호스트를 기록합니다. 서버 호스트 이름 확인에 실패했다면 먼저 이 문제를 해결해야 합니다. 대상 웹사이트를 바꿔 서버가 정상인지 확인할 수는 없습니다.
  2. 최근 변경 사항을 되돌리세요. DNS를 직접 입력한 뒤 문제가 시작됐다면 기존 값을 기록하고 해당 변경을 되돌려 다시 테스트하세요. 출처를 알 수 없는 리졸버 주소를 여러 개 한꺼번에 추가하면 원인을 판단하기 어려워집니다.
  3. 리졸버 연결 가능 여부를 확인하세요. 일반 DNS는 보통 53번 포트를 사용합니다. 암호화 DNS를 사용한다면 해당 서버에 연결할 수 있고 인증서 검증도 정상인지 확인해야 합니다. 암호화됐다고 해서 항상 연결 가능한 것은 아닙니다.
  4. 요청을 새로 시작하세요. 설정을 저장한 다음 연결을 끊었다가 다시 연결하고, 대상 페이지도 닫았다가 다시 여세요. 캐시가 영향을 주는 것 같다면 관련 앱을 재시작해 재테스트하세요. 이전 페이지에 표시된 내용을 새로운 이름 확인 결과로 간주하지 마세요.
  5. 주소 체계를 구분하세요. 일부 네트워크에서만 실패한다면 IPv6 경로와 관련이 있는지 확인하세요. 임시 비교로 원인을 좁힐 수 있지만 변경 사항을 기록해야 합니다. IPv6 비활성화를 모든 문제의 고정 해결책으로 삼지 마세요.

오류: No such host is known

원인: Windows에서 나타날 수 있는 호스트 이름 확인 오류입니다. 현재 이름 확인 과정에서 사용할 수 있는 결과를 얻지 못했다는 뜻이며, 원격 포트가 열려 있는지는 판단할 수 없습니다.

해결 방법: 먼저 호스트 이름의 철자를 확인한 뒤 사용 중인 네트워크와 DNS 설정을 살펴보세요. 본인 서버의 도메인이라면 서비스 제공업체에 현재 유효한 도메인인지 확인하세요.

네 번째: 규칙이 REJECT 또는 DIRECT와 일치하는지 확인

Home → Global Routing → Config로 돌아간 다음 Config에서 현재 활성화된 설정을 확인하세요. 일반 규칙은 순서대로 검사하며, 먼저 일치한 규칙이 이후 처리를 결정합니다. 앞선 규칙이 하나도 일치하지 않을 때만 FINAL로 넘어갑니다. 구독 서버 업데이트와 규칙 설정 업데이트는 별개입니다. 서버 목록을 업데이트해도 현재 규칙이 바뀌는 것은 아닙니다.

아래 예시는 규칙의 구조만 보여 줍니다. example.com과 문서용 주소 대역을 사용하므로 그대로 적용할 수 있는 설정이 아닙니다. 여기서 PROXY는 프록시 정책을 뜻합니다. 실제 설정에 해당 정책 이름과 대상이 모두 존재하는지 확인해야 합니다.

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

일부 웹사이트만 열리지 않는다면 해당 요청의 도메인, 일치한 규칙, 최종 정책을 확인하세요. 웹페이지는 기본 도메인뿐 아니라 로그인, 스크립트, 이미지 도메인에도 접속하는 경우가 많습니다. 첫 화면은 표시되는데 로그인이 실패한다면 필요한 도메인 중 하나만 차단됐을 수 있습니다. 실패한 요청에 맞춰 규칙을 수정하고, 특정 리소스 하나 때문에 필터 규칙 전체를 삭제하지 마세요.

DIRECT는 오류가 아니라 직접 연결을 뜻합니다. 현재 네트워크에서 대상에 직접 접속할 수 없다면 DIRECT와 일치한 요청이 실패할 수 있습니다. 마찬가지로 규칙이 프록시 정책을 선택했더라도 해당 정책이 실제로 연결하는 서버가 사용 가능한지 확인해야 합니다. PROXY라는 문구만 확인하고 점검을 끝내지 마세요.

정리: 실제로 일치한 단계만 수정하세요

로그에서 대상이 REJECT된 것으로 나오면 해당 규칙과 순서를 먼저 확인하세요. DIRECT 경로에서 시간 초과가 발생한다면 원래 프록시를 사용해야 하는 요청인지 확인합니다. 이미 프록시로 연결했는데 실패한다면 서버와 DNS를 다시 점검하고, 관련 없는 규칙을 계속 바꾸지 마세요.

자주 묻는 질문과 복원 점검

네 가지 점검이 끝나면 진단용 임시 변경 사항을 근거가 명확한 설정으로 되돌리세요. 특히 Proxy, On Demand, 임시 DNS는 테스트가 성공했다는 이유만으로 원래 사용 목적을 무시해서는 안 됩니다. 다음 질문으로 자동 재연결, 규칙 적용, 네트워크 차이를 놓치지 않았는지 확인하세요.

연결 스위치를 껐는데 왜 다시 켜지나요?

먼저 Settings → On Demand가 활성화돼 있는지 확인하세요. 기존 상태를 기록한 뒤 잠시 끄고 수동으로 연결을 해제해 다시 테스트합니다. 기기에 다른 자동 연결 관리 설정이 없는지도 확인하세요. 점검을 마친 뒤 원래 필요에 맞게 복원합니다.

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

지연 시간 테스트는 전체 요청을 대신하지 못합니다. 해당 서버를 그대로 두고 웹페이지 요청에서 이름 확인이 완료되는지, TLS 또는 인증 단계에서 실패하는지 살펴본 뒤 Proxy와 Config를 비교하세요. 지연 시간 수치만 보고 서버 항목을 반복해서 바꾸지 마세요.

Proxy로 바꾸니 해결됐는데 계속 사용해도 되나요?

Config의 트래픽 경로를 우선 점검해야 한다는 뜻이지, 모든 요청을 계속 프록시로 보내는 것이 적합하다는 뜻은 아닙니다. Config로 돌아가 실패한 대상에 일치한 규칙, FINAL의 처리 경로, 정책에서 실제 선택된 서버를 확인하세요.

Wi-Fi에서는 안 되고 셀룰러에서는 되는데, 무엇부터 바꾸면 되나요?

서버 매개변수는 그대로 두고 Wi-Fi 로그인이 완료됐는지 먼저 확인한 뒤 해당 네트워크의 DNS, 외부 연결 제한, UDP 사용 조건을 점검하세요. 같은 설정으로 네트워크를 바꿔 성공했다면 네트워크 차이를 찾는 데 도움이 되는 근거입니다. 앱을 반드시 재설치해야 한다는 뜻은 아닙니다.

Shadowrocket 다운로드