이 글의 핵심

Shadowrocket의 연결 스위치를 켰다는 것은 기기에서 연결 상태가 활성화되었다는 뜻일 뿐, 원격 서버와 도메인 조회, 대상 웹사이트까지 모두 정상이라는 의미는 아닙니다. 직접 보유한 서비스 정보와 구독이 있지만 웹페이지가 열리지 않는 경우, 먼저 기본 네트워크와 비교한 뒤 서버, 모드, DNS, 규칙을 차례로 점검하세요. 한 번에 한 항목만 변경하고, 점검이 끝나면 평소 설정으로 되돌리세요.

1. 기본 네트워크 문제와 프록시 연결 문제 구분하기

구독을 바로 삭제하거나 모든 설정을 초기화하지 마세요. 먼저 Home에서 현재 선택된 서버와 Global Routing 모드를, Config에서 사용 중인 구성 파일을 기록해 두세요. 같은 ‘웹페이지가 열리지 않는’ 증상도 원인은 다를 수 있습니다. 정보를 보존해야 이후 어떤 변경이 효과가 있었는지 확인할 수 있습니다.

시스템에 연결됨으로 표시되면 일반적으로 로컬 VPN 터널이 시작된 상태입니다. 원격 서버가 연결을 허용하는지, 인증 정보가 유효한지, DNS 응답이 오는지는 별도로 확인해야 합니다. 평소 접속할 수 있고 로그인이 필요 없는 일반 웹페이지로 테스트하고, 정확한 시간과 오류 증상을 기록하세요.

  1. 현재 상태 기록

    Home에서 선택한 서버와 Global Routing 모드를, Config에서 현재 구성을 기록하세요. 기존 설정을 저장한 다음 변경해야 원래 문제와 새로 적용한 변경 사항을 구분할 수 있습니다.

  2. 연결 끄기

    Home의 연결 스위치를 끄세요. 연결이 자동으로 다시 켜지면 Settings → On Demand에서 해당 조건을 일시적으로 비활성화한 뒤 연결이 완전히 종료됐는지 확인하세요.

  3. 직접 연결 확인

    Safari에서 직접 연결이 가능한 것으로 알고 있는 웹페이지를 여세요. 여전히 열리지 않는다면 규칙을 먼저 바꾸지 말고 현재 Wi-Fi의 로그인 인증, 셀룰러 데이터 권한, 기본 네트워크 상태부터 확인하세요.

  4. 다시 연결해 테스트

    연결을 다시 켜고 같은 웹페이지로 재검사하세요. 테스트 중에는 같은 네트워크, 서버, 대상을 유지하고 매번 설정 하나만 변경하세요.

  5. 네트워크를 바꿔 비교

    가능하다면 Wi-Fi와 셀룰러 네트워크를 바꿔 같은 대상을 테스트하세요. 한쪽 네트워크에서만 실패한다면 해당 네트워크의 DNS 조회, 포트 또는 전송 제한을 먼저 확인하세요.

2. 서버 주소·포트·프로토콜 설정 확인

Home에서 실제로 선택된 서버를 확인하세요. 구독 그룹 이름만 확인해서는 안 됩니다. 해당 서버의 편집 화면을 열고 Address, Port, Type 및 인증 항목을 보유한 서비스 정보와 하나씩 대조하세요. 구독 업데이트가 성공했다는 것은 구독 내용을 가져와 읽을 수 있다는 뜻일 뿐, 그 안의 모든 서버가 현재 통신 가능하다는 의미는 아닙니다.

Shadowsocks, VMess, VLESS, Trojan, Hysteria2, WireGuard의 설정값은 서로 바꿔 쓸 수 없습니다. 서버에서 사용하는 프로토콜에 맞춰 항목을 확인하세요. TLS를 사용하는 경우 서버 이름과 인증서 요구 사항도 확인하고, 전송 계층 설정이 있다면 경로와 호스트 이름 등의 값도 살펴보세요. Type을 임의로 바꿔 ‘고치려’ 하지 마세요.

연결 로그에 아래 문구가 있다면 오류가 발생한 단계에 따라 점검하세요. 프로토콜이나 오류 발생 위치에 따라 앞뒤에 다른 문구가 붙을 수 있으니, 특정 단어만 보고 결론 내리지 말고 전체 로그를 보관하세요.

오류: connection refused

