Shadowrocket의 지연 시간만으로는 웹페이지 접속 경로가 정상이라고 단정할 수 없습니다. 서비스와 구독을 이미 이용 중이라면 네트워크, 대상 URL, 출구 항목을 고정한 뒤 DNS 조회, Global Routing, 연결 오류를 차례로 확인하세요. 이 글에서는 재현 가능한 순서에 따라 DNS 조회 실패, 규칙 선택 오류, 출구 연결 실패를 구분합니다. 한 번에 한 항목만 바꿔 DNS를 계속 바꾸는 것으로 근본 원인을 가리지 않도록 합니다.
1. 지연 테스트가 정상이어도 테스트 대상에 응답이 있었다는 뜻입니다
웹페이지를 열려면 도메인 조회, 연결 수립, TLS 핸드셰이크, 콘텐츠 요청을 거쳐야 합니다. DNS는 도메인을 IP 주소로 변환합니다. 주소를 알아낸 뒤에도 대상 포트, 네트워크 경로, 인증서 또는 서버 상태 때문에 연결이 차단될 수 있습니다. 지연 테스트는 대상과 방식에 따라 확인하는 단계가 다르므로, 표시된 밀리초 값만으로 웹페이지 접속 가능 여부를 판단할 수 없습니다.
이 흐름은 문제를 찾기 위한 참고용이며, 모든 요청이 반드시 같은 순서로 처리된다는 뜻은 아닙니다. IP를 얻기 전에 도메인 규칙이 적용될 수 있고, 일부 출구 방식은 도메인 조회를 원격에서 처리할 수도 있습니다. 모든 도메인이 같은 DNS 서버에서 조회된다고 가정하지 말고 현재 설정과 요청 기록을 기준으로 확인하세요.
- 서버 주소에 연결할 수 있음: 테스트에 사용된 주소와 포트가 응답했다는 뜻일 뿐, 모든 웹사이트에 접속할 수 있다는 의미는 아닙니다.
- 특정 테스트 URL에 접속할 수 있음: 해당 시점에 그 대상이 작동했다는 뜻일 뿐, 다른 도메인은 다른 규칙이나 주소 체계를 사용할 수 있습니다.
- 웹페이지가 계속 로딩 중임: DNS 응답 대기일 수도 있고, 연결·핸드셰이크·페이지 리소스 중 하나가 시간 초과된 것일 수도 있습니다. 오류 메시지를 더 확인해야 합니다.
2. DNS 설정을 이해하고 포트와 리졸버를 구분하세요
먼저 Config에서 현재 선택된 구성을 확인한 다음 DNS 설정을 살펴보세요. 구성 파일의 [General] 섹션에는 dns-server를 지정할 수 있으며, system은 시스템 DNS를 사용한다는 뜻입니다. 구성에 다른 리졸버가 이미 지정되어 있다면 수정하기 전에 기존 값을 기록하고 섹션 전체를 덮어쓰지 마세요.
[General]
dns-server = system이 내용은 설정 항목을 확인하기 위한 설명이며, 완성된 구성이나 모든 네트워크에서 system으로 바꾸라는 뜻이 아닙니다. 시스템 DNS는 현재 연결된 네트워크의 영향을 받습니다. 사용자 지정 DNS를 사용하려면 해당 주소와 전송 경로에 연결할 수 있어야 합니다. 암호화 DNS는 조회 과정의 전송을 보호하지만 대상 웹사이트에 연결할 수 있다고 보장하지는 않습니다.
위 숫자는 프로토콜에서 주로 사용하는 포트이며, Add Server 화면에 차례로 입력할 값이 아닙니다. 출구 서버의 Port는 서비스 제공자가 안내한 값과 일치해야 합니다. DoH는 HTTPS 요청 경로를 사용하므로 IP 주소만 있는 문자열을 완전한 DoH 주소로 입력할 수 없습니다.
요약: 먼저 조회 결과를 확인한 다음 DNS 변경 여부를 판단하세요
같은 요청에서 대상 IP를 이미 얻은 뒤 연결 시간 초과가 발생했다면 출구 경로와 대상 포트를 먼저 확인하세요. 조회 실패, 잘못된 주소 반환 또는 주소 체계 차이를 보여주는 증거가 있을 때 DNS 문제를 더 살펴보는 것이 적절합니다.
3. 재현 가능한 문제 해결 기록을 남기는 5단계
평소 접속할 수 있고 현재 오류를 안정적으로 재현할 수 있는 URL 하나를 고르세요. 전체 도메인, 테스트 시간, 연결된 네트워크, 오류 문구를 기록합니다. 네트워크, 출구 항목, DNS, 규칙을 동시에 바꾸지 마세요. 페이지가 다시 열려도 어느 항목이 영향을 주었는지 알 수 없습니다.
- 네트워크 연결을 완료했는지 확인합니다. 인증이 필요한 경우 신뢰할 수 있는 네트워크에서 웹 인증을 마치세요. 연결 스위치를 끈 상태와 켠 상태의 결과를 각각 기록합니다. 이 비교는 문제 범위를 파악하기 위한 것이며, 모든 대상이 두 상태에서 모두 접속되어야 한다는 뜻은 아닙니다.
- 현재 출구를 확인합니다. Home으로 돌아가 연결 스위치와 선택된 항목을 확인하세요. 항목이 Subscribe에서 가져온 것이라면 구독 링크는 이용 중인 서비스 제공자에게 받으세요. 구독 상태와 항목 매개변수를 확인하되, 업데이트 성공이 서버 연결을 보장한다고 여기지 마세요.
- 라우팅 상태를 기록합니다. Home → Global Routing으로 이동해 현재 Config, Proxy, Direct 또는 Scene 중 무엇이 선택되어 있는지 기록하세요. Scene은 적용 조건도 확인해야 합니다. 이름만으로 실제 경로를 판단할 수 없습니다.
- 같은 조건에서 요청을 한 번 보냅니다. 같은 URL에 접속한 뒤 확인 가능한 요청 기록이나 로그에서 도메인, 조회 주소, 적용된 규칙, 출구 정책, 오류 문구를 살펴보세요. 기록에 없는 항목은 알 수 없음으로 표시하고 임의로 추측하지 마세요.
- 한 항목만 바꾼 뒤 다시 테스트합니다. 예를 들어 나머지 조건은 그대로 두고 Config와 Proxy를 비교하거나, 현재 DNS와 연결 가능 여부를 확인한 리졸버 방식을 비교할 수 있습니다. 매번 결과를 기록하세요. 개선되지 않으면 원래 값으로 되돌린 뒤 다음 가설을 확인합니다.
4. 오류 메시지로 DNS 조회·연결·인증서 실패 구분하기
아래는 네트워크 로그에서 흔히 볼 수 있는 오류 원문 예시이며, 모든 화면에 같은 문자열이 표시된다는 뜻은 아닙니다. 같은 문제도 브라우저 안내, 요청 기록의 짧은 오류 또는 더 상세한 로그로 나타날 수 있습니다. 오류와 함께 표시된 도메인을 확인하세요. 문제가 발생한 대상은 웹사이트일 수도 있고 출구 서버나 DNS 엔드포인트일 수도 있습니다.
오류: no such host
원인: 현재 조회 과정에서 필요한 호스트 주소를 얻지 못했거나 도메인 철자가 잘못되었을 수 있습니다.
해결 방법: 먼저 오류에 표시된 도메인을 확인한 다음 현재 DNS에 연결할 수 있는지 살펴보세요. 출구 서버 도메인에서 발생한 오류라면 대상 웹사이트 규칙이 아니라 해당 도메인의 조회 문제부터 해결해야 합니다.
오류: i/o timeout
원인: 네트워크 읽기 또는 쓰기 작업이 제한 시간 안에 완료되지 않았습니다. DNS 조회, 연결 또는 이후 데이터 전송 중에 발생할 수 있습니다.
해결 방법: 오류 앞에 표시된 주소와 작업 단계를 확인하세요. DNS 조회 시간 초과라면 리졸버 경로를 살펴보고, 연결 시간 초과라면 출구 주소, Port, 현재 네트워크를 확인하세요.
오류: connection refused
원인: 연결 시도가 거부 응답을 받았습니다. 대상 포트에서 서비스가 대기 중이지 않거나 네트워크 장비가 연결을 차단했을 수 있습니다.
해결 방법: 거부된 대상이 웹사이트인지 출구 서버인지 확인하고 해당 포트를 살펴보세요. 서비스 제공자가 안내한 출구 매개변수에 문제가 있다면 이용 중인 서비스 제공자에게 상태를 문의하세요.
오류: certificate has expired or is not yet valid
원인: 인증서 유효 기간이 현재 시간과 맞지 않습니다. 기기의 시간, 웹사이트 인증서 또는 출구 TLS 엔드포인트가 원인일 수 있습니다.
해결 방법: 먼저 시스템 날짜와 시간을 확인한 다음 오류가 발생한 도메인을 확인하세요. 인증서 검증은 유지하고, 검증을 끄는 방식으로 문제를 대신 해결하지 마세요.
웹사이트에서 HTTP 403 또는 HTTP 404를 반환했다면 일반적으로 해당 요청이 HTTP 서비스에 도달했다는 뜻입니다. 이 응답을 단순한 DNS 조회 실패로 볼 수는 없습니다. 대상 주소가 올바른지, 웹사이트 접속 조건과 서버 상태를 확인하세요. 잘못된 서비스로 조회됐다고 의심되면 DNS 반환값을 확인합니다.
5. DNS 조회에 성공했다면 규칙과 IPv6 경로를 확인하세요
Config 설정에서는 현재 구성의 규칙이 요청에 영향을 줍니다. DOMAIN-SUFFIX 도메인 접미사 규칙과 IP-CIDR 주소 대역 규칙은 서로 다른 대상을 처리합니다. GEOIP 규칙은 IP 위치 판정에 의존하며 FINAL은 마지막에 적용되는 기본 규칙입니다. DNS 조회 결과가 있어도 요청이 예상한 출구를 거친다는 보장은 없습니다.
[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY위 내용은 규칙 순서만 설명합니다. example.com과 그 하위 도메인은 DIRECT로 연결하고, 나머지 요청은 FINAL에서 PROXY 정책을 기본값으로 사용합니다. 완전한 구성도 아니고 모든 사용자에게 권장하는 규칙도 아닙니다. 해당 도메인이 앞쪽의 REJECT 규칙에 먼저 걸렸다면 DNS를 바꿔도 규칙 적용 결과는 대개 달라지지 않습니다.
| 비교할 증상 | 우선 확인할 항목 | 다음 단계 |
|---|---|---|
| Proxy에서는 접속되지만 Config에서는 안 됨 | 현재 구성의 규칙, 정책 및 관련 재정의 설정 | 해당 도메인에 적용된 규칙과 실제 출구를 확인하세요. 원인을 곧바로 DNS로 단정하지 마세요. |
| 같은 구성이 네트워크에 따라 다르게 작동함 | 네트워크 인증, 리졸버 연결 가능 여부, UDP 및 주소 체계 경로 | URL과 출구 항목은 그대로 두고 연결 네트워크만 바꾼 뒤 차이를 기록하세요. |
| A와 AAAA 레코드는 반환되지만 일부 연결이 시간 초과됨 | IPv4와 IPv6의 실제 연결 가능 여부 | 실패한 연결에 사용된 주소 체계를 확인한 다음 한 가지 조건만 바꿔 비교하세요. |
| 메인 페이지는 열리지만 이미지 또는 로그인이 실패함 | 리소스 하위 도메인과 해당 규칙, DNS 조회 및 출구 | 실패한 리소스의 도메인을 기록하고 하나씩 확인하세요. 메인 사이트 도메인만 테스트해서는 안 됩니다. |
A 레코드는 IPv4 주소를, AAAA 레코드는 IPv6 주소를 제공합니다. DNS가 AAAA 레코드를 정상적으로 반환해도 현재 네트워크에서 IPv6 경로를 사용할 수 있다는 뜻은 아닙니다. IPv6 주소가 보인다고 해서 반드시 IPv6가 문제의 원인인 것도 아닙니다. 비교 결과가 주소 체계 차이를 가리킬 때만 관련 IPv6 설정을 확인하고 복구 방법을 마련해 두세요.
놓치기 쉬운 또 다른 요소는 캐시입니다. 브라우저, 시스템, 중간 리졸버가 결과를 저장할 수 있어 DNS를 바꾼 뒤 새로고침해도 새 조회가 발생했다고 볼 수 없습니다. 먼저 연결을 다시 설정하고 페이지를 새로 연 다음 새 요청 기록을 확인하세요. 모든 브라우징 데이터를 지우는 것부터 시작하지 마세요.
6. 자주 묻는 질문과 설정 복구 확인
지연 시간이 수십 밀리초에 불과한데 왜 출구 연결도 확인해야 하나요?
지연 시간은 임의의 웹사이트에서 전체 요청이 완료되는지 보여주지 않습니다. Home으로 돌아가 선택된 항목을 확인하고 실패한 URL의 연결 단계를 기록하세요. 테스트 대상에 접속할 수 있어도 대상 웹사이트의 443번 포트에는 연결할 수 없는 경우가 있습니다.
URL을 IP 주소로 바꾸면 DNS 문제인지 확인할 수 있나요?
그렇게 단정할 수 없습니다. HTTPS는 인증서 확인과 가상 호스트 선택에 도메인을 사용하므로 IP 주소로 직접 접속하면 인증서 오류가 나거나 다른 사이트가 표시될 수 있습니다. IP 접속 실패를 DNS 문제의 근거로 삼지 말고 DNS 조회와 연결 기록을 확인하세요.
DNS를 바꿨는데도 열리지 않습니다. 계속 바꿔야 하나요?
먼저 주소를 이미 얻었는지 확인하세요. 주소를 얻은 뒤 시간 초과가 발생했다면 DNS를 원래대로 복구하고 Global Routing, 실제 출구, Port를 확인하세요. DNS 조회 자체가 시간 초과됐다면 리졸버 전송 경로를 살펴보세요.
구독 업데이트만 실패하고 웹페이지는 정상입니다. DNS를 바꿔야 하나요?
먼저 구독 도메인 조회 실패와 HTTP 상태 오류를 구분하세요. 링크는 이용 중인 서비스 제공자에게 받고, 전체가 제대로 복사됐는지와 유효한 상태인지 확인합니다. 웹페이지가 정상이어도 구독 주소가 정상이라고 볼 수는 없지만, 전역 DNS에 문제가 있다는 증거도 아닙니다.
복구 후에는 평소 사용하는 Config와 예상한 정책으로 되돌리고 기존 On Demand 조건도 복원하세요. 그런 다음 메인 페이지, 이미지, 로그인 등 필요한 리소스를 다시 테스트합니다. Proxy로 임시 전환했을 때만 성공한다면 규칙을 계속 점검하세요. 임시 비교 결과를 DNS 원인을 찾았다는 근거로 삼아서는 안 됩니다.
- 사용 가능 여부를 확인한 구성 백업을 보관하고 마지막에 변경한 항목이 무엇인지 기록하세요.
- 서비스 제공자에게 문의할 때는 시간, 네트워크 유형, 프로토콜, 대상 도메인, 오류 문구를 전달하세요.
- 로그를 공유하기 전에 구독 token, UUID, 비밀번호와 전체 인증 정보를 가리세요. 구독 링크 전체를 공개할 필요는 없습니다.