리라이트가 바꾸는 것은 요청의 모습이지, 어느 길로 갈지가 아닙니다.

Config 모드에서 엔진은 먼저 규칙으로 이 연결의 동작을 정합니다. REJECT 연결은 리라이트로 넘어가지 않습니다. 이미 버려졌습니다. DIRECT와 PROXY 연결이 리라이트 줄에 맞을 때만 리라이트 뒤의 URL 또는 헤더로 이어갑니다.

따라서 페이지가 연 것은 A 사이트인데 규칙은 B로 썼다고 생각하면, 먼저 규칙이 맞았는지를 보고, 그다음 리라이트가 경로를 다른 곳으로 바꿨는지를 봅니다. Data는 바이트가 Direct인지 Proxy인지만 말하며, URL이 무엇으로 바뀌었는지는 말하지 않습니다.

정책이 Proxy 또는 Direct이면 규칙 파일은 건너뜁니다. 리라이트가 여전히 실행되는지는 현재 버전과 스위치에 따르며, 「분기를 끄면 리라이트도 꺼진다」고 가정하지 마세요. 가를 때 순수 출구만 보려면 리라이트도 먼저 멈추고, 한 번에 남기는 변수는 하나입니다.

리라이트 줄에도 순서가 있습니다. 먼저 맞은 한 줄이 효력을 냅니다. 더 구체적인 패턴을 더 넓은 것 앞에 쓰는 것은 규칙과 같습니다. 주석과 빈 줄의 처리는 앱 안 편집기를 따릅니다.

외부 구성은 긴 리라이트를 붙이는 경우가 많습니다. 내용 수준 수정이 필요 없으면 규칙만 남기고 리라이트를 꺼 「같은 호스트가 어떤 때는 정상이고 어떤 때는 건너뛰어지는」 원인을 줄일 수 있습니다.

호스트명, SNI, 목적지는 복호화를 켜지 않아도 규칙에서 쓸 수 있습니다. 리라이트가 URL의 평문 부분이나 일부 헤더만 움직이면 HTTPS 복호화가 필수는 아닙니다.

HTTPS의 경로와 본문을 보거나 바꾸려면 사용자 프로파일을 넣어 기기 위 확장을 중간자로 만들어야 합니다. 이 기기의 인증서 신뢰 모델이 바뀝니다. 대가와 언제 빼야 하는지는 시스템입니다.

복호화가 효력이 없을 때 HTTPS 본문용 리라이트는 일어나지 않고 연결이 바로 실패할 수 있습니다. 먼저 복호화를 끄고 방문하세요. 돌아오면 문제는 인증서와 목록이지 레코드가 아닙니다. 분기를 「더 정확히」 하려고 복호화를 켜지 마세요.

일부 버전은 스크립트를 제공해 한 줄 치환보다 복잡한 리라이트를 요청 또는 응답에 합니다. 그래도 규칙 엔진이 아닙니다. FINAL을 맡지 않고 Config / Proxy / Direct를 대신하지도 않습니다.

스크립트 실패의 모습은 어떤 한 번 요청의 이상이지 스위치가 되돌아가는 것이 아닙니다. 가르는 순서는 그대로입니다. Direct에서 로컬 망, Proxy에서 레코드, Config에서 규칙, 마지막에 리라이트와 스크립트입니다. 외부 스크립트와 외부 규칙을 동시에 열면 귀속 비용이 몇 배가 됩니다.