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

이 글의 핵심

Shadowrocket의 스위치를 켰다는 것은 시스템 터널이 시작됐다는 뜻일 뿐, 서버 연결이나 도메인 이름 확인, 대상 웹사이트 접속까지 모두 정상이라는 의미는 아닙니다. 이미 이용 중인 서비스와 구독 정보를 보유한 사용자를 대상으로, 먼저 로컬 네트워크 상태를 확인하고 서버를 점검한 뒤 Global Routing 모드를 바꿔 한 가지 조건만 비교합니다. 마지막으로 DNS와 규칙 적용 내역을 살펴봅니다. 한 번에 한 항목만 변경하고 같은 대상의 결과를 기록하면 설정 변경을 네트워크 복구로 오인하는 일을 줄일 수 있습니다.

1. 문제 범위를 먼저 확인하고 앱 재설치는 미루세요

먼저 ‘모든 요청이 실패하는 경우’, ‘일부 도메인만 실패하는 경우’, ‘네트워크를 바꾼 뒤 실패하는 경우’를 구분하세요. 각 상황에 따라 확인할 항목이 다릅니다. 시스템에 VPN 상태가 표시되어도 원격 프록시와의 핸드셰이크가 완료됐다는 뜻은 아닙니다. Home에 테스트 지연 시간이 표시되어도 실제 웹페이지 요청을 대신할 수 없습니다.

문제 해결 중에는 현재 Config와 서버 정보를 유지하고 앱을 먼저 삭제하지 마세요. 삭제 후 다시 가져오면 설정, 캐시, 선택 상태가 한꺼번에 바뀌어 원인을 파악할 단서가 사라질 수 있습니다. On Demand 연결이 켜져 있다면 Settings → On Demand에서 잠시 중지한 뒤 수동으로 연결을 켜고 꺼 보세요. 테스트가 끝나면 원래 설정으로 되돌리세요.

네트워크 기준 상태 확인

Home에서 연결을 끈 다음 평소 직접 접속할 수 있는 HTTPS 페이지를 여세요. 페이지가 여전히 열리지 않으면 규칙 탓으로 돌리기 전에 Wi‑Fi 로그인 인증, 셀룰러 데이터 권한 또는 라우터 연결부터 확인하세요.
테스트 대상 고정

직접 연결할 대상 하나와 기존 프록시를 통해 접속해야 하는 대상 하나를 정하고, 매번 같은 도메인과 페이지를 사용하세요. 페이지가 완전히 로드되어야 해당 테스트가 성공한 것입니다. 이전에 열린 페이지가 그대로 보인다고 해서 새 요청까지 성공한 것은 아닙니다.
현재 상태 기록

Home에서 선택된 서버와 Global Routing 모드를 기록하고, Config에서 현재 활성화된 구성을 확인하세요. Wi‑Fi와 셀룰러 네트워크 중 어떤 것을 사용 중인지도 적어 두고, 이후 비교할 때 조건을 동시에 바꾸지 마세요.
요청 다시 보내기

연결을 켠 뒤 테스트 페이지를 다시 열고 새로 생성된 요청 기록을 확인하세요. 대상 도메인, 시간, 처리 정책, 오류 정보를 기록합니다. 몇 분 전에 남은 이전 기록으로 이번 테스트 결과를 판단하지 마세요.

2. 서버 점검: 터널이 시작돼도 원격 서버에 연결된 것은 아닙니다

Home에서 구독 목록에 서버가 있는지만 확인하지 말고 실제 선택된 서버를 확인하세요. 주소, 포트, 프로토콜, 인증 항목이 본인이 보유한 서비스 정보와 일치하는지 살펴보세요. 서버 주소가 도메인 이름이라면 프록시 연결을 시작하기 전에 해당 이름을 확인해야 하는 경우가 많습니다. 서버 도메인을 확인할 수 없어도 연결 불가처럼 나타날 수 있습니다.

