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

이 글의 핵심

이 글은 Shadowrocket을 설치하고 직접 준비한 서비스 제공업체의 설정이나 구독을 보유했으며, 연결 스위치를 켤 수는 있지만 접속에 실패하는 사용자를 위한 안내입니다. 연결을 끈 상태에서 기본 네트워크부터 확인한 뒤 Home의 서버, Global Routing, DNS, Config의 Rule 순서로 점검합니다. 한 번에 한 항목만 변경하고 같은 사이트를 다시 테스트해 기본 네트워크, 프록시 연결, 도메인 해석, 트래픽 분기 정책 중 어디에서 문제가 발생하는지 확인하세요. 앱을 반복해서 재설치할 필요는 없습니다.

1. VPN이 켜진 것과 사이트에 연결되는 것은 다릅니다

연결 스위치가 켜지고 시스템에 VPN이 표시된다는 것은 앱이 트래픽을 처리할 통로가 만들어졌다는 뜻입니다. 원격 서버의 인증이 완료되었거나 웹사이트에 접속할 수 있다는 의미는 아닙니다. 서버 주소를 해석하지 못하거나, 포트에 연결할 수 없거나, 인증 정보가 유효하지 않거나, Rule에서 요청을 거부하는 문제는 스위치를 켠 뒤에도 발생할 수 있습니다.

평소 접속할 수 있고 용도가 다른 웹사이트 두 곳을 테스트 대상으로 정하세요. 모든 사이트가 열리지 않는지, 특정 도메인만 열리지 않는지, 페이지는 열리지만 일부 리소스가 로드되지 않는지 기록합니다. 한 웹사이트의 문제만으로 전체 네트워크가 작동하지 않는다고 판단하지 마세요. 서버, DNS, 구성 파일을 한꺼번에 바꾸면 어떤 변경이 결과에 영향을 주었는지 알 수 없습니다.

연결 끄기

Home으로 돌아가 연결 스위치를 끈 다음 브라우저에서 정한 두 사이트에 접속합니다. 그래도 열리지 않으면 Wi-Fi 로그인, 셀룰러 데이터 권한 또는 현재 네트워크 자체의 문제부터 확인하세요.
자동 연결 일시 중지

Settings → On Demand로 이동해 기존 설정을 기록한 뒤 자동 연결을 잠시 꺼둡니다. 수동으로 연결을 끈 뒤 시스템이 다시 연결하는 일을 방지할 수 있습니다. 점검이 끝나면 원래 설정으로 되돌리세요.
테스트 조건 고정

네트워크 한 종류와 기존에 보유한 서버 하나를 선택해 고정합니다. Home → Global Routing의 현재 옵션과 Config에서 실제로 활성화된 구성 파일도 기록하세요.
연결 후 다시 테스트

연결을 다시 켜고 같은 브라우저에서 같은 사이트에 접속합니다. Wi-Fi와 셀룰러 데이터를 비교하려면 네트워크 전환만 별도의 테스트로 진행하고 다른 설정은 변경하지 마세요.

2. Home의 서버와 실제 연결 오류 확인

Home에서 현재 선택된 항목이 테스트하려는 서버인지 확인하세요. 구독 그룹 이름만 확인해서는 안 됩니다. 해당 항목의 편집 화면을 열고 보유한 서비스 제공업체 자료와 주소, 포트, 프로토콜, 인증 정보를 대조합니다. Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard는 각각 매개변수 구성이 다르므로 한 프로토콜의 항목을 다른 프로토콜에 그대로 적용할 수 없습니다.

포트는 서버 측 설정과 일치해야 합니다. TLS를 사용하는 서비스라면 서비스 제공업체가 안내한 Server Name 등의 매개변수도 확인하세요. 인증서 검증을 꺼서 오류를 감추지 마세요. 기기의 날짜와 시간이 올바르지 않아도 인증서 검증에 문제가 생길 수 있으므로 먼저 정확한 시간으로 맞춥니다. 구독을 업데이트하면 항목이 달라질 수 있으니 현재 선택된 서버를 다시 확인하세요. 예전에 사용하던 항목의 이름만으로 설정이 여전히 유효하다고 판단해서는 안 됩니다.

