2026-09-10 · 문제 해결 · 약 9분

Shadowrocket 연결은 됐는데 인터넷이 안 될 때: 서버·라우팅 모드·DNS·규칙 점검

연결은 켜졌지만 웹페이지가 열리지 않을 때 서버 상태, Global Routing 모드, DNS 설정, 규칙 적용 순서로 원인을 확인합니다.

이 글의 핵심

연결 스위치가 켜졌다는 것은 연결 기능이 시작됐다는 뜻일 뿐, 선택한 서버와 도메인 이름 확인, 접속하려는 웹사이트가 모두 정상이라는 의미는 아닙니다. 이미 보유한 서버나 구독을 Shadowrocket에 추가한 사용자를 대상으로 기본 네트워크, 서버, Global Routing, DNS, 규칙 순서로 점검합니다. 한 번에 한 가지 설정만 바꾸고, 마지막에는 원래 설정으로 되돌려 임시 테스트 상태가 평소 설정으로 남지 않도록 하세요.

1. 먼저 장애 범위를 확인하고 앱을 재설치하지 마세요

먼저 기본 네트워크 문제인지 연결을 켠 뒤 발생하는 문제인지 구분하세요. Home에서 연결을 끄고 Safari로 평소 바로 접속되는 웹사이트 두 곳을 연 다음, 연결을 켜고 같은 페이지를 다시 열어 보세요. 테스트하는 동안 같은 Wi-Fi 또는 셀룰러 네트워크를 유지하세요. 네트워크와 서버, 설정을 동시에 바꾸면 어떤 변경이 영향을 줬는지 알기 어렵습니다.

  1. 현재 설정 기록

    Home에서 선택한 서버와 Global Routing 모드를 기록하고, Config에서 현재 활성화된 설정을 확인하세요. 설정을 편집할 계획이라면 먼저 사본을 저장하세요. 기록에 비밀번호, 전체 구독 URL 또는 기타 인증 정보를 포함하지 마세요.

  2. 연결을 끄고 비교

    Home에서 연결 스위치를 끈 뒤 웹페이지를 다시 열어 보세요. 네트워크가 자동으로 다시 연결된다면 Settings → On Demand를 확인하세요. 테스트 중에는 활성화된 자동 연결 설정을 잠시 끄고, 점검이 끝나면 원래대로 복구하세요.

  3. 기본 네트워크 확인

    연결을 꺼도 일반 웹사이트에 접속할 수 없다면 먼저 Wi-Fi 로그인 인증, 셀룰러 데이터 권한, 신호 상태를 확인하세요. 공용 Wi-Fi에서 인증이 필요하다면 시스템 또는 Safari에서 로그인 절차를 먼저 완료하세요.

  4. 테스트 대상 고정

    바로 접속할 수 있다고 확인된 페이지 하나와 기존에 보유한 서버를 통해 접속해야 하는 페이지 하나를 골라 각각 성공 여부와 시간 초과 여부를 기록하세요. 한 웹사이트의 결과만으로 전체 네트워크 상태를 판단하지 마세요.

연결을 꺼도 접속에 실패한다면 먼저 기본 네트워크 문제를 해결해야 합니다. 연결을 켠 경우에만 실패한다면 이 글의 다음 항목을 확인하세요. 특정 웹사이트만 실패한다면 해당 사이트의 장애, 접속 제한 또는 규칙 차이도 고려해야 합니다. 시스템에 VPN 표시가 나타나도 원격 웹사이트에 연결됐다는 뜻은 아닙니다.

2. 서버 확인: 테스트 결과만으로 전체 연결 상태를 판단할 수 없습니다

먼저 현재 선택한 서버가 실제 요청을 처리할 수 있는지 확인하세요. Home → Connectivity Test에서 테스트를 실행한 다음 SERVER 목록에서 선택 상태를 확인합니다. 지연 시간이 표시되더라도 해당 테스트 조건에서 응답을 받았다는 뜻일 뿐, 모든 도메인과 포트, 앱 트래픽이 정상 처리된다는 보장은 없습니다.

오류 메시지는 발생한 위치와 함께 살펴보세요. 아래는 연결 로그에 나타날 수 있는 하위 수준 오류의 일부입니다. 실제 문구는 프로토콜과 실패 단계에 따라 달라질 수 있으며, 같은 오류 한 줄만으로 서비스 제공업체, DNS, 규칙 중 어느 항목에 문제가 있는지 단정할 수 없습니다.

오류: connection refused

원인: 보통 대상 주소의 해당 포트에서 연결을 거부한 경우입니다. 포트 오류, 서비스 미수신 상태 또는 접근 제어와 관련이 있을 수 있습니다.

해결: 먼저 오류가 프록시 서버와 대상 웹사이트 중 어디에서 발생했는지 확인하세요. 해당 주소의 포트를 점검한 뒤 서비스 제공업체에 포트가 수신 대기 중인지 문의하세요.