포트 번호만으로 프로토콜을 알 수는 없습니다. 예를 들어 서버가 TCP 443을 사용하더라도 임의의 프로토콜로 해당 포트에 연결할 수 있는 것은 아닙니다. Trojan의 인증 및 TLS 매개변수, VMess 또는 VLESS의 전송 설정, Shadowsocks의 암호화 방식은 서버 설정과 일치해야 합니다. 다른 항목과 호환되지 않는 상태로 Type만 바꿔가며 시험하지 마세요.

현재 항목부터 테스트: Home에서 Connectivity Test를 실행하고, 이어서 실제 웹페이지에 한 번 접속해 보세요. 테스트 실패는 추가 점검이 필요하다는 뜻입니다. 성공하더라도 당시 해당 테스트 경로가 작동했다는 것만 확인할 수 있습니다.
같은 네트워크에서 비교: 목록에 사용할 수 있는 다른 항목이 있다면 서버만 바꾸고 Global Routing과 Config는 그대로 둔 채 테스트하세요. 항목 하나만 실패한다면 우선 해당 항목의 매개변수, 유효 상태, 원격 서비스를 확인하세요.
마지막으로 네트워크 변경: 서버는 그대로 두고 Wi‑Fi에서 셀룰러 네트워크로 바꾼 뒤 테스트를 반복하세요. 한 네트워크에서만 실패한다면 해당 네트워크의 인증 상태, 외부 연결 제한, 사용 중인 전송 방식의 연결 가능 여부를 확인하세요.
기존 구독 확인: 서비스 매개변수가 변경됐다면 본인이 이용 중인 구독을 업데이트한 뒤 항목을 다시 선택하세요. 구독 업데이트 성공은 설정 정보를 가져올 수 있다는 뜻일 뿐, 구독에 포함된 모든 서버를 현재 사용할 수 있다는 뜻은 아닙니다.

오류: `connection refused`

원인: 대상 또는 중간 장비가 연결을 명시적으로 거부했습니다. 주소, 포트, 서비스의 수신 대기 상태를 우선 확인하세요.

해결: 보유한 서비스 정보를 기준으로 포트를 확인하세요. 정보가 일치한다면 오류 발생 시간, 네트워크 유형, 오류 내용을 본인의 서비스 제공업체에 전달해 확인을 요청하세요. DNS를 계속 바꾸는 것은 해결책이 아닙니다.

오류: `i/o timeout`

원인: 네트워크의 읽기 또는 쓰기 단계가 제한 시간 안에 완료되지 않았습니다. 이 메시지만으로 서버, 전송 경로, 상위 대상 중 어디에서 문제가 생겼는지 판단할 수는 없습니다.

해결: 같은 기록 주변에 표시된 연결 대상과 진행 단계를 확인한 뒤 ‘같은 네트워크에서 서버 변경’, ‘같은 서버로 네트워크 변경’ 비교 테스트를 진행해 실패 범위를 좁히세요.

위 오류는 네트워크 로그에 나타날 수 있는 저수준 오류 원문이며, 정해진 화면 안내 문구가 아닙니다. 프로토콜마다 관련 맥락이 다를 수 있으므로 문제를 문의할 때는 앞뒤 기록을 함께 보존하고 비밀번호, 인증 정보, 구독 토큰은 가리세요.

3. Global Routing: Proxy와 Config를 비교해 연결 경로와 규칙을 구분하세요

Home → Global Routing에서 현재 모드를 확인하세요. Proxy, Direct, Config, Scene은 서로 다른 트래픽 처리 방식이지 서버의 정상 여부를 나타내는 상태가 아닙니다. 문제를 확인할 때는 원래 값을 기록하고 잠시 비교한 다음 복원하세요. 모드를 전환하면 다른 앱에서 진행 중인 요청에 영향을 줄 수 있습니다.

