줄이 같아도 순서만 바꾸면 결과가 반대입니다.

규칙이 아무리 완전해도 정책이 Proxy면 송신은 모두 현재 레코드로 들어가고, Direct면 모두 원래 경로입니다. 파일이 「스스로 켜지지는」 않습니다. 정책을 Config로 되돌린 뒤에야 지금 고른 구성이 한 줄씩 맞추기 시작합니다. 정책 세 항의 뜻은 터널에 있습니다. 그래서 「규칙이 안 먹힌다」에는 전혀 다른 두 뜻이 있습니다. 하나는 엔진이 아예 묻히지 않은 것입니다. 다른 하나는 물었지만 먼저 맞은 줄이 생각한 줄이 아닌 것입니다. 대조에서는 전자를 먼저 확인하고 후자를 고칩니다.

구성 파일은 여러 개를 둘 수 있습니다. 연결 때 쓰는 것은 지금 고른 하나뿐입니다. 서버 레코드는 다른 오브젝트입니다. 하이라이트 행을 바꿔도 파일은 바뀌지 않고, 파일을 바꿔도 하이라이트 행은 바뀌지 않습니다. 구성에 무엇이 적혀 있는지와 목록에서 지금 하이라이트된 출구는 독립된 두 가지입니다. 오브젝트와 Config를 보세요. 제품 페이지의 도메인 테스터는 박아 넣은 견본 목록입니다. 「위에서 아래」만 보여 줍니다. GEOIP는 웹에서 흉내 낼 수 없습니다. 테스터 결과를 자기 폰의 분기로 삼으면 잘못된 결론이 납니다.

흔한 쓰기는 조건 유형, 인자, 동작입니다. 동작은 DIRECT, PROXY, REJECT입니다. 맞춤은 위에서 아래입니다. 어떤 줄이 맞은 뒤 뒤 줄은 보지 않습니다. 그래서 예외는 통례보다 앞에 씁니다. FINAL을 파일 중간에 두면 그 아래 모든 줄이 무효입니다. 파일에는 남아 있지만 영원히 묻히지 않습니다. 줄 형식과 조건 유형의 세부는 규칙 장에 있고, 아래에서는 순서 자체를 한 쌍의 맞바꿈으로 보입니다.

# A: 호스트를 먼저 지명하고 그다음 접미사
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,PROXY

# B: 접미사를 먼저
DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN,api.example.com,PROXY
FINAL,PROXY

api.example.com에서는 목록 A가 첫 줄에 맞아 레코드로 가고, 목록 B는 접미사에 맞아 직통입니다. www.example.com에서는 둘 다 접미사에서 직통입니다. 어느 쪽에도 지명되지 않은 호스트에서는 둘 다 FINAL로 떨어져 레코드로 갑니다. 차이는 「구체 줄과 넓은 줄 모두에 덮이는」 이름에서만 납니다. KEYWORD는 SUFFIX보다 넓고, GEOIP는 대부분의 도메인 줄보다 넓고, FINAL이 가장 넓습니다. 안정된 순서는 구체 호스트 → 접미사 / 키워드 → CIDR → GEOIP → FINAL입니다. 문법 요구가 아니라 예외가 보일 자리를 주기 위한 배치입니다.

DOMAIN은 호스트명 완전 일치입니다. DOMAIN-SUFFIX는 그 접미사와 같거나 「.접미사」로 끝나는 이름입니다. DOMAIN-KEYWORD는 그 문자열이 들어가기만 하면 됩니다. 접미사 줄은 다른 등록 도메인을 자동으로 덮지 않습니다. google.com을 적었다고 gstatic.com까지 다루지는 않습니다. IP-CIDR이 보는 것은 IPv4뿐입니다. IPv6 목적지는 이 줄을 보지 못하고 GEOIP나 FINAL까지 떨어집니다. IPv4 사설망만 보태고 기기가 같은 서비스를 IPv6로 쓰면 규칙이 「가끔 먹히는」 것처럼 보입니다. DNS를 보세요.

GEOIP는 목적지 IP의 지리 라이브러리 분류이지, 도메인 등록지도, 사이트 언어도 아닙니다. CDN이 같은 호스트명을 다른 나라 주소로 가리키면 GEOIP 결과도 따라갑니다. 규칙이 보는 이름도 주소창 문자열과 다를 수 있습니다. 앱이 IP로 바로 붙거나 SNI를 빼면 도메인 줄은 모두 빗나가고 주소 줄이나 FINAL에 떨어집니다. 그것이 「같은 사이트가 어떤 때는 프록시, 어떤 때는 직통」의 한 원인입니다. 두 요청이 엔진에 넘긴 정보가 다릅니다.

가져온 목록의 저자는 자기 출구에 맞춰 씁니다. FINAL이 PROXY인지 DIRECT인지가 지명되지 않은 트래픽 전체의 운명을 정하고, 도메인 줄을 백 줄 더하는 것보다 큽니다. 레코드가 이미 잘 닿는 사이트 대부분과 같은 쪽에 있고 소수 호스트만 보내려는데 FINAL을 PROXY로 쓰면 무관한 요청이 대량으로 노드에 들어갑니다. 레코드가 다른 쪽에 있고 지명되지 않은 것도 보내려는데 FINAL을 DIRECT로 쓰면 대부분의 사이트는 노드에 들어가지 않습니다.

한 번도 닿지 않는 규칙을 고쳐도 Data는 안 움직이고 페이지도 안 바뀝니다. 고정한 한 레코드로 정책만 바꿔 대조합니다. Proxy에서 그 호스트가 이미 열리면 Config로 돌아가 카운터가 어느 쪽에 서는지를 봅니다. 레코드와 파일과 FINAL을 동시에 바꾸면 매번 변화를 나머지 두 변수로 설명할 수 있습니다. 구독형 규칙 새로고침과 서버 컨테이너 새로고침은 다른 오브젝트 위의 같은 종류의 동작입니다. 실패 때는 직전에 성공한 파일을 남기고, 실패 때문에 규칙을 비우지 않습니다.

동작은 「연결된 정도」가 아닙니다. DIRECT는 원래 경로로 나가고, PROXY는 하이라이트 중인 레코드로 보내며, REJECT는 보내지 않습니다. 직통이어야 할 시스템 서비스를 PROXY로 쓰면 푸시나 스토어 업데이트가 느려지기 쉽습니다. 레코드로 넣어야 할 호스트를 DIRECT로 쓰면 Data는 Direct만 늘고, REJECT로 쓰면 앱이 네트워크 오류를 내 노드가 죽은 것으로 오인하기 쉽습니다. 동작을 바꾸기 전에 그 줄이 정말 맞을지를 확인하세요.

같은 연결이 엔진에 넘기는 정보도 빠질 수 있습니다. 브라우저는 보통 호스트명과 해석된 주소를 모두 가지므로 도메인 줄과 주소 줄 모두 맞을 기회가 있습니다. 그래도 먼저 맞은 줄입니다. IP만 붙고 SNI가 없는 클라이언트는 도메인 줄이 모두 빗나가고 IP-CIDR, GEOIP, FINAL에만 떨어질 수 있습니다. 그러면 「Safari는 프록시, 어떤 앱은 직통」이 됩니다. 두 프로그램이 엔진에 준 것이 다른 것이지 엔진이 무작위가 아닙니다. 대조할 때 도메인 줄만 고치지 말고 Data로 이번 바이트가 어느 쪽에 섰는지도 보세요. 홈 테스터는 도메인만 받습니다. 「주소만 있고 이름이 없는」 요청은 흉내 내지 못하고, 기기 위 지리 라이브러리 버전도 흉내 내지 못합니다.