규칙은 먼저 이름을 보거나 주소를 봅니다. 두 DNS는 두 답을 냅니다.

기기 자체에 시스템 DNS가 있습니다(통신사, 라우터, 또는 설정에 적은 서버). Shadowrocket은 구성에서 자체 DNS도 지정할 수 있고 암호화 쿼리도 포함합니다. 둘이 동시에 있을 때 어떤 쿼리가 어느 쪽을 타는지는 현재 구성에 따르며 「두 결과의 평균」이 아닙니다.

시스템 DNS와 앱 안 DNS가 다른 재귀를 가리키고 같은 이름에 다른 주소를 주면 규칙 안 GEOIP도 따라갑니다. 같은 호스트명이 한 번은 CN에 맞고 한 번은 FINAL로 떨어집니다. 규칙 파일이 고쳐진 것이 아니라 목적지가 바뀐 것입니다.

가를 때는 한 번에 한 곳만 바꿉니다. 먼저 Direct 아래 시스템 해석이 되게 한 뒤(포털 페이지, 기기 방문) 터널을 엽니다. 앱 안 DNS가 틀리거나 도달 불가면 해석에 의존하는 요청이 모두 실패하고 스위치는 켜진 채일 수 있습니다. 레코드를 여러 번 바꾸는 것보다 Data로 바이트가 있는지를 보는 편이 빠릅니다.

브라우저는 보통 호스트명(Host / SNI)과 해석된 주소를 모두 가지므로 도메인 줄과 주소 줄 모두 맞을 기회가 있습니다. 그래도 위에서 먼저 맞은 한 줄입니다.

앱이 IP로 바로 붙거나 SNI를 빼면 도메인 줄은 모두 빗나가고 IP-CIDR, GEOIP, FINAL에만 떨어질 수 있습니다. 그러면 「같은 사이트에서 Safari는 프록시, 어떤 클라이언트는 직통」이 됩니다. 두 프로그램이 엔진에 넘긴 정보가 다릅니다. 규칙 페이지 「호스트명은 어디서 오는가」를 보세요.

SNI는 example.com, 실제로 붙는 것은 CDN의 다른 주소: 도메인 줄은 example.com으로 맞추고 GEOIP는 CDN 주소로 분류합니다. 도메인 줄이 GEOIP보다 앞에 있고 이미 맞았으면 GEOIP는 묻히지 않습니다. 도메인 줄이 빗나가면 보이는 것은 CDN 라이브러리이지 그 이름에 대한 인상이 아닙니다.

IP-CIDR,10.0.0.0/8,DIRECT는 IPv6를 다루지 않습니다. 기기가 fd00:: 또는 글로벌 IPv6로 같은 서비스에 가면 이 줄은 안 맞고 요청은 GEOIP나 FINAL까지 떨어집니다. Wi-Fi가 IPv6를 주고 셀룰러가 안 주면 같은 규칙이 두 망에서 다르게 보입니다.

두 주소족을 다루려면 IP-CIDR6를 더하거나 쓰지 않는 쪽을 설정에서 끄세요. 주소족 문제를 「같은 도메인 DIRECT를 한 줄 더」로 고치지 마세요. 도메인 줄은 「주소만 있고 이름이 없는」 요청에 도움이 되지 않습니다.

일부 구성은 도메인을 먼저 로컬 또는 가짜 주소 묶음으로 해석한 뒤 터널 안에서 진짜 목적지로 바꿉니다. 그때 IP-CIDR / GEOIP가 보는 것은 매핑 후 주소이지 사이트의 공중망 주소가 아닙니다. GEOIP 국가 코드 줄은 그런 주소에 의미가 없고 결과는 모두 다른 줄로 떨어집니다.

목록이 GEOIP에 크게 의존하고 해석 방침을 가짜 주소로 바꾸면 분기가 통째로 어긋납니다. 해석 모드를 바꾸는 것은 규칙이 먹는 입력을 바꾸는 것이지 작은 옵션이 아닙니다. 바꾸기 전에 고정 레코드와 Proxy 정책으로 출구 자체가 되는지 확인하세요. Data입니다.

기기의 hosts형 매핑이 영향을 주는 것은 적어 둔 이름뿐입니다. 안 적은 이름은 현재 DNS를 탑니다. 매핑 표로 규칙 파일을 대신하지 마세요.