모드	처리 방식	이번 점검에서의 용도
Proxy	트래픽을 프록시로 처리하며 Config의 일반적인 분기 규칙에 따라 직접 연결을 선택하지 않습니다.	서버를 고정한 상태에서 프록시 경로로 실제 요청을 처리할 수 있는지 테스트합니다.
Direct	직접 연결 경로를 사용합니다.	로컬 네트워크와 대상에 직접 연결할 수 있는지 확인합니다. 프록시 서버 테스트에는 사용할 수 없습니다.
Config	현재 활성화된 구성과 규칙에 따라 처리 방식을 결정합니다.	Proxy와 비교해 규칙, 정책 또는 구성의 DNS 차이를 파악합니다.
Scene	설정된 Scene 조건에 따라 해당 라우팅 방식을 적용합니다.	실제로 적용 중인 Scene을 먼저 확인하세요. 처음 원인을 파악할 때는 조건이 바뀌지 않도록 명확한 모드로 전환하세요.

같은 서버와 대상을 사용했을 때 Proxy에서는 성공하고 Config에서는 실패한다면 현재 구성과 적용된 정책을 먼저 확인하세요. 그렇다고 해서 곧바로 ‘규칙이 잘못됐다’고 단정할 수는 없습니다. 구성에 따른 이름 확인 방식, 실제 선택된 정책 그룹, 차단 규칙 등이 차이를 만들 수 있습니다. 두 모드에서 모두 실패한다면 규칙을 더 추가하기 전에 서버 연결 가능 여부와 DNS부터 다시 점검하세요.

정리: 재현 가능한 모드 차이를 먼저 기록하세요

‘Proxy에서는 성공하고 Config에서는 실패’한다면 비교 결과를 보존하고 실패한 요청에 실제로 적용된 규칙과 출구를 확인하세요. 차이가 발생한 지점을 찾은 다음 구성을 변경하세요. 서버와 DNS를 동시에 바꾸지 마세요.

4. DNS 점검: 서버 도메인과 대상 도메인을 따로 확인하세요

한 번의 접속에는 두 종류의 이름 확인이 필요할 수 있습니다. 하나는 프록시 서버 주소를 확인하는 과정이고, 다른 하나는 대상 웹사이트 도메인을 확인하는 과정입니다. 전자가 실패하면 프록시 연결이 시작되지 않습니다. 후자가 실패하면 서버에는 연결할 수 있어도 대상 요청을 진행하지 못할 수 있습니다. 이름 확인이 로컬에서 이뤄지는지 원격에서 이뤄지는지는 프로토콜과 구성에 따라 다르므로, 웹페이지가 계속 로딩된다는 이유만으로 원인을 판단할 수는 없습니다.

대상 도메인 이름 확인 결과 규칙 판단 출구 연결 대상 응답

이 흐름은 점검 지점을 이해하기 위한 것으로, 모든 프로토콜이 같은 단계에서 이름을 확인한다는 뜻은 아닙니다. Config에서 현재 구성의 편집 화면을 열고 [General]의 dns-server 등 DNS 설정을 확인하세요. 요청 기록에 이름 확인 실패, 빈 결과 또는 비정상적인 주소가 나타나는지도 살펴보세요. 사용자 지정 DNS 서비스를 사용한다면 해당 서비스에 연결하는 네트워크 경로도 확인해야 합니다.

한 가지 설정만 변경: 먼저 구성 사본을 저장한 다음 현재 사용자 지정 DNS 설정을 일시적으로 정상 작동이 확인된 시스템 DNS 방식으로 되돌리세요. 다시 연결한 뒤 같은 도메인에 접속해 보고, Config 전체를 한꺼번에 교체하지 마세요.
주소 유형별로 확인: 기록에 A와 AAAA 결과가 있다면 최종 연결에 사용된 IPv4 또는 IPv6 주소를 각각 확인하세요. AAAA 레코드를 받았다고 해서 현재 네트워크에서 IPv6로 연결할 수 있다는 뜻은 아닙니다.
포트 의미를 정확히 파악: 기존 DNS는 보통 UDP 또는 TCP 53을 사용하고, DoH는 HTTPS를 사용하며 일반적으로 TCP 443이 관련됩니다. 포트에 연결할 수 있어도 이름 확인 요청이 성공한다고 단정할 수 없으므로 실제 응답을 확인하세요.
IP 주소로 바꿔 바로 시험하지 마세요: HTTPS 사이트는 인증서 확인과 가상 호스트 선택에 도메인 이름을 사용하는 경우가 많습니다. 주소창에 IP를 입력했을 때 접속에 실패하더라도 DNS 문제라고 단정할 수 없습니다.

