순서 있는 목록입니다. 먼저 맞은 한 줄이 정합니다.

규칙을 아무리 갖춰도 정책이 Proxy면 송신은 모두 현재 레코드로 들어가고, Direct면 모두 원래 경로입니다. 파일이 「스스로 열리지는」 않습니다. 정책을 Config로 되돌린 뒤에야 지금 고른 구성이 한 줄씩 맞추기 시작합니다. 정책 세 항의 뜻은 터널에 있습니다.

구성 파일은 여러 개를 둘 수 있습니다. 연결 때 쓰는 것은 지금 고른 하나뿐입니다. 서버 레코드는 다른 오브젝트입니다. 하이라이트 행을 바꿔도 파일은 바뀌지 않고, 파일을 바꿔도 하이라이트 행은 바뀌지 않습니다. 구성에 무엇이 적혀 있는지와 목록에서 지금 하이라이트된 출구는 독립된 두 가지입니다. 오브젝트와 Config를 보세요.

그래서 「규칙이 안 먹힌다」에는 전혀 다른 두 뜻이 있습니다. 하나는 엔진이 애초에 물리지 않은 것입니다(정책이 Config가 아니거나, 고른 것이 생각하던 파일이 아님). 다른 하나는 물렸지만 먼저 맞은 줄이 생각하던 줄이 아닌 것입니다. 가를 때는 전자를 먼저 확인하고, 그다음 후자를 고칩니다.

흔한 쓰기는 조건 유형, 인자, 동작입니다. 쉼표로 나눕니다. 유형과 인자가 「이 줄이 누구를 다루는가」를 정하고, 동작이 「다룬 뒤 어떻게 하는가」를 정합니다. 행 머리가 #인 줄은 주석이며 엔진은 건너뛰고 맞춤에 참여하지 않습니다.

# 주석은 맞춰지지 않습니다
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,10.0.0.0/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

송신을 정말로 바꾸는 동작은 셋뿐입니다. DIRECT(원래 경로), PROXY(지금 하이라이트된 레코드), REJECT(막고 보내지 않음). 어떤 파일은 정책 그룹 이름을 적어 동작을 다른 선택 논리로 돌립니다. 이 페이지가 다루는 것은 이 세 직접 동작뿐입니다. 유형을 틀리거나, 쉼표를 빠뜨리거나, URI 전체를 규칙 줄에 붙이면 그 줄은 기대한 대로 움직이지 않고 요청은 아래로 계속 떨어집니다.

같은 파일에 도메인 조건과 주소 조건을 섞을 수 있습니다. 엔진은 연결마다 목록을 한 번만 걷고 「도메인에서 한 번 맞고, IP에서 또 맞아 합친다」고 하지 않습니다. 먼저 맞은 줄이 이미 동작을 냈고, 뒤의 줄은 보지 않습니다.

맞춤은 위에서 아래입니다. 어떤 줄이 맞은 뒤 뒤의 줄은 보지 않습니다. 그래서 예외는 통칙보다 앞에 씁니다. FINAL을 파일 중간에 두면 그 아래 모든 줄이 무효입니다. 파일에는 남아 있지만 물리지 않습니다.

아래 두 목록은 줄이 완전히 같고 순서만 뒤바뀌었으며 결과는 반대입니다.

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

# B: 먼저 접미사. api 줄에는 영원히 닿지 않습니다
DOMAIN-SUFFIX,example.com,DIRECT
DOMAIN,api.example.com,PROXY
FINAL,PROXY

api.example.com에서는 목록 A가 첫 줄에 맞아 레코드로 가고, 목록 B는 접미사에 맞아 직통입니다. www.example.com에서는 둘 다 접미사에서 직통입니다. unrelated.org에서는 둘 다 FINAL로 떨어져 레코드로 갑니다.

KEYWORD는 SUFFIX보다 넓고, GEOIP는 대부분의 도메인 줄보다 넓고, FINAL이 가장 넓습니다. 안정된 순서는 구체 호스트 → 접미사 / 키워드 → 구간 → GEOIP → FINAL입니다. 문법 요구가 아니라 예외가 보이도록 두는 방식입니다.

접미사 줄은 그 접미사의 서브도메인 이외의 이름을 자동으로 덮지 않습니다. DOMAIN-SUFFIX,google.com,PROXY를 써도 gstatic.com, youtube.com, googleapis.com은 대상이 되지 않습니다. 그것들은 다른 등록 도메인입니다. 각각 쓰거나, 뒤의 GEOIP / FINAL로 떨어지는 것을 받아들입니다.

대소문자는 도메인 관례대로 구분하지 않습니다. 국제 도메인이 규칙에 Unicode로 나오고 실제 요청이 punycode(xn--)이면 양쪽이 맞지 않아 그 줄은 맞지 않습니다. 가를 때는 규칙 파일에 실제로 적은 바이트를 기준으로 하세요.