먼저 Home의 Connectivity Test로 단서를 확인할 수 있습니다. 다만 결과는 테스트 방식과 대상에 따라 달라지므로 지연 시간만으로 웹사이트 접속이 가능하다고 단정할 수는 없습니다.
TCP 연결은 성립하지만 실제 요청이 실패한다면 인증 정보와 TLS 매개변수를 추가로 확인하세요. 포트 연결 성공과 앱 트래픽 전송 성공은 서로 다른 단계입니다.
특정 네트워크에서 Hysteria2 또는 WireGuard 항목만 실패한다면 해당 네트워크와 서버에서 UDP에 연결할 수 있는지 확인하세요. 이 프로토콜은 TCP 테스트 결과만으로 판단할 수 없습니다.
기존 구독 내용이 변경되었다면 원래 구독의 업데이트 기능으로 최신 매개변수를 가져오세요. 포트나 비밀번호를 추측하지 말고 구독 URL, 키, 전체 로그를 공개하지 마세요.

다음은 네트워크 로그에 나타날 수 있는 오류 문자열의 예시입니다. 고정된 팝업 제목이 아니며 프로토콜과 하위 계층 오류에 따라 표현이 달라집니다. 실제 기록에 해당 내용이 있을 때만 관련 항목에 따라 점검하세요.

오류: connection refused

원인과 해결:대상 포트의 연결이 거부되었습니다. 서비스가 포트를 열어 두지 않았거나 네트워크 장비가 연결을 차단했을 수 있습니다. 먼저 서버 주소와 포트를 확인한 뒤 서비스 상태를 서비스 제공업체에 문의하세요. 도메인 규칙부터 바꾸지는 마세요.

오류: i/o timeout

원인과 해결:읽기 또는 쓰기 단계가 제한 시간 안에 완료되지 않았습니다. 이 오류만으로 DNS 문제인지 서버 문제인지 알 수 없습니다. 앞뒤 로그를 확인해 시간이 초과된 대상을 파악하고, 다른 기본 네트워크에서 같은 설정으로 다시 테스트하세요.

오류: no such host

원인과 해결:조회한 호스트 이름을 사용할 수 있는 IP 주소로 해석하지 못했습니다. 서버 도메인인지 웹사이트 도메인인지 먼저 구분하고, 철자와 DNS 조회 경로를 확인하세요. 서버 도메인 해석 실패를 Rule 문제로 오인하지 않도록 주의하세요.

3. Global Routing으로 트래픽 분기 문제 확인

Home → Global Routing에서 현재 Proxy, Direct, Config 또는 Scene 중 어떤 항목이 선택되어 있는지 기록하세요. Proxy는 트래픽을 프록시로 처리하고, Direct는 직접 연결하며, Config는 활성화된 구성에 따라 트래픽을 분기하고, Scene은 선택한 시나리오의 설정에 따라 작동합니다. 문제를 점검하려면 현재 어떤 모드인지 알아야 합니다. Config에서 Rule만 수정하고 다른 모드를 계속 사용하면 예상한 변경이 적용되지 않을 수 있습니다.

옵션	이번 테스트 목적	결과 확인 후 다음 단계
Direct	직접 연결 경로가 작동하는지 비교	실패하면 연결을 끈 상태의 결과와 비교해 기본 네트워크와 DNS 설정을 확인하세요.
Proxy	같은 서버에서 프록시 경로 테스트	두 사이트 모두 실패하면 Rule 순서를 바꾸기 전에 서버, 인증, DNS를 먼저 확인하세요.
Config	현재 구성의 트래픽 분기 결과 테스트	Proxy에서는 접속되지만 Config에서 같은 사이트가 실패하면 적용된 Rule과 최종 정책을 확인하세요.
Scene	Scene에서 실제로 사용하는 설정 확인	현재 Scene을 먼저 확인하세요. 문제를 분리하려면 Proxy 또는 Config를 명확히 선택해 비교 테스트를 진행하세요.

정리: 프록시 경로를 고정한 뒤 Rule 확인

같은 네트워크, 같은 서버, 같은 사이트에서 Proxy로는 접속되지만 Config로는 실패한다면 다음 테스트에서는 Config의 적용 정책과 관련 DNS 설정만 확인하세요. 서버까지 함께 바꾸지 마세요. 이 비교로 문제 범위를 좁힐 수 있지만, 원인을 확정하려면 요청 기록도 함께 확인해야 합니다.