5. 규칙 점검: 규칙의 존재뿐 아니라 가장 먼저 적용된 규칙을 확인하세요

Config에서 실제로 활성화된 구성을 확인한 뒤 실패한 도메인의 요청 기록을 살펴보세요. 적용된 규칙, 최종 정책, 실제 서버를 기록하는 것이 중요합니다. 규칙은 순서대로 적용되므로 먼저 일치한 요청은 뒤에 더 적절해 보이는 규칙이 있더라도 자동으로 다른 경로로 바뀌지 않습니다.

아래 내용은 규칙 순서와 문법을 설명하기 위한 예시이며, 기존 구성에 그대로 덮어쓸 수 있는 범용 설정이 아닙니다. example.com은 예시 도메인이고 192.168.0.0/16은 사설 IP 주소 범위입니다. 여기서 PROXY와 DIRECT는 규칙의 정책 키워드이며, Global Routing 메뉴에 표시되는 모드와 혼동하지 마세요.

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

DOMAIN-SUFFIX: 예시에서는 example.com과 그 하위 도메인을 일치시킵니다. 실제 페이지는 로그인, 이미지, API 도메인에도 요청할 수 있으므로 메인 페이지에 규칙이 적용됐다고 해서 모든 관련 요청에도 적용된 것은 아닙니다.
IP-CIDR: 대상 IP 주소 대역을 기준으로 일치시킵니다. 예시의 no-resolve는 이 IP 규칙에 일치시키기 위해 도메인 이름 확인을 추가로 요청하지 않는다는 뜻이지, 구성 전체의 DNS를 끈다는 뜻은 아닙니다.
GEOIP: 예를 들어 GEOIP,CN,DIRECT는 주소가 속한 지역을 기준으로 판단합니다. 결과는 IP 주소와 사용 중인 데이터베이스에 따라 달라지며, 도메인 접미사 규칙처럼 사용할 수 없습니다.
FINAL: 앞선 규칙에 일치하지 않은 요청에 적용되는 최종 처리입니다. 예시의 FINAL,DIRECT는 앞의 두 규칙에 일치하지 않는 요청을 직접 연결합니다. 대상에 프록시가 필요하다면 이 기본 처리가 의도와 맞지 않을 수 있습니다.

규칙 적용 결과가 예상과 다르면 먼저 의도한 Config가 활성화됐는지 확인한 다음 규칙 순서, 도메인 표기, 참조된 정책을 살펴보세요. 정책 그룹에 적용됐다면 그룹 안에서 실제로 선택된 서버도 확인해야 합니다. PROXY라는 글자만 보고 원하는 출구를 통해 요청이 처리됐다고 단정하지 마세요.

정리: 잘못된 트래픽 분기가 확인된 경우에만 수정하세요

실패 기록에서 대상이 잘못 직접 연결된 것이 확인되면 구성 사본에 정확한 범위의 도메인 규칙을 추가하고, 먼저 적용될 수 있는 포괄적인 규칙보다 앞에 배치하세요. 페이지와 관련 요청이 모두 정상인지 확인한 뒤 변경 사항을 유지할지 결정하세요.

6. 자주 묻는 질문: 일부 접속만 실패하는 경우, 자동 재연결, 구독 업데이트

지연 시간은 표시되는데 웹페이지가 열리지 않는 이유는 무엇인가요?