오류: i/o timeout

원인: 지정된 단계가 제한 시간 안에 완료되지 않은 상태입니다. 패킷 손실, 원격 서버 무응답 또는 전송 설정 불일치가 원인일 수 있습니다.

해결: 서버 설정은 그대로 둔 채 다른 네트워크에서 다시 테스트하세요. 한 네트워크에서만 실패한다면 해당 네트워크의 제한 여부를 확인하세요.

오류: no such host

원인: 관련 호스트 이름을 유효한 주소로 확인하지 못한 상태입니다. 먼저 서버 도메인과 웹페이지 도메인 중 어느 쪽에서 실패했는지 확인하세요.

해결: 도메인 철자가 맞는지 확인한 다음 아래 안내에 따라 DNS 기본 설정을 복원하세요. 서버 도메인 자체가 유효하지 않다면 기존 연결 설정부터 확인해야 합니다.

3. Global Routing 확인: 모드를 비교해 원인 좁히기

Global Routing은 요청을 어떤 방식으로 분기할지 결정하며, 작동하지 않는 서버를 복구하지는 않습니다. Home → Global Routing에서 현재 선택 항목을 기록한 뒤 Proxy와 Config를 잠시 비교해 보세요. 테스트가 끝나면 원래 항목으로 복구해 진단 과정에서 모든 요청 경로가 계속 바뀌지 않도록 하세요.

옵션점검 시 의미확인할 항목
Proxy일반 요청을 프록시 경로로 보내 규칙에 따른 분기 여부와 비교합니다.Home에서 선택한 서버가 올바른지, 연결 설정이 유효한지 확인합니다.
Direct프록시 서버를 거치지 않고 대상에 직접 연결합니다.현재 기본 네트워크에서 대상에 직접 접속할 수 있는지 확인합니다. 실패하더라도 서버가 작동하지 않는다는 뜻은 아닙니다.
Config현재 활성화된 설정의 규칙과 정책에 따라 요청을 처리합니다.Config에서 실제로 활성화된 파일, 규칙 순서, 정책 대상이 올바른지 확인합니다.
Scene설정된 Scene에 따라 실제 연결 방식을 결정합니다.현재 Scene의 규칙 적용 결과를 확인합니다. Scene이라는 표시만 보고 모든 요청이 프록시를 거친다고 단정하지 마세요.

결론: Proxy에서 성공하면 Config를 확인하세요

같은 네트워크와 서버, 대상에서 Proxy는 성공하지만 Config는 실패한다면 현재 설정의 규칙과 정책, DNS 차이를 먼저 확인하세요. 서버 설정 전체를 먼저 바꾸지 마세요.

On Demand는 연결을 언제 시작할지 제어하며, Global Routing의 요청 분기를 대신하지 않습니다. 연결을 꺼도 자동으로 다시 켜지는 현상이라면 Settings → On Demand를 먼저 확인하세요. 연결을 켰는데 일부 웹사이트만 실패한다면 On Demand를 반복해서 전환하기보다 모드와 해당 요청을 먼저 점검하세요.

4. DNS 확인: 서버 도메인과 대상 도메인 구분

DNS를 점검할 때는 먼저 어떤 이름을 확인하지 못했는지 파악해야 합니다. 서버 주소가 도메인이라면 연결을 시작하기 전부터 DNS 확인이 필요할 수 있습니다. 대상 웹페이지가 도메인이라면 실제 요청이 어떤 DNS 경로를 사용하는지도 관련됩니다. 서버 도메인 확인에 실패하면 서버 연결 자체가 시작되지 않을 수 있고, 대상 도메인 확인에 실패하면 일부 웹사이트만 영향을 받을 수 있습니다.

53
일반 DNS에서 주로 사용하는 포트이며 UDP 또는 TCP를 사용할 수 있습니다.
853
DNS over TLS에서 주로 사용하는 포트입니다.
443
DNS over HTTPS에서 주로 사용하는 HTTPS 포트입니다.

