Shadowrocket에 연결됨으로 표시되는 것은 기기의 VPN 터널이 시작되었다는 뜻일 뿐, 원격 서버와 DNS, 접속하려는 웹사이트가 모두 정상이라는 의미는 아닙니다. 이미 이용 중인 서비스와 구독이 있는 사용자를 위해 기본 네트워크, 서버, Global Routing, DNS, 규칙 순서로 문제 범위를 좁혀 봅니다. 한 번에 하나씩만 변경하고 같은 주소로 다시 테스트한 뒤 평소 설정으로 되돌리세요.
1. 연결됨으로 표시되는데도 웹페이지가 열리지 않는 이유
먼저 문제가 어느 단계에서 발생하는지 확인하세요. 기기에 로컬 VPN 터널을 만드는 것, 원격 서버에 연결하는 것, 대상 도메인을 조회하는 것, 웹페이지 요청에 성공하는 것은 서로 다른 단계입니다. Home에서 연결 스위치가 켜져 있거나 시스템에 VPN 표시가 나타나더라도 특정 웹사이트에서 응답을 받아왔다는 뜻은 아닙니다.
무엇부터 확인해야 하나요? 먼저 기본 네트워크 상태를 비교하세요. 현재 네트워크, 선택한 서버, Global Routing 모드, 사용 중인 구성을 기록한 다음 Shadowrocket 연결을 잠시 끄고 현재 네트워크에서 보통 바로 접속되는 웹사이트를 열어 보세요. 이때도 접속되지 않는다면 규칙을 바꾸기 전에 Wi-Fi 로그인, 셀룰러 데이터 권한, 네트워크 자체를 확인해야 합니다.
-
현재 상태 기록
Home에서 선택한 서버와 현재 Global Routing 값을, Config에서 사용 중인 구성을 기록하세요. 문제 해결 후 원래대로 돌릴 수 있도록 구성 사본을 보관하세요.
-
자동 연결 일시 중지
Settings → On Demand에서 현재 설정을 기록한 뒤 On Demand를 잠시 끄세요. 이어서 Home의 연결 스위치를 꺼서 직접 연결을 테스트하는 동안 터널이 자동으로 다시 켜지지 않도록 합니다.
-
기본 네트워크 테스트
Safari에서 평소 바로 접속되는 웹사이트를 여세요. Wi-Fi에 웹 인증이 필요하다면 먼저 인증을 완료하고, 같은 주소를 셀룰러 네트워크에서도 비교해 보세요.
-
다시 연결
기본 네트워크가 정상이라면 Home으로 돌아가 연결을 켜고 같은 주소로 다시 테스트하세요. 이후 설정을 하나씩 변경할 때마다 연결을 다시 만들고 새 요청을 보내세요.
Wi-Fi와 셀룰러 네트워크에서 결과가 다르면 무엇을 알 수 있나요? 네트워크 경로와 관련된 문제일 가능성은 있지만, 특정 프로토콜의 오류라고 단정할 수는 없습니다. 서버 포트 연결 가능 여부, DNS, 네트워크 인증 상태는 네트워크에 따라 달라질 수 있습니다. 이 차이를 기록하고 다음 항목을 비교하세요.
2. 서버 테스트에 성공하면 인터넷도 되는 건가요?
그렇지는 않습니다. Home에서 현재 서버의 연결 테스트를 실행하고 어떤 테스트 방식인지 확인하세요. 포트 연결만 확인하는 테스트와 프록시를 통해 테스트 웹사이트에 요청을 보내는 방식은 확인 범위가 다릅니다. 지연 시간 하나만으로 모든 도메인, 전송 방식, 대상 포트를 사용할 수 있다고 보장할 수 없습니다.
테스트에 실패하면 어떤 항목부터 수정해야 하나요? 현재 서버의 편집 화면을 열고 서비스 제공업체가 안내한 원본 정보와 대조해 주소, 포트, Type, 인증 정보를 하나씩 확인하세요. 경험에 따라 포트를 모두 443으로 바꾸지 마세요. 443은 HTTPS에서 흔히 쓰는 포트일 뿐이며, 원격 프록시의 수신 포트는 서버 설정과 일치해야 합니다.
| 점검 항목 | 확인할 내용 | 잘못 판단하기 쉬운 경우 |
|---|---|---|
| 주소와 포트 | 전체 호스트 이름 또는 IP, 실제 수신 포트 | 웹사이트의 443을 입력해도 프록시 서비스 포트와 다를 수 있습니다. |
| Shadowsocks | 암호화 방식과 비밀번호가 서버 설정과 일치하는지 확인 | 주소에 연결할 수 있어도 인증 및 암호화 매개변수가 올바르다는 뜻은 아닙니다. |
| VMess / VLESS | UUID, 전송 방식 및 관련 전송 매개변수 | UUID가 맞더라도 전송 설정이 일치하지 않을 수 있습니다. |
| Trojan 및 TLS | 비밀번호, 서비스에서 요구하는 TLS, 서버 이름 | IP로 연결하더라도 인증서 이름 검증에 실패할 수 있습니다. |
| Hysteria2 / WireGuard | 서비스 안내에 따라 인증, 키 및 관련 매개변수를 확인 | TCP만 확인하는 테스트 결과로 UDP 경로를 판단할 수 없습니다. |
직접 수정할까요, 구독을 업데이트할까요? 서버를 구독에서 가져왔다면 먼저 구독 업데이트가 성공했는지, 선택한 항목이 아직 서비스 이용 범위에 포함되는지 확인하세요. 구독 업데이트는 연결 정보를 새로 고치는 작업이지 원격 서버의 사용 가능 여부를 확인하는 작업은 아닙니다. 사본을 저장하지 않은 채 구성을 반복해서 덮어쓰지 마세요. 이 글에서는 연결 리소스를 제공하지 않으며, 매개변수의 유효성은 이용 중인 서비스 제공업체에 문의해야 합니다.
오류 키워드: Connection timed out
원인 및 해결 방법: 제한 시간 안에 연결이 완료되지 않았다는 뜻입니다. 주소, 포트 또는 네트워크 경로가 원인일 수 있으니 먼저 서버 정보를 확인하고 Wi-Fi와 셀룰러 네트워크에서 각각 테스트하세요. 시간 초과만으로 서비스가 중단됐다고 단정할 수는 없습니다.
오류 키워드: Connection refused
원인 및 해결 방법: 대상 측 또는 중간 장비에서 연결을 명시적으로 거부한 상태입니다. 포트에서 서비스가 대기 중이지 않거나 정책에 의해 거부되었을 수 있습니다. 포트를 확인하고 서비스 제공업체에 수신 상태를 문의하세요.
오류 키워드: No such host
원인 및 해결 방법: 해당 호스트 이름을 조회하지 못한 상태입니다. 서버 주소인지 대상 웹사이트의 도메인인지 먼저 구분하고, 철자와 현재 DNS 설정을 확인하세요. 도메인 조회 실패를 비밀번호 오류로 오인하지 마세요.
이 오류 문구는 어디에서 확인하나요? 앱의 연결 기록이나 진단 정보, 시스템 네트워크 오류에 표시된 원문과 발생 시간을 기록하세요. 요청에 따라 표시 문구가 달라질 수 있습니다. 해당 문구가 실제로 보이지 않았다면 여기의 예시를 기기에서 확인된 진단으로 간주하지 마세요.
3. Global Routing 비교 테스트 방법
문제를 파악하기 쉽도록 모드를 어떻게 비교해야 하나요? Home → Global Routing에서 현재 값을 기록한 뒤 Direct, Proxy, Config를 각각 선택해 같은 주소로 새 요청을 보내세요. 이는 짧은 진단을 위한 절차이며 특정 모드를 계속 사용하라는 뜻은 아닙니다. Direct 비교에는 현재 네트워크에서 직접 접속할 수 있는 대상을 선택하세요.
| 모드 또는 증상 | 의미 및 다음 단계 |
|---|---|
| Direct | 직접 연결 비교에 사용합니다. VPN 전체를 끄는 것과 같지는 않으며 앱 내 DNS 설정의 영향도 배제할 수 없습니다. |
| Proxy | 현재 프록시 경로를 확인합니다. 실제로 사용 중인 서버 또는 정책을 확인해 선택한 대상이 바뀌지 않았는지 살펴보세요. |
| Config | 현재 구성의 규칙에 따라 트래픽을 분기합니다. Proxy는 정상인데 Config에서 실패한다면 적용된 규칙과 정책을 먼저 확인하세요. |
| Scene | 시나리오 설정에 따라 라우팅 동작을 선택합니다. 문제를 확인할 때는 현재 시나리오를 살펴본 뒤 명확한 비교 모드로 잠시 바꾸세요. |
| Direct는 정상, Proxy는 실패 | 프록시 서버, 인증, 전송 매개변수와 서버 도메인 조회를 중점적으로 확인하세요. |
| Proxy는 정상, Config는 실패 | 대상이 적절하지 않은 경로로 라우팅되었거나 사용할 수 없는 정책을 참조하는지 확인하세요. |
결론: 경로를 고정한 뒤 규칙을 수정하세요
Proxy에서는 같은 주소가 열리지만 Config에서는 열리지 않는다면 서버 매개변수는 그대로 두고 규칙 적용 여부를 확인하세요. 검증을 마친 서버 설정을 잘못 바꾸는 일을 막을 수 있습니다.
4. DNS 조회 실패인지 확인하는 방법
웹페이지가 계속 로딩된다고 해서 반드시 DNS 문제인 것은 아닙니다. DNS 장애라고 판단하려면 조회 결과나 명확한 조회 오류가 근거로 있어야 합니다. 서버 주소와 대상 웹사이트 도메인도 구분해야 합니다. 서버 주소가 도메인이라면 먼저 조회가 필요하며, 대상 웹사이트 도메인은 다른 경로로 조회될 수 있습니다. 서버 주소 조회에 실패하면 프록시 연결 자체가 성립하지 않을 수 있습니다.
구체적으로 어디서 확인하나요? Config에서 현재 사용 중인 구성을 열고 DNS 관련 설정을 살펴보세요. 먼저 사본을 저장한 다음 [General]의 dns-server와 특정 도메인에 적용되는 별도 DNS 설정이 있는지 확인하세요. 시스템 Wi-Fi의 DNS만 바꿔도 구성에서 지정한 조회 경로에는 적용되지 않을 수 있습니다.
- 주소 형식 확인: 오타, 구분자 누락, 현재 연결할 수 없는 리졸버가 있는지 확인하세요. 암호화 DNS 주소라면 호스트 이름 조회와 HTTPS 연결이 가능한지도 확인해야 합니다.
- 전송 경로 확인: 일반 DNS는 주로 UDP 또는 TCP 53번 포트를 사용하고, DoH는 HTTPS를 사용하며 보통 443번 포트를 이용합니다. 포트의 용도만으로 현재 네트워크에서 해당 서비스에 접속할 수 있다고 단정할 수는 없습니다.
- 한 항목씩 되돌리기: DNS를 직접 변경한 뒤 문제가 시작됐다면 여러 리졸버를 추가하거나 모드와 서버를 동시에 바꾸지 말고, 변경 전 구성 사본부터 복원하세요.
- 새 요청으로 재테스트: 다시 연결한 뒤 페이지를 새로 불러오고 새로 생성된 기록을 확인하세요. 브라우저와 앱에 캐시가 남을 수 있으므로 한 번의 성공이나 실패만으로 모든 도메인의 상태를 판단할 수는 없습니다.
웹사이트 IP를 직접 입력해 DNS 문제를 확인해도 되나요? 그것만으로 결론을 내릴 수는 없습니다. HTTPS는 인증서 확인과 가상 호스트 선택에 도메인을 사용하므로 IP로 직접 접속하면 인증서 오류가 발생하거나 다른 사이트가 표시될 수 있습니다. 먼저 도메인이 유효한 조회 결과를 반환하는지 살펴본 뒤 이어지는 연결이 성공하는지 확인하세요.
5. 규칙 적용 오류: 어떤 키워드를 확인해야 하나요?
Config 모드에서 일부 웹사이트만 열리지 않는다면 무엇부터 확인해야 하나요? Config에서 선택한 구성을 확인하고, 실패한 요청의 연결 기록에서 대상 도메인 또는 IP, 적용된 규칙, 최종 정책, 사용된 서버를 살펴보세요. Shadowrocket은 규칙 순서대로 일치 여부를 확인하므로 앞선 규칙이 결과에 영향을 줄 수 있습니다. 파일에 해당 도메인 규칙이 있다는 것만 확인해서는 충분하지 않습니다.
| 키워드 | 일치 범위 | 점검할 내용 |
|---|---|---|
DOMAIN | 전체 도메인 | 기본 도메인과 각 하위 도메인을 따로 확인해야 합니다. |
DOMAIN-SUFFIX | 도메인과 모든 하위 도메인 | 접미사 범위가 지나치게 넓은지, 앞선 규칙에서 먼저 처리되는지 확인하세요. |
GEOIP | IP 지리 데이터베이스 결과에 따라 일치 | 도메인 접미사로 지역을 추측하지 말고 대상 IP의 할당 정보를 확인하세요. |
IP-CIDR | IPv4 주소 범위 | 마스크 범위가 올바른지, 조회된 주소가 해당 범위에 포함되는지 확인하세요. |
FINAL | 앞선 규칙과 일치하지 않은 요청 | 최종 정책을 사용할 수 있는지, 예상한 정책인지 확인하세요. |
규칙 문법은 어떻게 확인하나요? 아래는 세 가지 규칙 유형과 순서를 보여 주는 예시일 뿐, 그대로 가져와 적용하라는 구성이 아닙니다. example.com과 192.0.2.0/24는 문서용 예시이며, PROXY가 실제로 사용하는 프록시 출구도 자신의 구성에서 확인해야 합니다.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY여기서 no-resolve를 사용하는 이유는 무엇인가요? 이 IP 규칙에서 일치 여부를 확인하기 위해 도메인 조회를 능동적으로 시작하지 않는다는 뜻입니다. DNS를 전역적으로 끄는 설정은 아닙니다. 또한 이후 규칙을 계속 확인해야 하는 위치에 FINAL을 두지 마세요. 뒤에 오는 규칙이 의도한 트래픽 분기를 처리하지 못합니다.
- 페이지의 글자는 보이는데 이미지가 로드되지 않음: 페이지, 이미지, API 도메인의 기록을 각각 확인하세요. 기본 사이트에 규칙 하나만 추가해서는 해결되지 않을 수 있습니다.
- 규칙이 정책 그룹을 선택함: 그룹 안에서 실제로 선택된 서버를 확인하세요. 그룹 이름이 표시된다고 해서 구성원이 사용 가능하다는 뜻은 아닙니다.
- 직접 수정한 뒤 잠시 정상으로 돌아옴: 수정 전후의 차이를 저장하고 구독 또는 구성 업데이트가 로컬 변경 사항을 덮어썼는지 확인하세요.
6. 문제 해결 후 설정 복원 및 증거 보존 방법
문제가 사라지면 바로 마무리해도 되나요? 먼저 평소 사용하던 Global Routing 모드로 되돌리고 Config에서 예상한 구성을 사용 중인지 확인하세요. 평소 On Demand를 사용한다면 Settings → On Demand로 돌아가 기존 조건을 복원한 뒤 Wi-Fi, 셀룰러 네트워크, 네트워크 전환 후의 동작을 각각 확인하세요. 임시 진단 모드를 최종 설정으로 착각하지 마세요.
원인을 찾지 못했다면 어떤 정보를 준비해야 하나요? 단순히 “연결됨으로 표시되지만 열리지 않음”이라고만 알리기보다 재현 가능한 단계로 정리하세요. 서비스 매개변수와 서비스 상태는 서비스 제공업체에 확인하고, 앱 설정은 모드, 구성, 연결 기록을 함께 살펴봐야 합니다. 자료를 다른 사람에게 보내기 전에 구독 토큰, 비밀번호, UUID, 개인 키 및 기타 인증 정보를 가리세요.
- 테스트 환경: 기기 유형, 시스템 정보, Wi-Fi 또는 셀룰러 네트워크, 기본 네트워크의 정상 여부.
- 라우팅 비교: 같은 주소가 Direct, Proxy, Config에서 각각 열리는지 여부.
- 서버 상태: 프로토콜 Type, 연결 테스트 방식과 결과. 인증 키는 보내지 마세요.
- 요청 증거: 발생 시간, 민감 정보를 가린 오류 원문, 적용된 규칙 및 최종 정책.
- 변경 기록: 마지막 정상 사용 이후 서버를 바꾸거나 구독을 업데이트했는지, DNS 또는 구성을 수정했는지 여부.
결론: 반복 가능한 차이로 해결 여부를 확인하세요
같은 네트워크와 같은 주소에서 특정 설정을 되돌렸을 때 실패가 반복되고, 다시 수정했을 때 복구되는 경우에만 해당 설정을 원인으로 볼 근거가 생깁니다. 한 번 새로고침해 성공한 것만으로 최종 결론을 내리지 마세요.