지연 시간은 특정 테스트의 결과일 뿐 모든 대상, DNS 경로, 웹페이지의 관련 요청을 확인한 값은 아닙니다. 서버를 그대로 두고 Proxy 모드에서 실제 대상에 접속한 다음, 이름 확인·연결·응답 중 어느 단계에서 실패하는지 확인하세요.

웹사이트 하나만 열리지 않아도 구성 전체를 바꿔야 하나요?

먼저 해당 웹사이트의 기본 도메인과 API 도메인 요청 기록을 확인하세요. 다른 대상은 정상이라면 해당 도메인의 규칙, 이름 확인 결과, 원격 응답을 우선 살펴보세요. HTTP 403이나 429 같은 응답은 요청이 어떤 HTTP 서비스에 도달했다는 뜻입니다. 바로 앱을 다시 설치하지 말고 응답이 어디에서 왔는지와 접근 조건을 확인하세요.

연결을 꺼도 다시 자동으로 켜집니다. 어떻게 비교 테스트하나요?

Settings → On Demand로 이동해 On Demand 연결을 잠시 끈 다음 수동으로 연결을 해제하고 테스트하세요. 기기에 관리 정책이 설정되어 있다면 해당 정책의 연결 조건도 확인하세요. 점검을 마친 뒤에는 원래 설정으로 복원해 테스트 상태가 계속 유지되지 않도록 하세요.

구독 업데이트 실패와 웹페이지 접속 실패는 같은 문제인가요?

아닙니다. 구독 업데이트는 구성 주소에 접속하고 웹페이지 요청은 대상 사이트에 접속하므로 두 경로가 다를 수 있습니다. 먼저 본인의 구독 링크가 완전하고 유효한지 확인한 뒤 해당 주소의 이름 확인과 접속 경로를 살펴보세요. 업데이트에 성공한 뒤에도 Home에서 선택된 서버를 다시 확인해야 합니다.

셀룰러 네트워크로 바꾸자 해결됐다면 Wi‑Fi 문제라고 봐도 되나요?

네트워크 조건과 관련된 문제라는 점은 알 수 있지만, 변수를 통제해 확인해야 합니다. 서버, Config, 대상을 그대로 두고 Wi‑Fi 인증을 완료했는지, 직접 연결이 되는지, 해당 네트워크가 현재 전송 방식을 허용하는지 확인하세요. 프로토콜, 서버, DNS 설정을 한꺼번에 바꾸지 마세요.

7. 설정을 복원하고 재현 가능한 기록을 정리하세요

원인을 찾은 뒤에는 Global Routing과 On Demand를 원래대로 복원하고 검증된 변경 사항만 유지하세요. 한 번 성공했다고 문제가 완전히 해결된 것은 아닙니다. 원래 실패했던 네트워크에서 요청을 다시 보내고 연결을 껐다가 다시 켠 뒤에도 결과가 일관적인지 확인하세요.

환경: 기기 유형, 네트워크 유형, 발생 시간, 연결을 끈 상태에서 직접 접속할 수 있었는지 여부.
비교 결과: 같은 대상이 Proxy와 Config에서 어떻게 달랐는지, 네트워크나 기존 서버를 바꿨을 때 결과가 달라졌는지.
근거: 실패한 요청의 도메인, 적용된 정책, 오류 원문과 앞뒤 기록. 테스트 대상이 웹페이지였는지 Connectivity Test였는지도 적으세요.
개인정보: 기록을 보내기 전에 구독 전체 주소, 토큰, 비밀번호 및 기타 인증 정보를 삭제하고 원인 확인에 필요한 정보만 남기세요.

이 기록을 활용하면 ‘스위치를 켰는데 작동하지 않는다’는 문제를 서버 연결 실패, 이름 확인 실패, 잘못된 출구 선택, 대상의 오류 응답처럼 구체적으로 구분할 수 있습니다. 반복해서 초기화하는 것보다 순서대로 확인하는 편이 근거를 보존하기 쉽고, 본인의 서비스 제공업체도 원격 상태를 확인하기 편합니다.