원인: 대상 주소나 중간 장비가 연결을 거부한 상태입니다. 포트가 일치하지 않거나 서버가 수신 대기 중이 아닐 때 자주 발생합니다.

해결: Address와 Port를 확인하고, 해당 포트가 현재 수신 대기 중인지 기존 서비스 제공자에게 문의하세요.

오류: i/o timeout

원인: 네트워크 읽기 또는 쓰기 작업이 제한 시간 안에 완료되지 않았다는 뜻입니다. 이 오류만으로 네트워크에서 패킷이 차단됐는지, 서버가 응답하지 않는지, 이후 핸드셰이크가 멈췄는지는 구분할 수 없습니다.

해결: 시간 초과가 발생한 대상과 단계를 기록하세요. 설정을 그대로 둔 채 네트워크를 바꿔 다시 테스트하고, 같은 구독에서 직접 보유한 다른 서버와 비교하세요.

오류: no such host

원인: 이번 조회에서 사용할 수 있는 호스트 주소를 얻지 못했습니다. 서버 도메인이 잘못되었거나 DNS 조회 경로에 문제가 있을 수 있습니다.

해결: 먼저 오류에 표시된 도메인을 확인하세요. 서버 주소 자체의 문제라면 웹사이트 도메인을 테스트하기 전에 해당 서버 주소가 조회되도록 해결해야 합니다.

3. Global Routing으로 문제 범위 좁히기

Home → Global Routing으로 이동해 현재 모드를 확인하세요. Direct, Proxy, Config, Scene은 각기 다른 처리 방식이지 연결 성공도를 나타내는 단계가 아닙니다. 테스트 전에 원래 모드를 기록하고 잠시 전환한 뒤, 점검이 끝나면 원래대로 복원하세요.

모드주요 기능점검 목적
Direct직접 연결로 처리기본 직접 연결 경로를 확인합니다. 프록시 서버가 사용 가능한지 확인하는 용도로는 쓸 수 없습니다.
Proxy프록시를 사용해 처리현재 프록시 경로를 임시로 확인해 구성 규칙에 따른 분기가 결과에 미치는 영향을 줄입니다.
Config현재 구성 파일의 규칙에 따라 처리규칙 순서, 정책 이름, 최종 기본 처리 방식을 확인할 때 적합합니다.
Scene설정된 Scene 조건에 따라 처리현재 네트워크에서 어떤 Scene이 활성화됐는지, 해당 Scene이 실제로 어떤 설정을 사용하는지 확인합니다.

같은 서버와 같은 웹 주소로 비교하세요. Proxy에서는 열리지만 Config에서 열리지 않는다면 규칙과 정책을 우선 확인하되, 모드를 바꾸면 요청 경로와 DNS 조회 방식도 달라질 수 있다는 점에 유의하세요. Proxy에서도 실패한다면 서버 설정과 DNS를 먼저 다시 확인하고, 도메인 규칙을 계속 추가하며 시험하지 마세요.

정리: 경로를 고정한 뒤 규칙을 변경하세요

같은 대상이 고정된 프록시 경로에서는 열리고 Config에서 일관되게 실패할 때만 규칙 분기를 우선 점검하세요. 두 모드 모두 실패한다면 규칙은 그대로 두고 공통으로 사용하는 서버와 DNS 조회 경로를 먼저 확인하세요.

4. DNS 확인: 어떤 도메인 조회가 실패했는지 구분하기

DNS 문제는 적어도 두 단계에서 발생할 수 있습니다. 원격 서버에 연결할 때 서버 도메인을 조회하고, 웹페이지에 접속할 때는 웹사이트 도메인을 조회합니다. 전자가 실패하면 프록시 연결 자체가 성립하지 않을 수 있고, 후자가 실패하면 연결된 상태에서도 웹페이지가 오래 기다리는 증상이 나타날 수 있습니다. DNS 주소를 계속 바꾸기보다 오류에 실제로 표시된 도메인을 확인하는 편이 효과적입니다.

Settings → DNS에서 앱의 DNS 설정을 확인하고, 현재 Config 파일에 DNS 관련 설정이 있는지도 살펴보세요. 현재 값과 설정 출처를 기록해야 Settings만 바꾸고 실제로 사용하는 구성에 다른 DNS 요구 사항이 남아 있는 상황을 피할 수 있습니다. 구성별로 어떤 설정이 실제 적용되는지는 요청 기록을 함께 확인하세요.