일부 IP 줄은 no-resolve 같은 표시를 붙여, 이 줄을 맞추려고 도메인을 주소로 해석하지 말라는 뜻입니다. 해석 방침은 DNS 페이지의 DNS 설정과도 서로 영향을 줍니다. 규칙이 호스트명만 보고 주소를 못 보면 주소 줄은 모두 빗나갑니다. 주소만 보고 호스트명을 못 보면 도메인 줄은 모두 빗나갑니다.

직통이어야 할 시스템 서비스를 PROXY로 쓰면 푸시, 사진 동기화, 스토어 업데이트가 느려지거나 실패하기 쉽습니다. 그것들을 위한 출구가 아닌 곳으로 보내지기 때문입니다. 레코드로 넣어야 할 호스트를 DIRECT로 쓰면 Data는 Direct만 늘고 페이지는 「프록시를 안 연 것」처럼 보입니다. 호스트를 REJECT로 쓰면 앱이 네트워크 오류를 내 노드가 죽은 것으로 오인하기 쉽습니다.

동작을 바꾸기 전에 그 줄이 정말 맞을지를 확인하세요. 한 번도 닿지 않는 규칙을 고쳐도 화면은 바뀌지 않습니다. Data로 카운터가 어느 쪽에 서는지를 보는 편이 스위치를 반복하는 것보다 효력이 있습니다.

도메인 조건은 해석 결과, HTTP의 Host, 또는 TLS의 Server Name Indication에 따릅니다. 앱이 IP에 직접 연결하거나 SNI를 붙이지 않으면 규칙은 주소만 보고 도메인 줄은 모두 빗나가, 마지막은 IP-CIDR, GEOIP 또는 FINAL에 떨어집니다.

그것이 「같은 사이트가 어떤 때는 프록시, 어떤 때는 직통」의 한 원인입니다. 호스트명을 가진 요청과 IP만 남은 요청이 있습니다. 브라우저 주소 표시줄은 www.example.com이어도 하층은 먼저 CDN 주소에 연결할 수 있습니다. GEOIP가 보는 것은 그 CDN의 라이브러리이지 그 이름에 대한 인상이 아닙니다.

시스템 DNS와 앱 안 DNS를 각각 설정하고 서로 모순되면 규칙이 보는 호스트명과 진짜 목적지가 어긋납니다. 해석에 이상이 없을 때 두 곳을 동시에 고치지 마세요. 세부는 DNS입니다.

리라이트는 요청이 이미 보인 뒤에 일어나며, 규칙 대신 어느 길로 갈지를 정하지 못합니다. 먼저 분기하고, 그다음 리라이트합니다. HTTPS 내용 수준의 리라이트에는 추가 복호화 인가가 필요합니다. 시스템을 보세요.

현재 정책이 Config이고, 파일이 아래이며, 지금 하이라이트된 것이 쓸 수 있는 레코드 하나라고 합니다.

DOMAIN-SUFFIX,apple.com,DIRECT
DOMAIN-SUFFIX,icloud.com,DIRECT
DOMAIN-SUFFIX,github.com,PROXY
IP-CIDR,10.0.0.0/8,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

앱은 여러 구성을 저장할 수 있고, 연결 때 달리는 것은 지금 고른 하나뿐입니다. 하나에서 다른 하나로 바꾸는 것은 목록 전체의 치환이며 「두 FINAL이 겹친다」가 아닙니다. 남의 목록을 가져오기 전에 그 FINAL과 GEOIP를 찾으세요. 이 두 줄이 지명되지 않은 대부분의 트래픽의 운명을 정합니다.

레코드가 이미 잘 닿는 사이트 대부분과 같은 쪽에 있고 소수 호스트만 보내고 싶은데 FINAL을 PROXY로 두면 무관한 요청이 대량으로 노드에 들어갑니다. 레코드가 다른 쪽에 있고 지명되지 않은 것도 보내고 싶은데 FINAL을 DIRECT로 두면 대부분의 사이트는 노드에 들어가지 않습니다. 외부 목록의 저자는 자기 출구에 맞춰 썼지 당신의 출구에 맞춰 쓰지 않았습니다.

목록은 만료됩니다. 구독형 규칙 새로고침과 서버 컨테이너 새로고침은 다른 오브젝트 위의 같은 종류의 동작입니다. 저장하는 것은 URL이고, 가져오기가 성공한 뒤에 로컬 파일을 바꾸며, 실패 때는 직전에 성공한 파일을 남기고 실패 때문에 규칙을 비우지 않습니다. 새로고침은 그때의 네트워크 경로를 타고, 스위치가 만료된 레코드에 연결되어 있으면 규칙 구독 자체도 새로고침에 실패할 수 있습니다. 오브젝트와 Config를 보세요.

한 번에 고치는 조건은 하나입니다. 고친 뒤 고정한 레코드 하나로 정책만 바꿔 대조합니다. Data입니다. 레코드와 파일과 FINAL을 동시에 바꾸면 화면의 변화를 귀속할 수 없습니다.