قاعدة HTTP

هناك 4 أنواع من القواعد على مستوى HTTP. تقرأ 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 للطلب. أحرف البدل * و ? مدعومة. تُقرأ الترويسة من أول طلب في كل اتصال عميل بمستمع بروكسي HTTP؛ وفي HTTPS يكون ذلك الطلب هو CONNECT الذي يفتح به العميل نفقه، فترى القاعدة User-Agent الذي يضعه العميل على CONNECT إن أرسله.

URL-REGEX

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

تطابق القاعدة إذا تطابق رابط طلب HTTP عادي يصل إلى مستمع بروكسي HTTP مع التعبير النمطي. يُكتب الرابط كاملاً — http://host[:port]/path?query، مع حذف المنفذ حين يكون 80 — ويجب أن يطابق التعبير النمطي الرابط الكامل، وليس جزءاً منه فقط: فـ ^http://google\.com وحده لا يطابق http://google.com/، لأن المسار جزء من الرابط. أما نفق CONNECT (HTTPS، أو أي شيء آخر يمرّره العميل عبر نفق) واتصال TUN فلا رابط لهما، لذا لا تطابقهما URL-REGEX أبداً، ولا يغيّر فك تشفير اتصال HTTPS عبر MitM ذلك. أما تجربة مطابقة القواعد دون تنفيذ، أي POST /api/rules/match في HTTP Control API، فتطابق 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، يُستكشف اتصال 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)، تُطابَق اتصالات Chute نفسه بخوادم DNS المشفرة على أنها DOH وDOT وDOQ وDOH3: تستخدم الأربعة عندئذ السياسة التي تسميها القاعدة — DoQ وDoH3 عبر ترحيل UDP الخاص بها، ويحسم udp-policy-not-supported-behaviour الأمر حين لا تحمل UDP — ويؤدي قرار 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 يتوفر فقط عندما تكون الجلسة قد حُلّت بالفعل (على سبيل المثال، الطلبات الموجهة مباشرة إلى عنوان IP، أو مرحلة المطابقة الثانية بعد تحليل DNS).