포트에 연결할 수 있어도 DNS 응답이 올바르다는 뜻은 아닙니다. 암호화 DNS는 DNS 서비스 주소에 접속할 수 있고 TLS 인증도 정상이어야 합니다. 도메인을 사용하는 DNS 서비스는 초기 도메인 확인이 필요할 수도 있습니다. 낯선 DNS 주소를 여러 개 설정에 한꺼번에 추가하면 변수가 늘어나므로, 그 결과만으로 문제를 찾았다고 판단할 수 없습니다.

  1. Config에서 현재 활성화된 파일을 확인하고 편집 화면을 열어 [General] 아래의 기존 dns-server 설정을 확인하세요. 먼저 원래 값을 저장하고 설정 전체를 바로 덮어쓰지 마세요.
  2. DNS를 수동으로 변경한 직후 문제가 생겼다면 먼저 이전에 정상 작동하던 설정으로 되돌리세요. 비교 테스트가 필요하다면 설정 사본에서 dns-server = system을 사용해 시스템 DNS 경로를 테스트할 수 있습니다. 이는 진단용 기본값이며 모든 네트워크에 맞는 최종 설정은 아닙니다.
  3. 테스트 설정을 저장하고 활성화한 다음 다시 연결해 새 웹페이지 요청을 보내세요. 브라우저가 기존 연결이나 캐시를 재사용할 수 있으므로 한 번 새로 고친 것만으로 새 설정이 적용됐다고 판단하기 어렵습니다.
  4. [Host]에 수동 도메인 매핑이 있다면 이전 주소를 가리키는지 확인하세요. DNS 설정을 복원해도 설정에 별도로 지정한 정적 매핑은 자동으로 삭제되지 않습니다.

5. 규칙 확인: 첫 번째 일치 항목부터 FINAL까지

Config 모드에서는 파일이 존재하는지만 볼 것이 아니라 실제로 활성화된 규칙을 확인해야 합니다. 규칙은 보통 위에서 아래 순서로 적용되므로 앞쪽의 포괄적인 규칙이 뒤에 있는 구체적인 규칙보다 먼저 적용될 수 있습니다. 먼저 Config에서 활성 파일을 확인한 다음 [Rule]에서 접속에 실패한 도메인 관련 항목과 최종 정책을 점검하세요.

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

이 코드는 문법을 설명하는 예시이며, 일상적인 설정을 그대로 대체할 수 있는 완성된 구성은 아닙니다. example.com은 예시 도메인이고 PROXY에는 실제로 사용할 수 있는 프록시 정책이 필요합니다. 설정 파일에서 이름이 지정된 정책을 사용한다면 Home 목록만 확인하지 말고 그 정책에서 실제로 선택된 서버를 점검하세요.

규칙을 수정할 때는 한 번에 한 곳만 변경하고 같은 대상으로 다시 테스트하세요. Proxy 모드에서도 실패한다면 FINAL을 프록시로 바꾸는 것만으로 서버 인증 오류를 해결할 수 없습니다. Config 모드에서만 실패한다면 적용된 규칙과 해당 정책을 먼저 확인하세요. 테스트가 끝나면 유지할 필요가 없는 임시 규칙을 되돌리세요.

6. 자주 묻는 질문과 점검 마무리

점검을 마칠 때는 인증 정보가 포함된 설정 전체를 공유하기보다 재현 가능한 증상을 기록하세요. 네트워크 종류, 서버 프로토콜, Global Routing 모드, 실패한 대상, 오류가 발생한 단계를 기록하면 단순히 “스위치가 켜져 있다”는 정보보다 원인을 파악하는 데 도움이 됩니다. 서비스 제공업체에 문의할 때는 비밀번호, UUID, 개인 키, 구독 토큰을 먼저 삭제하세요.

Connectivity Test에 지연 시간이 표시되는데 Safari에서 페이지가 열리지 않는 이유는 무엇인가요?

테스트 대상과 웹페이지 대상이 다를 수 있고, 규칙과 DNS 경로도 다를 수 있습니다. Home에서 같은 서버를 유지한 상태로 Global Routing → Proxy를 먼저 비교한 다음 Config로 돌아가 대상 도메인과 관련된 규칙을 확인하세요. 지연 시간 하나만 보고 전체 트래픽이 정상이라고 판단하지 마세요.

구독 업데이트에 성공하면 서버도 정상인 건가요?

아닙니다. Home에서 구독 업데이트에 성공했다는 것은 구독 정보를 가져왔다는 뜻일 뿐입니다. 업데이트 후 현재 선택한 서버가 여전히 유효한지 확인하고 Connectivity Test를 실행하세요. 서버 설정값이 변경됐다면 서비스 제공업체에 새 설정을 문의하세요. 구독 URL을 서버 주소로 입력하지 마세요.

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

같은 서버와 Global Routing 설정을 유지한 채 두 네트워크를 각각 테스트하세요. 먼저 Wi-Fi 인증을 완료하고 해당 네트워크의 DNS와 접속 제한을 확인합니다. 같은 설정이 해당 Wi-Fi에서만 실패한다면 설정과 인증 정보를 동시에 다시 작성하기보다 네트워크 간 차이부터 확인하세요.

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

원인을 찾는 비교 결과로 활용할 수는 있지만, 본인의 트래픽 분기 방식에 적합한지 확인해야 합니다. Config로 돌아가 실패한 도메인과 정책 대상, FINAL을 점검하세요. 규칙에 따른 분기가 필요하다면 설정을 수정한 뒤 Config로 복구하고, 임시 비교 결과를 최종 설정으로 그대로 사용하지 마세요.

App Store에서 보기