Global Routing 전환은 진단 방법이지 영구적인 해결책이 아닙니다. 테스트 중 기존 연결이 유지될 수 있으므로 모드를 바꾼 뒤에는 요청을 새로 보내고, 필요하면 연결을 껐다가 다시 켜세요. 테스트가 끝나면 원래 모드로 복구하세요. 특히 임시로 사용한 Proxy를 기존 트래픽 분기 설정이 해결된 것으로 간주하지 마세요.

4. DNS 문제가 발생한 단계 구분

DNS를 점검할 때는 먼저 “어떤 도메인을 해석하지 못했는가”를 확인하세요. 서버 주소가 도메인이라면 프록시 연결을 만들기 전에 서버 IP를 확인해야 합니다. 웹사이트 도메인은 그 이후 요청 단계에서 해석될 수 있습니다. 어느 단계에서든 시간 초과가 발생할 수 있지만, 해결 순서는 다릅니다. 먼저 서버 주소를 해석할 수 있게 한 다음 대상 도메인을 확인하세요. 아직 연결되지 않은 프록시가 모든 사전 DNS 조회를 대신 처리할 것으로 기대해서는 안 됩니다.

일반 DNS에서 주로 사용하는 포트(UDP 또는 TCP)

443

DoH가 일반적으로 사용하는 HTTPS 포트

853

DoT가 일반적으로 사용하는 TLS 포트

위 포트는 DNS 조회 방식에 흔히 쓰이는 포트이며, 서버 포트를 이 중 하나로 변경하라는 뜻이 아닙니다. 암호화 DNS를 사용하더라도 DNS 서버에 연결할 수 있어야 합니다. DNS 엔드포인트에 접속하려면 먼저 프록시를 연결해야 하는데 그 엔드포인트로 프록시 서버 도메인을 조회한다면 의존성 순환이 발생할 수 있습니다. DNS 주소가 올바르더라도 현재 네트워크에서 해당 주소에 접속할 수 있다는 보장은 없습니다.

Settings → DNS의 현재 설정을 기록하고, Config에서 현재 사용 중인 구성에 [General]의 dns-server 항목이 있는지 확인하세요. 설정을 제공하는 곳이 여러 곳이라면 실제로 적용 중인 출처부터 확인하세요. 활성화되지 않은 파일만 수정하지 마세요.
실패한 요청에 대상 IP가 기록되어 있는지, DNS 오류가 표시되는지, 서버 연결 전과 대상 요청 중 어느 단계에서 실패했는지 확인하세요. IP가 확인된 뒤 연결 시간 초과가 발생했다면 웹페이지가 열리지 않는다는 이유만으로 DNS 실패라고 단정할 수 없습니다.
DNS를 직접 설정한 적이 있다면 기존 값을 저장한 뒤 해당 설정만 이전에 작동했던 값으로 되돌려 비교하세요. 서버와 Global Routing은 그대로 두고 연결을 다시 설정한 다음 테스트합니다.
특정 Wi-Fi에서만 DNS 조회에 실패한다면 셀룰러 데이터로 전환해 한 가지 조건만 비교하세요. 결과가 다르면 네트워크 환경이 문제에 영향을 준다는 뜻이지만, 어떤 장비가 차단하는지까지 바로 판단할 수는 없습니다.

5. Config에서 Rule 적용 순서 확인

프록시 연결은 되지만 Config에서 특정 사이트만 실패한다면 Config에서 실제로 활성화된 파일을 열고 [Rule]을 확인하세요. 규칙은 순서대로 검사하며 먼저 일치하는 규칙이 해당 요청의 정책을 결정합니다. 일반적으로 구체적인 도메인 규칙을 포괄적인 규칙보다 앞에 두고 FINAL은 마지막에 둡니다. 수정 전에 원본 파일을 복사해 저장하고, 수정 후에도 해당 파일이 계속 적용 중인지 확인하세요.

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

위 예시는 구문과 순서만 보여 주며 기존 구성을 그대로 대체하라는 의미가 아닙니다. example.com은 예시 도메인입니다. DOMAIN-SUFFIX는 해당 도메인과 하위 도메인을 일치시키고, IP-CIDR은 IP 주소 대역을 일치시키며, GEOIP는 IP의 지역 정보를 기준으로 하고, FINAL은 앞선 규칙에 일치하지 않은 요청을 처리합니다. no-resolve는 IP 규칙을 적용하기 위해 도메인을 추가로 조회하지 않는다는 뜻이지 모든 DNS 조회를 끈다는 의미는 아닙니다.

