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

リクエストのユーザーエージェントが一致する場合にルールがマッチします。ワイルドカード文字*と?がサポートされています。ヘッダーは、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全体にマッチする必要があります。パスもURLの一部なので、^http://google\.comだけではhttp://google.com/にマッチしません。CONNECTトンネル（HTTPS、またはクライアントがトンネルで送るその他のもの）とTUN接続にはURLがないため、URL-REGEXがこれらにマッチすることはなく、MitMでHTTPS接続を復号してもそれは変わりません。ルール照合のドライランであるHTTPコントロールAPIのPOST /api/rules/matchは、URL-REGEXを送られたままのurlフィールドと照合するため、完全な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が有効なとき、TCP接続がHTTPまたはTLS（HTTPSを含む任意のTLS接続）としてスニッフィングされるのは、Chuteがそのホスト名をまだ知らない場合だけです: フェイク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はセッションのトランスポートを読み、これはどのインバウンドでも設定されるため、その2つはそこでもマッチします。encrypted-dns-follow-outbound-mode = true（DNSサーバーを参照）の場合、Chute自身の暗号化DNSアップストリーム接続がDOH、DOT、DOQ、DOH3としてマッチング対象になります。4つともルールが指定するポリシーを使い（DoQとDoH3はそのUDPリレーを通り、UDPを運ばないポリシーではudp-policy-not-supported-behaviourに従います）、REJECTの判定はこの4つのいずれもスキップします。HTTPSはスニッフィングされたTLSハンドシェイクの別表記なので、PROTOCOL,HTTPSとPROTOCOL,TLSは同じトラフィックにマッチします。STUN、MTPROTO、DNSは互換性のために受け付けられますが、まだどの検出器も生成しません。

SCRIPT

SCRIPT,MyRuleScript,DIRECT

カスタムマッチングロジックのためにJavaScriptスクリプトを評価します。スクリプト名は[Script]セクションでtype=ruleで定義されたスクリプトと一致する必要があります。

[Rule]
SCRIPT,CheckInternal,PROXY

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

ルールスクリプトは$requestを受け取り、$done({matched: true})または$done({matched: false})を呼び出す必要があります。$request.dnsResultは、セッションが既に解決されている場合（例えば、IPアドレスに直接送信されたリクエストや、DNS解決後の2回目のマッチングパス）にのみ利用可能であることに注意してください。