HTTP 규칙

4가지 HTTP 수준 규칙 유형이 있습니다. USER-AGENT와 URL-REGEX는 클라이언트가 Chute의 HTTP 프록시 리스너로 보내는 요청을 읽으므로, 그곳으로 들어오는 연결에만 일치합니다. TUN이나 SOCKS5를 거치는 연결에는 읽을 HTTP 요청이 없습니다. 이 두 규칙은 클라이언트 연결마다 한 번, 그 연결의 첫 요청으로 판정됩니다. MitM 복호화는 연결의 정책이 선택된 뒤에 시작되므로, 복호화된 요청은 규칙과 다시 대조되지 않습니다. PROTOCOL,TCP와 PROTOCOL,UDP는 전송 계층을 읽으므로 어떤 인바운드에서도 일치합니다. PROTOCOL의 응용 프로토콜 값은 TUN 인바운드의 프로토콜 스니핑에서, 그리고 HTTP 프록시 인바운드로 들어온 일반 요청에서 나옵니다. SCRIPT는 모든 연결에 대해 평가됩니다.

USER-AGENT

USER-AGENT,Instagram*,DIRECT

요청의 User-Agent가 일치하면 규칙이 일치합니다. 와일드카드 문자 * 및 ?가 지원됩니다. 헤더는 HTTP 프록시 리스너로 들어온 각 클라이언트 연결의 첫 요청에서 읽습니다. HTTPS의 경우 그 요청은 클라이언트가 터널을 열 때 보내는 CONNECT이므로, 규칙은 클라이언트가 CONNECT에 User-Agent를 붙였다면 그 값을 봅니다.

URL-REGEX

URL-REGEX,^http://google\.com.*,DIRECT

HTTP 프록시 리스너로 들어온 일반 HTTP 요청의 URL이 정규식과 일치하면 규칙이 일치합니다. URL은 완전한 형태 — http://host[:port]/path?query, 포트가 80이면 생략 — 로 쓰이며, 정규식은 부분 문자열이 아니라 URL 전체와 일치해야 합니다. ^http://google\.com만 쓰면 http://google.com/에도 일치하지 않습니다. 경로도 URL의 일부이기 때문입니다. CONNECT 터널(HTTPS, 또는 클라이언트가 터널로 보내는 그 밖의 모든 것)과 TUN 연결에는 URL이 없으므로 URL-REGEX는 이들과 결코 일치하지 않으며, MitM으로 HTTPS 연결을 복호화해도 이는 달라지지 않습니다. HTTP 제어 API의 규칙 일치 시험인 POST /api/rules/match는 url 필드를 보낸 그대로 URL-REGEX와 대조하므로, 전체 URL을 넣으세요.

PROTOCOL

PROTOCOL,TLS,Proxy

연결의 감지된 프로토콜이 일치하면 규칙이 일치합니다. 최상의 결과를 위해 sniffing-enabled와 함께 사용하세요. NETWORK는 PROTOCOL의 별칭으로 허용됩니다.

허용되는 프로토콜 값: HTTP, HTTPS, TLS, TCP, UDP, QUIC, STUN, MTPROTO, DNS, DOH, DOH3, DOQ, DOT.

주의: 감지된 프로토콜은 다음 위치에서 채워집니다. TUN 인바운드 세션에서는 sniffing-enabled가 켜져 있을 때, Chute가 호스트 이름을 아직 모르는 경우에만 TCP 연결이 HTTP 또는 TLS(HTTPS를 포함한 모든 TLS 연결)로 스니핑됩니다. 가짜 IP로, 또는 Chute DNS가 해석한 주소로 열린 연결은 그 이름을 유지하며 스니핑되지 않으므로, Chute가 이름을 해석한 TUN 트래픽에는 PROTOCOL,HTTP와 PROTOCOL,TLS가 거의 일치하지 않습니다. UDP 흐름은 TUN을 거치든 SOCKS5 인바운드의 UDP 릴레이를 거치든 패킷의 형태를 보고 QUIC으로 감지되며, sniffing-enabled가 필요하지 않습니다. sniffing-enabled가 켜져 있으면 Chute는 QUIC 흐름의 Initial 패킷에서 서버 이름도 읽으므로 DOMAIN 계열 규칙도 그 흐름과 일치할 수 있습니다(기타 옵션의 sniffing-enabled 참조). HTTP 프록시 인바운드에서는 CONNECT가 아닌 일반 요청이 스니핑 없이 그대로 HTTP입니다. 요청 헤더를 방금 연결에서 파싱했기 때문입니다. CONNECT는 프로토콜을 설정하지 않은 채로 두고, SOCKS5 인바운드의 TCP 연결은 프로토콜을 전혀 얻지 못합니다. 다만 PROTOCOL,TCP와 PROTOCOL,UDP는 세션의 전송 계층을 읽고 이는 모든 인바운드가 채우므로, 그 두 값은 거기서도 일치합니다. encrypted-dns-follow-outbound-mode = true(DNS 서버 참조)이면 Chute 자체의 암호화된 DNS 업스트림 연결이 DOH, DOT, DOQ, DOH3로 일치합니다. 네 가지 모두 규칙이 지정한 정책을 사용하고(DoQ와 DoH3는 그 UDP 릴레이를 거치며, UDP를 나르지 않는 정책이면 udp-policy-not-supported-behaviour를 따릅니다), REJECT 판정은 네 가지 모두를 건너뜁니다. HTTPS는 스니핑된 TLS 핸드셰이크를 가리키는 또 다른 표기이므로, PROTOCOL,HTTPS와 PROTOCOL,TLS는 같은 트래픽에 일치합니다. STUN, MTPROTO, DNS는 호환성을 위해 허용되지만, 아직 어떤 감지기도 이를 생성하지 않습니다.

SCRIPT

SCRIPT,MyRuleScript,DIRECT

규칙은 사용자 정의 일치 로직을 위해 JavaScript 스크립트를 평가합니다. 스크립트 이름은 type=rule로 [Script] 섹션에 정의된 스크립트와 일치해야 합니다.

[Rule]
SCRIPT,CheckInternal,PROXY

[Script]
CheckInternal = type=rule, script-path=internal-check.js

규칙 스크립트는 $request를 받고 $done({matched: true}) 또는 $done({matched: false})를 호출해야 합니다. $request.dnsResult는 세션이 이미 해석된 경우(예: IP 주소로 직접 보낸 요청, 또는 DNS 해석 후의 두 번째 일치 패스)에만 사용할 수 있다는 점에 유의하세요.