확인 순서:대상이 앞쪽의 DIRECT 규칙에 이미 일치했다면 마지막의 FINAL은 해당 요청을 PROXY로 바꾸지 않습니다. 예외 규칙을 추가하려면 적용 결과를 덮어쓰는 규칙보다 앞에 배치하세요.
정책 확인:규칙이 사용자 지정 정책 이름을 가리킨다면 해당 정책이 존재하는지, 최종 선택된 서버가 작동하는지 확인하세요. 그룹 이름이 올바르게 보여도 그룹에서 선택된 항목이 작동한다는 뜻은 아닙니다.
거부 여부 확인:REJECT에 일치한 요청은 거부됩니다. 웹페이지 본문은 정상적으로 열리지만 필요한 리소스 하나가 실패한다면 주소창의 도메인만 확인하지 말고 해당 리소스의 도메인과 정책을 점검하세요.
IP 규칙 확인:GEOIP와 IP-CIDR은 요청에 사용할 수 있는 IP 정보에 의존합니다. 도메인의 DNS 조회 결과가 달라지면 규칙 적용도 달라질 수 있으므로 한 번의 관찰 결과를 계속 동일하게 유지되는 것으로 보지 마세요.

규칙을 찾았다면 실패한 대상과 관련된 범위만 최소한으로 수정한 뒤 기존 테스트를 반복하세요. 웹사이트 하나를 열기 위해 모든 규칙을 삭제하지 마세요. 일시적으로 접속 결과가 바뀌더라도 원래 문제를 판단할 근거가 사라질 수 있습니다. 규칙 항목의 자세한 설명은 구성 항목 매뉴얼에서 확인하세요.

6. 자주 발생하는 문제와 복구 방법

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

지연 시간 테스트는 특정 테스트의 응답만 보여 주며 모든 인증, TLS, DNS, 대상 요청을 확인하지는 않습니다. 같은 서버를 유지한 채 Home → Global Routing에서 Proxy를 선택하고 원래 테스트한 사이트에 접속한 다음 요청 오류를 확인해 핸드셰이크 실패인지 대상 연결 실패인지 판단하세요.

Wi-Fi에서는 되는데 셀룰러 데이터에서는 안 될 때 무엇부터 바꿔야 하나요?

먼저 연결을 끄고 셀룰러 네트워크 자체에서 인터넷에 접속할 수 있는지 확인한 다음, 시스템 설정에서 Shadowrocket의 셀룰러 데이터 권한을 확인하세요. 이후 같은 서버와 모드로 다시 테스트합니다. UDP에 의존하는 설정만 실패한다면 해당 네트워크의 연결 조건을 서비스 제공업체에 문의하고 프로토콜 항목을 임의로 변경하지 마세요.

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

먼저 Proxy와 Config에서 해당 사이트의 접속 결과를 비교하고, 실패한 리소스의 도메인, 적용된 Rule, 최종 정책을 확인하세요. 두 모드에서 모두 실패하지만 다른 사이트는 정상이라면 대상 서비스 상태, 원격 서버에서 대상 사이트까지의 경로, 해당 웹사이트의 접속 조건도 확인해야 합니다.

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

Settings → On Demand에서 자동 연결을 잠시 끈 다음 연결을 끈 상태의 기본 테스트를 진행하세요. 점검이 끝나면 원래 설정을 복구합니다. 자동 연결 동작을 스위치 고장으로 오인하지 말고, 이 문제만을 이유로 시스템 VPN 구성을 먼저 삭제하지 마세요.

마지막으로 임시 변경한 Global Routing, DNS, On Demand 설정을 복구하고 비교 테스트로 확인된 수정 사항만 유지하세요. 여전히 연결되지 않으면 발생 시각, 네트워크 종류, 프로토콜, 개인정보를 가린 오류 원문, Direct·Proxy·Config 세 번의 테스트 결과 차이를 서비스 제공업체에 전달하세요. 비밀번호, UUID, 키, 구독 token은 가리세요. 이런 정보가 단순히 “연결 스위치가 켜졌다”는 정보보다 연결 단계의 문제를 찾는 데 도움이 됩니다.