กฎ HTTP

มีกฎระดับ HTTP 4 ประเภท USER-AGENT และ URL-REGEX อ่านคำขอที่ไคลเอนต์ส่งมายังตัวรับฟังพร็อกซี HTTP ของ Chute ดังนั้นจึงจับคู่เฉพาะการเชื่อมต่อที่เข้ามาทางนั้นเท่านั้น การเชื่อมต่อที่ผ่าน TUN หรือ SOCKS5 ไม่มีคำขอ HTTP ให้อ่าน กฎทั้งสองจะถูกตัดสินครั้งเดียวต่อการเชื่อมต่อของไคลเอนต์หนึ่งรายการ จากคำขอแรกของการเชื่อมต่อนั้น การถอดรหัส MitM เริ่มขึ้นหลังจากเลือกนโยบายของการเชื่อมต่อแล้ว ดังนั้นคำขอที่ถูกถอดรหัสจะไม่ถูกนำมาจับคู่กับกฎอีก ส่วน PROTOCOL,TCP และ PROTOCOL,UDP อ่านชั้นขนส่งจึงจับคู่ได้กับทุกขาเข้า ขณะที่ค่าโปรโตคอลระดับแอปพลิเคชันของ PROTOCOL มาจากการดมกลิ่นโปรโตคอลของขาเข้าแบบ TUN และจากคำขอธรรมดาบนขาเข้าแบบพร็อกซี HTTP ส่วน SCRIPT จะถูกประเมินสำหรับการเชื่อมต่อใด ๆ

USER-AGENT

USER-AGENT,Instagram*,DIRECT

กฎจะจับคู่หาก user agent ของคำขอตรงกัน รองรับอักขระ wildcard * และ ? ส่วนหัวจะถูกอ่านจากคำขอแรกของการเชื่อมต่อของไคลเอนต์แต่ละรายการที่เข้ามายังตัวรับฟังพร็อกซี HTTP สำหรับ HTTPS คำขอนั้นคือ CONNECT ที่ไคลเอนต์ใช้เปิดทันเนล ดังนั้นกฎจะเห็น User-Agent ที่ไคลเอนต์ใส่ไว้ใน CONNECT หากไคลเอนต์ส่งมา

URL-REGEX

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

กฎจะจับคู่หาก URL ของคำขอ HTTP ธรรมดาที่เข้ามาทางตัวรับฟังพร็อกซี HTTP ตรงกับนิพจน์ปกติ URL จะถูกเขียนแบบเต็ม — http://host[:port]/path?query โดยละพอร์ตไว้เมื่อเป็นพอร์ต 80 — และนิพจน์ปกติต้องตรงกับ URL ทั้งหมด ไม่ใช่เพียงบางส่วน: ^http://google\.com เพียงลำพังจะไม่จับคู่ http://google.com/ เพราะพาธเป็นส่วนหนึ่งของ URL ทันเนล CONNECT (HTTPS หรือสิ่งอื่นใดที่ไคลเอนต์ส่งผ่านทันเนล) และการเชื่อมต่อ TUN ไม่มี URL ดังนั้น URL-REGEX จะไม่มีวันจับคู่กับสิ่งเหล่านี้ และการถอดรหัสการเชื่อมต่อ HTTPS ด้วย MitM ก็ไม่ได้เปลี่ยนข้อนี้ การทดลองจับคู่กฎ POST /api/rules/match บน HTTP Control API จะจับคู่ 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 (การเชื่อมต่อ TLS ใด ๆ รวมถึง HTTPS) ก็ต่อเมื่อ Chute ยังไม่รู้ชื่อโฮสต์ของการเชื่อมต่อนั้นเท่านั้น: การเชื่อมต่อที่เปิดไปยัง IP ปลอม หรือไปยังที่อยู่ที่ DNS ของ Chute แปลงชื่อให้ จะคงชื่อนั้นไว้และไม่ถูกตรวจจับ ดังนั้น PROTOCOL,HTTP และ PROTOCOL,TLS จึงแทบไม่ตรงกับทราฟฟิก TUN ที่ Chute เป็นผู้แปลงชื่อ โฟลว์ UDP จะถูกตรวจพบเป็น QUIC โดยอัตโนมัติจากรูปแบบของแพ็กเก็ต — ทั้งผ่าน TUN และผ่านการรีเลย์ UDP ของขาเข้าแบบ SOCKS5 — โดยไม่ต้องใช้ sniffing-enabled เมื่อเปิด sniffing-enabled Chute ยังอ่านชื่อเซิร์ฟเวอร์จากแพ็กเก็ต Initial ของโฟลว์ QUIC ด้วย ทำให้กฎประเภท DOMAIN จับคู่โฟลว์นั้นได้เช่นกัน (ดู sniffing-enabled ในตัวเลือกเบ็ดเตล็ด) ส่วนบนขาเข้าแบบพร็อกซี HTTP คำขอธรรมดา (ที่ไม่ใช่ CONNECT) จะเป็น HTTP โดยไม่ต้องตรวจจับอะไรเลย เพราะส่วนหัวคำขอของมันเพิ่งถูกแยกวิเคราะห์ออกมาจากการเชื่อมต่อ ส่วน CONNECT จะไม่กำหนดโปรโตคอลไว้ และการเชื่อมต่อ TCP บนขาเข้าแบบ SOCKS5 ไม่เคยได้รับค่าโปรโตคอลเลย — แต่ PROTOCOL,TCP และ PROTOCOL,UDP อ่านชั้นขนส่งของเซสชัน ซึ่งทุกขาเข้ากำหนดค่าให้ ดังนั้นสองค่านี้จึงจับคู่ที่นั่นได้ด้วย เมื่อตั้ง encrypted-dns-follow-outbound-mode = true (ดูเซิร์ฟเวอร์ DNS) การเชื่อมต่อต้นทาง DNS แบบเข้ารหัสของ Chute เองจะถูกจับคู่เป็น 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 สำหรับตรรกะการจับคู่ที่กำหนดเอง ชื่อสคริปต์ต้องตรงกับสคริปต์ที่กำหนดในส่วน [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 จะพร้อมใช้งานเฉพาะเมื่อเซสชันแปลงชื่อ DNS แล้วเท่านั้น (เช่น คำขอที่ส่งไปยังที่อยู่ IP โดยตรง หรือรอบการจับคู่ที่สองหลังการแปลงชื่อ DNS)