53
일반 DNS에서 주로 사용하는 UDP / TCP 포트
853
DNS over TLS의 표준 기본 포트
443
DNS over HTTPS에서 주로 사용하는 HTTPS 포트

5. 규칙 순서, 정책, FINAL 확인

Config에서 선택된 구성 파일을 확인한 다음 규칙을 살펴보세요. 규칙은 일반적으로 순서대로 일치 여부를 확인하며, 앞쪽 규칙에 일치하면 뒤쪽 규칙이 요청을 처리하지 못할 수 있습니다. 파일 끝에 도메인 규칙 하나를 추가해도 앞선 규칙에서 이미 처리된 트래픽에는 아무런 변화가 없을 수 있습니다.

아래 예시는 구문을 파악하기 위한 것으로, 현재 구성을 그대로 대체하라는 범용 권장안이 아닙니다. example.com은 예시 도메인이고 192.0.2.0/24는 문서용 예시 네트워크입니다. 실제 문제를 점검할 때는 실패한 도메인, 요청 기록, 본인의 정책을 기준으로 확인하세요.

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

구성에서 사용자 지정 정책 그룹을 참조한다면 그룹 내부에서 현재 어떤 항목이 선택됐는지도 확인하세요. 규칙이 그룹 이름과 일치하더라도 그룹이 최종적으로 프록시를 사용하는 것은 아닙니다. 그룹 안에서 직접 연결이나 현재 사용할 수 없는 서버가 선택됐을 수 있습니다. 규칙 텍스트만 확인하는 것보다 요청 기록에서 ‘대상 도메인 → 일치한 규칙 → 정책 그룹 → 실제 연결 경로’를 확인하는 편이 확실합니다.

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

지연 시간이 표시되는데 웹페이지는 왜 열리지 않나요?

먼저 Connectivity Test가 어떤 방식으로 테스트하는지 확인하세요. TCP 연결 한 번이나 테스트 주소의 응답은 전체 경로 중 일부만 확인합니다. 실제로 실패한 웹사이트를 다시 테스트하고 인증, DNS, 규칙 일치 여부를 살펴보세요. 지연 시간 수치만으로 모든 웹사이트에 접속할 수 있다고 볼 수는 없습니다.

웹사이트 하나만 열리지 않는데 구독을 다시 가져와야 하나요?

먼저 같은 서버로 다른 웹페이지를 열어 보고, 해당 사이트에서 실패한 요청의 도메인과 정책을 확인하세요. Proxy에서는 열리지만 Config에서 실패한다면 그 도메인의 규칙과 관련 리소스를 우선 점검하세요. 구독을 다시 가져와도 구성 파일의 도메인 분기 오류는 대개 해결되지 않습니다.

연결을 껐는데 다시 자동으로 연결됩니다. 직접 연결은 어떻게 테스트하나요?

Settings → On Demand에서 관련 자동 연결 조건을 잠시 비활성화한 다음 Home으로 돌아가 연결을 끄고 상태를 확인하세요. 비교 테스트가 끝나면 원래 설정을 복원하세요. 그래야 On Demand가 연결을 다시 시작한 것을 수동 전환이 적용되지 않은 것으로 오해하지 않습니다.

구독을 업데이트했는데 왜 원래 서버는 여전히 사용할 수 없나요?

업데이트는 목록 내용만 새로 고칩니다. Home으로 돌아가 실제로 선택된 항목을 확인하고 주소, 포트, 인증 정보가 바뀌었는지 살펴보세요. 목록이 본인의 유효한 서비스 정보와 다르다면 기존 서비스 제공자에게 확인하세요. 같은 링크를 반복해서 가져와 중복 항목을 만들지 마세요.

정상화되면 테스트를 위해 임시로 바꾼 설정을 되돌리세요. 평소 사용하는 Global Routing 모드로 복원하고, Config에서 올바른 파일이 선택됐는지 확인한 뒤 필요한 On Demand 조건도 다시 설정하세요. 이후 직접 연결이 필요한 웹페이지, 프록시로 처리해야 하는 웹페이지, 이전에 실패한 기능을 각각 다시 테스트하세요. 첫 화면만 확인해 로그인이나 이미지 요청을 놓치지 않도록 합니다.