خادم البروكسي

يوجّه خادم البروكسي الطلبات إلى بروكسي منبع. يدعم Chute بروتوكولات البروكسي HTTP/HTTPS/SOCKS5/SOCKS5-TLS/SS/SSR/Trojan/VMess/VLESS/AnyTLS/TUIC/Hysteria2/WireGuard/AmneziaWG/ShadowTLS/MASQUE/SSH.

يعلن القسم [Proxy] عن خوادم البروكسي. يمكنك إنشاء عدة خوادم بروكسي لقواعد مختلفة.

مثال:

[Proxy]
ProxyHTTP = http, 1.2.3.4, 443, username, password
ProxyHTTPS = https, 1.2.3.4, 443, username, password, sni=example.com
ProxySOCKS5 = socks5, 1.2.3.4, 443, username, password
ProxySOCKS5TLS = socks5-tls, 1.2.3.4, 443, username, password, sni=example.com
SS = ss, 1.2.3.4, 443, method, password, obfs=http
SSR = ssr, 1.2.3.4, 443, method, password, protocol=auth_chain_f, protocol_param=user:pass, obfs=http_post, obfs_param=example.com
Trojan = trojan, 1.2.3.4, 443, password=password, tls=true, sni=example.com, skip-cert-verify=false, ws=true
VMess = vmess, 1.2.3.4, 443, uuid=uuid, sni=example.com, tls=true, ws=true
VLESS = vless, 1.2.3.4, 443, uuid=uuid, sni=example.com, xtls=true
AnyTLS = anytls, 1.2.3.4, 443, password, sni=example.com
TUIC = tuic, 1.2.3.4, 443, uuid=uuid, password=password, sni=example.com
Hysteria2 = hysteria2, 1.2.3.4, 443, auth=password, sni=example.com, up=10, down=100
WireGuard = wireguard, private-key=base64key, peer-public-key=base64key, section-name=wg0, self-ip=10.0.0.2
AmneziaWG = amneziawg, section-name=awg0
ShadowTLS = shadowtls, 1.2.3.4, 443, password=password, sni=example.com, skip-cert-verify=false, fingerprint=chrome
ProxyMASQUE = masque, 1.2.3.4, 443, token=auth-token, mode=connect-udp, sni=example.com, alpn=h3, skip-cert-verify=false
SSH = ssh, 1.2.3.4, 22, root, password=pw
SCHEME = scheme, ssr://....

ملاحظة: تحتاج سياسة Trojan إلى tls=true صريح — TLS ليس ضمنياً. ومن دونه (ومن دون grpc=true، الذي يعمل فوق TLS دائماً) تتصل السياسة بلا تشفير، ويذكر السجل ذلك عند تحميل الإعدادات: Trojan policy <name> has no tls=true; it connects without TLS. ويكتب استيراد ملف إعدادات Clash/mihomo القيمة tls=true على كل عقدة Trojan.

ملاحظة: يقبل scheme رابط مشاركة من أحد هذه الأنواع: ss:// وssr:// وanytls:// وtuic:// وhysteria2:// وshadowtls://. والرابط من أي نوع آخر يجعل السطر خطأً في الإعدادات.

المعاملات

معاملات البروكسي مع TLS

tls: اختياري.

tls=true

تفعيل نقل TLS.

skip-cert-verify: اختياري

skip-cert-verify=true

إذا تم تفعيل هذا الخيار، لن يتحقق Chute من شهادة الخادم. وتفعّله القيم true و 1 و yes جميعاً، لذا تعمل روابط المشاركة التي تكتب insecure=1. وتُقرأ skip-common-name-verify=true، تهجئة Shadowrocket في أسطر socks5-tls، على أنها الخيار نفسه.

sni (الافتراضي: اسم المضيف)

sni=exmaple.com

يمكنك تخصيص Server Name Indication (SNI) أثناء مصافحة TLS. افتراضياً سيرسل Chute SNI مع اسم المضيف مثل معظم المتصفحات.

fingerprint: اختياري.

fingerprint=chrome

يُرسل ClientHello الخاص بمتصفح بدلاً من الافتراضي للنظام، حتى لا تبدو المصافحة مميزة كعميل بروكسي. القيم المدعومة هي chrome وfirefox وsafari وios، بالإضافة إلى edge و360 وqq وandroid وrandom التي تُعامل جميعها كـ Chrome. وتُقبل أيضاً الأسماء التي تستخدمها mihomo وsing-box وXray، وتُحوَّل إلى هذه القوالب الأربعة: فمثلاً تُعامل randomized وchrome_pq وhellochrome_131 كـ Chrome، وhellofirefox_120 كـ Firefox، وhellosafari_16_0 كـ Safari، وhelloios_14 كـ iOS. أما hellogolang في Xray فلا قالب مقابل له.

ينطبق ذلك على Trojan وVMess وVLESS فوق TLS، بما في ذلك نقل WebSocket وgRPC، وعلى Shadowsocks وShadowsocksR عبر WebSocket مع TLS. تحتوي REALITY وShadowTLS على الخيار نفسه في قسميهما. لتعيين بصمة واحدة لكل سياسة لا تحدد بصمتها الخاصة، استخدم global-client-fingerprint. وهو يصل دائماً إلى سياسات ShadowTLS، ويصل إلى سياسات VLESS التي تضبط tls=true أو reality=true، وإلى سياسات Trojan وVMess التي تضبط tls=true، وإلى سياسات Shadowsocks التي تضبط ws=true وtls=true معاً؛ والسياسة التي تستخدم نقل gRPC تحتاج إلى كتابة tls=true أيضاً. ولا يصل إلى سياسات ShadowsocksR إطلاقاً.

وعلى هذه البروتوكولات يختار fingerprint=none — أو unsafe الذي يعني الشيء نفسه — حزمة TLS الخاصة بالنظام، ويتقدم على global-client-fingerprint. ولا يستغني REALITY وShadowTLS عن مصافحة المتصفح، لذا فإن none فيهما يرفض الاتصال. أما أي قيمة لا يتعرّف عليها Chute فترفض اتصالات السياسة بدلاً من الرجوع إلى TLS النظام، أياً كان البروتوكول: لا يُرسَل أي شيء إلى الخادم، وينتهي الاتصال بالفشل — وتحسبه مجموعة url-test أو fallback كأي فشل آخر — ويسجّل تحميل الإعدادات Policy <name>: fingerprint '<value>' is not supported; connections through this policy are refused. أما global-client-fingerprint ذو القيمة غير المعروفة فيُتجاهل فحسب.

يؤدي ضبط بصمة أيضاً إلى تفعيل تبادل المفاتيح المقاوم للحوسبة الكمية: يعرض Chute عندئذٍ المجموعة الهجينة X25519MLKEM768 إلى جانب X25519، فلا يستطيع مهاجم يسجّل الجلسة اليوم فك تشفيرها لاحقاً بعد حصوله على حاسوب كمي. أما الخادم الذي لا يعرف هذه المجموعة فيختار X25519 ببساطة، فلا يتعطل شيء. وبدون بصمة يستخدم الاتصال حزمة TLS الخاصة بالنظام، وهي لا تعرضها — وهو السبب نفسه الذي يجعل ECH بحاجة إلى بصمة.

معاملات البروكسي مع Shadowsocks

method: مطلوبة.

مدعومة حالياً:

rc4-md5
aes-128-cfb
aes-192-cfb
aes-256-cfb
aes-128-ctr
aes-192-ctr
aes-256-ctr
bf-cfb
camellia-128-cfb
camellia-192-cfb
camellia-256-cfb
salsa20
chacha20
chacha20-ietf
aes-128-gcm
aes-192-gcm
aes-256-gcm
chacha20-ietf-poly1305
xchacha20-ietf-poly1305

طرق Shadowsocks 2022

يدعم Chute بروتوكول Shadowsocks 2022، الذي يستخدم اشتقاق مفاتيح قائم على BLAKE3 وتشفير AEAD. يحدد اسم الطريقة مجموعة التشفير:

2022-blake3-aes-128-gcm
2022-blake3-aes-256-gcm
2022-blake3-chacha20-poly1305

تنسيق كلمة المرور:

يتكون حقل كلمة المرور لـ SS2022 من مفتاح واحد أو اثنين مرمَّزين بـ base64، مفصولين بـ : (نقطتين رأسيتين).

وضع المستخدم الواحد (مفتاح واحد):

SS2022 = ss, 1.2.3.4, 443, 2022-blake3-aes-256-gcm, "base64-key"

وضع المستخدمين المتعددين مع ترويسات الهوية (مفتاحان):

بالنسبة لـ 2022-blake3-aes-128-gcm و 2022-blake3-aes-256-gcm، يمكنك توفير مفتاح ترويسة هوية ومفتاح مستخدم، مفصولين بـ ::

SS2022 = ss, 1.2.3.4, 443, 2022-blake3-aes-256-gcm, "header-base64-key:user-base64-key"

كل مفتاح هو نص مرمَّز بـ base64 (يدعم كلاً من base64 القياسي والآمن للروابط). أطوال المفاتيح المطلوبة:

توليد مفتاح:

openssl rand -base64 32

ملاحظة: طرق SS2022 لا تدعم معامل obfs. طريقة 2022-blake3-chacha20-poly1305 لا تدعم وضع المستخدمين المتعددين.

طرق Shadowsocks AEGIS

يدعم Chute أيضاً عائلة تشفير AEAD المسماة AEGIS. وهي مبنية على دالة جولة AES وأسرع بوضوح من AES-GCM أو ChaCha20-Poly1305 على أي معالج يتضمن AES عتادياً، وهو ما ينطبق على كل أجهزة iPhone وiPad وApple TV وMac الحديثة:

aegis-128l
aegis-256

تُضبط مثل طرق AEAD التقليدية أعلاه، وكلمة المرور عبارة مرور عادية وليست مفتاحاً بترميز base64:

AEGIS = ss, 1.2.3.4, 443, aegis-128l, your-password

كل ما عدا ذلك يتبع SIP004 دون تغيير: طول الملح مساوٍ لطول المفتاح، ومفتاح الجلسة الفرعي هو HKDF-SHA1(key, salt, "ss-subkey")، وتُنقل حمولة TCP في كتل AEAD مسبوقة بالطول مع زيادة الـ nonce بعد كل عملية، بينما يستخدم UDP قيمة nonce صفرية بالكامل.

عليك تشغيل الخادم بنفسك. ليست AEGIS جزءاً من مواصفات Shadowsocks — فلا يوجد SIP يعرّفها، ولا ينفذها أي خادم Shadowsocks شائع، بما في ذلك shadowsocks-rust وshadowsocks-libev وshadowsocks-go وsing-box وXray. اختيار إحدى هاتين الطريقتين لن ينجح إلا مع خادم تديره بنفسك وتم بناؤه لدعمهما. أما إذا كنت تتصل بعقدة تجارية أو مشتركة، فاستخدم إحدى الطرق المتوافقة أعلاه.

obfs: اختياري.

مدعوم حالياً:

tls
http

obfs_param: اختياري.

obfs_param=example.com

يحدد قيمة Host المستخدمة في طبقة obfs. القيمة الافتراضية cloudfront.net عند عدم التعيين.

WebSocket (v2ray-plugin): اختياري.

ws=true, ws-path=/path, ws-headers=Host:example.com, tls=true, sni=example.com, skip-cert-verify=false

ينقل تدفق Shadowsocks داخل WebSocket، كما يفعل وضع websocket في v2ray-plugin، فتصل السياسة إلى خادم Shadowsocks يعمل خلف v2ray-plugin، بما في ذلك حين تكون أمامه شبكة CDN. والخيارات هي خيارات نقل WebSocket وخيارات TLS. وتعمل طرق Shadowsocks 2022 فوقه أيضاً، وتقبل سياسات ShadowsocksR الخيارات نفسها مع احتفاظها ببروتوكولها وobfs الخاصين بها.

• القيمة الافتراضية لـ ws-path هي /، والمسار المكتوب بلا شرطة مائلة في أوله تُضاف إليه.
• يكون Host في طلب الترقية هو Host المذكور في ws-headers، ويُستخدم كما كُتب. وإن لم يوجد فهو sni — أو عنوان الخادم إن لم يوجد sni — متبوعاً بـ :<port>.
• يُشغّل tls=true طبقة TLS تحت WebSocket. وتعمل sni وskip-cert-verify وfingerprint وخيارات ECH كما تعمل مع Trojan. ومن دون ws=true لا يفعل tls=true شيئاً: تتصل السياسة بلا TLS، ويحصل السطر على التنبيه الإرشادي Shadowsocks tls=true only applies with ws=true (the v2ray-plugin transport); this policy connects without TLS.
• يفتح ws-mux (الافتراضي true) جلسة mux.cool واحدة على كل WebSocket، وهو ما يتوقعه خادم v2ray-plugin المُشغَّل بقيمته الافتراضية mux=1. أما للخادم المُشغَّل بـ mux=0 فاكتب ws-mux=false.
• إذا وُجد obfs= في السطر نفسه يُستخدم WebSocket ولا يُطبَّق simple-obfs؛ ويسجّل تحميل الإعدادات Policy <name> ignored unsupported option(s): obfs.
• لا يمر UDP عبر المُلحق: فهو UDP عادي لـ Shadowsocks يُرسَل مباشرة إلى host:port، ولا يعبر شبكة CDN. اكتب udp-relay=false للخادم الذي تصل إليه عبر شبكة كهذه. وإذا كان خادم Shadowsocks الذي خلف المُلحق يدعم UoT، فيمكن بدلاً من ذلك استخدام udp-over-tcp=true، فيُحمَل UDP داخل تدفقات السياسة ويمر بذلك عبر WebSocket أيضاً.
• وضع quic في v2ray-plugin غير مدعوم.

تُقرأ صيغة Shadowrocket أيضاً: obfs=websocket (أو obfs=ws)، مع Host في obfsParam أو obfs-host والمسار في path أو obfs-uri. وتُحفظ السياسة بصيغة ws=true. أما أي قيمة أخرى لـ obfs لا تستطيع حزمة Shadowsocks قراءتها — مثل wss في Quantumult X أو خطأ إملائي — فيُذكر اسمها في تنبيه إرشادي، وتتصل السياسة كـ Shadowsocks عادي: Shadowsocks over WebSocket (the v2ray-plugin transport) is written ws=true, with ws-path= and ws-headers=; obfs=<value> is not read, so this policy would connect as plain Shadowsocks.

SS = ss, 1.2.3.4, 443, aes-256-gcm, password, ws=true, ws-path=/ws, ws-headers=Host:cdn.example.com, tls=true, sni=cdn.example.com

udp-over-tcp: اختياري.

udp-over-tcp=true, udp-over-tcp-version=2

يحمل UDP الخاص بالسياسة داخل اتصالات TCP للسياسة نفسها بدلاً من ترحيل UDP في الخادم — أي UDP عبر TCP (UoT) الخاص بـ sing-box. يحصل كل تدفق UDP على اتصال خاص به إلى عنوان الالتقاء الذي يتعرّفه الخادم (sp.v2.udp-over-tcp.arpa، أو sp.udp-over-tcp.arpa للإصدار 1). وهذه اتصالات عادية للسياسة، فتتبع underlying-proxy الخاص بها كأي اتصال آخر: فيعمل UDP عندئذ عبر منبع لا يحمل UDP، مثل بروكسي HTTP، وعبر نقل WebSocket. ويجب أن يدعم الخادم UoT، كما تفعل خوادم sing-box وmihomo. وتعمل معه طرق تشفير Shadowsocks 2022.

• udp-over-tcp-version (الافتراضي 2): يفتتح الإصدار 2 كل اتصال بطلب يسمّي الوجهة، ثم يؤطّر كل حزمة بيانات بطولها؛ أما الإصدار 1 فلا طلب فيه، ويضع العنوان أمام كل حزمة بيانات. الإصدار الافتراضي في mihomo هو 1، لذا يكتب ملف الإعدادات المستورد من mihomo الإصدارَ صراحة. وأي قيمة أخرى يُبلَّغ عنها وتُستخدم على أنها 2، وتبقى كما كُتبت عند حفظ ملف الإعدادات.
• لا يزال udp-relay=false يوقف UDP للسياسة.
• في محرر Shadowsocks داخل التطبيق، يقابل ذلك مفتاح UDP over TCP وخيار UoT Version.

SS = ss, 1.2.3.4, 8388, aes-256-gcm, password, udp-over-tcp=true

معاملات البروكسي مع ShadowsocksR/ShadowsocksRR/ShadowsocksR-Akarin

method: مطلوبة.

مدعومة حالياً:

rc4
rc4-md5-6
rc4-md5
aes-128-cfb
aes-192-cfb
aes-256-cfb
aes-128-ctr
aes-192-ctr
aes-256-ctr
bf-cfb
camellia-128-cfb
camellia-192-cfb
camellia-256-cfb
cast5-cfb
des-cfb
idea-cfb
rc2-cfb
seed-cfb
salsa20
chacha20
chacha20-ietf

protocol: اختياري.

مدعوم حالياً:

origin
auth_sha1
auth_sha1_v2
auth_sha1_v4
auth_aes128_md5
auth_aes128_sha1
auth_chain_a
auth_chain_b
auth_chain_c
auth_chain_d
auth_chain_e
auth_chain_f
auth_akarin_rand
auth_akarin_spec_a

protocol_param: اختياري.

obfs: اختياري.

مدعوم حالياً:

plain
http_simple
http_post
tls1.2_ticket_auth

obfs_param: اختياري.

معاملات البروكسي مع WebSocket

يتوفر نقل WebSocket لـ Trojan وVMess وVLESS، ولـ Shadowsocks وShadowsocksR حيث يكون هو وضع websocket في v2ray-plugin — انظر WebSocket (v2ray-plugin) لما يختلف هناك.

ws: اختياري.

ws=true

تفعيل نقل WebSocket.

ws-path: اختياري.

ws-path=/exmaple

تغيير مسار طلب HTTP لـ WebSocket.

ws-headers: اختياري.

ws-headers=Header1:Value1|Header2:Value2

تعديل ترويسة HTTP لطلب HTTP لـ WebSocket.

معاملات البروكسي مع gRPC

نقل gRPC متاح لبروتوكولات Trojan و VMess و VLESS. يستخدم تأطير gRPC المعتمد على HTTP/2 عبر TLS، مما يمكن أن يساعد في تجاوز بعض قيود الشبكة.

grpc: اختياري.

grpc=true

تفعيل نقل gRPC. ويعمل هذا النقل فوق TLS دائماً مهما كانت قيمة tls في السياسة. ومع ذلك اكتب tls=true إن أردت أن تأخذ السياسة global-client-fingerprint، إذ لا يصل إلى سياسة gRPC إلا إذا ضبطته.

grpc-service-name: مطلوب عندما grpc=true.

grpc-service-name=MyService

تحديد اسم/مسار خدمة gRPC لتعدد الإرسال. يجب أن يتطابق مع اسم الخدمة المكوَّن على الخادم؛ لا يوجد افتراضي.

grpc-multi-mode: اختياري.

grpc-multi-mode=true

استخدام الوضع المتعدد (multi) في Xray: يستدعي النفق /<service>/TunMulti بدلاً من /<service>/Tun، وتُنقل عدة عمليات كتابة في رسالة gRPC واحدة. ويجب أن يدعم الخادم الوضع المتعدد. ويبقى لكل نفق اتصاله الخاص.

مثال مع VMess و gRPC:

VMess = vmess, 1.2.3.4, 443, uuid=uuid, tls=true, grpc=true, grpc-service-name=GunService, sni=example.com

معاملات البروكسي مع XHTTP

نقل XHTTP متاح لبروتوكولات Trojan وVMess وVLESS. فبدلاً من إبقاء اتصال واحد مفتوحاً، يضع النفق داخل طلبات HTTP عادية: التنزيل يصل كاستجابة واحدة لا تنتهي، والرفع يخرج إما كسلسلة من طلبات POST أو كطلب POST واحد لا ينتهي. هذا ما يجعله صالحاً للعمل خلف شبكة توصيل محتوى (CDN)، وهو السبب الرئيسي لاختياره بدل WebSocket أو gRPC.

إصدار HTTP لا يُضبط مباشرة. بدون TLS يكون HTTP/1.1، ومع TLS يكون HTTP/2، إلا إذا كانت alpn تساوي http/1.1 تماماً (فيكون HTTP/1.1) أو h3 تماماً (فيكون HTTP/3). أما REALITY فيستخدم HTTP/2 دائماً.

xhttp: اختياري.

xhttp=true

تفعيل نقل XHTTP.

xhttp-mode: اختياري.

xhttp-mode=packet-up

كيفية حمل الرفع. القيمة auto (الافتراضية) تعني packet-up، وتعني stream-one عند استخدام REALITY.

• packet-up — الرفع سلسلة من طلبات POST مرقّمة. الأكثر توافقاً والأنسب لشبكات توصيل المحتوى.
• stream-up — الرفع طلب POST واحد لا ينتهي، والتنزيل عبر طلب منفصل.
• stream-one — طلب واحد يحمل الاتجاهين. يتطلب دعم الخادم والأجهزة الوسيطة لـ HTTP ثنائي الاتجاه المتزامن.

عادةً ما يثبّت الخادم وضعاً واحداً، وعدم التطابق يُقابَل بالرد 400.

xhttp-path: اختياري.

xhttp-path=/yourpath

مسار الطلب، والافتراضي /. يجب أن يطابق المسار الذي يقدّم عليه الخادم خدمة XHTTP.

xhttp-host: اختياري.

xhttp-host=example.com

اسم المضيف المستخدم في ترويسة Host وفي عنوان الطلب. الافتراضي هو sni، وعنوان الخادم إذا لم تُضبط.

xhttp-headers: اختياري.

xhttp-headers=Header1:Value1|Header2:Value2

ترويسات HTTP إضافية بالصيغة نفسها المستخدمة في ws-headers.

xhttp-padding: اختياري.

xhttp-padding=100-1000

مدى طول الحشو الذي يحمله كل طلب، بصيغة MIN-MAX أو كرقم واحد. الافتراضي 100-1000. الخادم يشترط وجود الحشو ويتحقق من طوله، لذا يجب أن يبقى هذا المدى ضمن ما يقبله الخادم؛ فالطلب بلا حشو أو بطول غير صحيح يُقابَل بالرد 400.

xhttp-max-post-bytes: اختياري.

xhttp-max-post-bytes=1000000

أكبر حجم لطلب POST للرفع بالبايت، والافتراضي 1000000. الكتابات الأكبر تُقسَّم على عدة طلبات POST.

xhttp-min-post-interval: اختياري.

xhttp-min-post-interval=30

أقل فاصل زمني بين طلبَي رفع متتاليين بالميلي ثانية، والافتراضي 30.

xhttp-xmux-max-concurrency و xhttp-xmux-max-connections و xhttp-xmux-max-reuse-times و xhttp-xmux-max-lifetime: اختياري.

xhttp-xmux-max-concurrency=4

يجمّع XMUX اتصالات HTTP/2 الأساسية في مجمّع حتى تتشارك عدة أنفاق اتصالاً واحداً، فيبدو الأمر كجلسة متصفح عادية بدل اتصال لكل نفق. القيم الأربع افتراضها 0، أي أن التجميع معطّل.

• xhttp-xmux-max-concurrency — عدد الأنفاق التي يمكنها التشارك في اتصال واحد.
• xhttp-xmux-max-connections — عدد الاتصالات المسموح بها لكل خادم.
• xhttp-xmux-max-reuse-times — بعد كم نفقاً يتوقف الاتصال عن قبول أنفاق جديدة.
• xhttp-xmux-max-lifetime — بعد كم ثانية يتوقف الاتصال عن قبول أنفاق جديدة.

لاحظ أن mux=true مرفوض مع سياسة XHTTP أياً كان بروتوكولها، ويسجّل تحميل الإعدادات Policy <name> ignored unsupported option(s): mux: فـ XHTTP يحمل تعدد الإرسال الخاص به، ووضع تعدد الإرسال العام فوقه يجعله طبقتين.

xhttp-download-server و xhttp-download-port: اختياري.

xhttp-download-server=cdn.example.com

توجيه التنزيل عبر عنوان آخر — عادةً شبكة توصيل محتوى أمام الخادم نفسه — بينما يبقى الرفع على العنوان الرئيسي. يجب أن يصل الاثنان إلى الخادم نفسه: فالجلسة حالة على جانب الخادم، ومسار ثانٍ مقبول أما خادم ثانٍ فلا.

مثال مع VLESS وXHTTP:

VLESS = vless, 1.2.3.4, 443, uuid=uuid, tls=true, xhttp=true, xhttp-mode=packet-up, xhttp-path=/yourpath, sni=example.com

معاملات البروكسي مع XTLS

xtls: اختياري.

xtls=true

تغليف النقل بـ XTLS. وهو وحده لا يعلن أي تدفق: إذ يحمل طلب VLESS كتلة addons فارغة، فلا يُتفاوض على تدفق. استخدم flow=xtls-rprx-vision أدناه لإعلان واحد؛ أما xtls-rprx-direct فغير مطبَّق.

flow: اختياري.

flow = xtls-rprx-vision

اختيار تحكم تدفق XTLS. القيمة الوحيدة المدعومة هي xtls-rprx-vision، وهي تفعّل تأطير Vision؛ وتُرسل قيمة التدفق إلى الخادم ضمن إضافات VLESS.

skip-cert-verify: اختياري

skip-cert-verify=true

مثل TLS.

sni (الافتراضي: اسم المضيف)

sni=exmaple.com

مثل TLS.

معاملات البروكسي مع REALITY

REALITY هي تقنية تمويه قائمة على TLS تجعل حركة مرور البروكسي غير قابلة للتمييز عن حركة TLS العادية إلى موقع حقيقي. يمكن استخدامها مع بروتوكول VLESS.

reality: اختياري.

reality=true

تفعيل تمويه REALITY. يتطلب خادم هدف سيعمل كوجهة تمويه.

public-key: مطلوب.

public-key=BASE64KEY

مفتاح X25519 العام للخادم (base64). لا يمكن بناء مصافحة REALITY بدونه.

short-id: اختياري.

short-id=abcd1234

معرف قصير يستخدم لمصادقة REALITY. عادة ما يكون نصاً ست عشرياً.

server-name: اختياري.

server-name=www.microsoft.com

اسم SNI (Server Name Indication) الذي سيتم تقديمه أثناء مصافحة TLS. يجب أن يكون موقعاً حقيقياً شائع الزيارة لأفضل تأثير تمويه. يجب أن تتطابق شهادة الخادم الهدف مع هذا الاسم.

fingerprint: اختياري.

fingerprint=chrome

بصمة عميل TLS للمحاكاة. القيم المدعومة تشمل chrome، firefox، safari، ios، edge، 360، qq، android، random، والأسماء الأخرى المذكورة تحت fingerprint. استخدام بصمة متصفح شائعة يساعد في تجنب الاكتشاف. لاحظ أن android و random ليسا مميزين هنا — إذ يُعاملان معاملة chrome. أما none وأي قيمة لا يتعرّف عليها Chute فترفض الاتصال، لأن حزمة TLS الخاصة بالنظام لا تستطيع إجراء هذه المصافحة.

spiderx: اختياري.

spiderx=/path

مسار مخصص لتمويه REALITY العنكبوتي.

مثال مع VLESS:

VLESS = vless, 1.2.3.4, 443, uuid=uuid, reality=true, public-key=BASE64KEY, server-name=www.microsoft.com, short-id=abcd, fingerprint=chrome

ملاحظة: REALITY لا تستخدم شهادة تقليدية. يستخدم الاتصال الشهادة الحقيقية لخادم التمويه.

معاملات البروكسي مع ECH

يُخفي Encrypted Client Hello اسم الخادم عن أي طرف يراقب الاتصال. يسير الاسم الحقيقي مشفراً داخل المصافحة، بينما الذي يظهر على المسار هو public_name المنشور في ECHConfig الخاص بالخادم.

يعتمد ECH على الحزمة نفسها التي تعتمد عليها بصمة العميل، لذا يجب أن تضبط السياسة fingerprint أيضاً — بدونها لا يفعل ech=true شيئاً ويُرسَل الاسم الحقيقي بوضوح. ينطبق على Trojan وVMess وVLESS فوق TLS العادي، بما في ذلك نقل WebSocket، وعلى Shadowsocks وShadowsocksR عبر WebSocket مع TLS.

ملاحظة: نقلا gRPC وXHTTP لا يدعمان ECH. فمع grpc=true أو xhttp=true يُتجاهل ech=true بصمت ويُرسَل اسم الخادم الحقيقي بوضوح. (أما بصمة العميل وتبادل المفاتيح ما بعد الكمي فينطبقان على gRPC وXHTTP.)

ech: اختياري.

ech=true

تفعيل ECH. ما لم يُضبط ech-config، يبحث Chute عن ECHConfig في سجل DNS HTTPS لاسم الخادم، تماماً كما يفعل المتصفح.

ech-config: اختياري.

ech-config=AEX+DQBBAAAgACD...

قائمة ECHConfigList بترميز base64 تُستخدم بدل البحث في DNS. اضبطها عندما لا ينشر الخادم سجل HTTPS، أو لتثبيت إعداد بعينه. وضبطها يفعّل ECH وحده؛ فلا حاجة إلى ech=true معها.

ech-public-name: اختياري.

ech-public-name=cover.example.com

يتجاوز اسم التغطية المُرسَل بوضوح. الافتراضي هو public_name داخل ECHConfig وهو ما يتوقعه الخادم؛ لا تضبطه إلا في نشرٍ يقدّم فيه مضيف آخر هذا الإعداد.

مثال مع Trojan:

Trojan = trojan, 1.2.3.4, 443, password=pw, tls=true, sni=secret.example.com, fingerprint=chrome, ech=true

إذا رفض الخادم ECH — غالباً لأن الإعداد أصبح قديماً — فسيجيب باسم التغطية ويقدّم شهادة ذلك الاسم، وتتراجع المصافحة إلى TLS الخارجي. وما دام التحقق من الشهادة مفعّلاً يفشل الاتصال عندئذ في التحقق بدل أن يستمر بصمت؛ أما مع skip-cert-verify=true فلا شيء يفحص ذلك الاسم وتستمر الجلسة بصمت تحت اسم التغطية. حدّث ech-config أو احذفه للعودة إلى البحث في DNS.

TCP Fast Open (تجريبي)

tfo: اختياري

tfo=true

يمكن قراءة المزيد من المعلومات عن TCP Fast Open في Wikipedia. قد يتسبب تفعيل TCP Fast Open في فشل اتصال غير متوقع. ويتجاهل Chute Android الخيار tfo.

المعاملات المشتركة

udp-relay: اختياري (الافتراضي: true)

udp-relay=false

يجعل السياسة TCP فقط. ترحيل UDP مفعل افتراضياً حيث يدعمه البروتوكول؛ عيّن udp-relay=false لاستبعاد السياسة من ترحيل حركة UDP. يرحّل Trojan حركة UDP عبر اتصال TLS عادي إلى منفذ الخادم — بلا WebSocket أو gRPC أو XHTTP، وبلا ECH، لكن مع بصمة السياسة — لذا مع خادم لا يخدم إلا أحد هذه الأنواع من النقل، عيّن udp-relay=false.

mux: اختياري

mux=true

تفعيل إعادة استخدام الاتصال / تعدد الإرسال. يُقبل أيضاً الاسمان المستعاران multiplex و reuse. مدعوم من HTTP/HTTPS و SOCKS5/SOCKS5-TLS و Trojan و VMess و VLESS و Hysteria2 و Shadowsocks(R) و ShadowTLS و MASQUE. أما AnyTLS و TUIC و SSH فلا تُعدّ متعددة الإرسال على أي منصة. ولهذه البروتوكولات لا يُطبَّق mux=true، ويذكر السجل ذلك عند تحميل الإعدادات: Policy <name>: mux=true is not applied: <reason>.

يُعدّ Hysteria2 و MASQUE متعددَي الإرسال عبر اتصال QUIC واحد مشترك. أما بقية البروتوكولات فتحمل الاتصالات متعددة الإرسال في تأطير خاص بـ Chute، لا يفككه إلا خادم يفهمه: خوادم Xray و sing-box و Shadowsocks القياسية لا تستطيع ذلك، فلا تفعّل mux معها.

cert-fingerprint-sha256: اختياري

cert-fingerprint-sha256=<hex>

تثبيت شهادة الخادم ببصمتها SHA-256. يُقبل أيضاً الاسم المستعار cert-fp. فعال حالياً لـ MASQUE فقط.

encrypt-method (VMess): اختياري (الافتراضي: auto)

encrypt-method=aes-128-gcm

تشفير حمولة VMess. القيم المدعومة: aes-128-gcm، chacha20-poly1305، aes-128-cfb (الاسم المستعار legacy)، none.

alpn: اختياري

alpn=h2|http/1.1

تفصل قيم ALPN المتعددة بـ |. ولا يقرأه سوى TUIC و Hysteria2 و MASQUE — ويعود كل منها إلى h3 حين لا يُضبط — إلى جانب XHTTP، حيث يختار إصدار HTTP الذي يتكلمه النقل. أما بقية البروتوكولات فتتجاهل هذا الخيار وتعرض ALPN الذي يقرره نقلها: h2 لـ gRPC؛ ومع fingerprint، http/1.1 لـ WebSocket وh2,http/1.1 لـ TLS المجرد؛ ومن دونه لا شيء لأيٍّ منهما، لأن حزمة TLS الخاصة بالنظام هي التي تُجري المصافحة حينئذ.

underlying-proxy: اختياري.

underlying-proxy=OtherProxy

تسلسل البروكسي: تسمي القيمة سياسة أخرى أو مجموعة سياسات تحمل حركة مرور هذه السياسة. يُختار المنبع قبل أن تفتح السياسة اتصالها بخادمها؛ لذلك يرسل A = ..., underlying-proxy=B حركة A عبر B. ويمكن لـ B تسمية منبع آخر لإنشاء عدة قفزات. تركها فارغة أو كتابة DIRECT يعني اتصالاً مباشراً. ضع الاسم الذي يحتوي على مسافة أو فاصلة بين علامتي اقتباس، كما في underlying-proxy="HK 01". والاسم غير المعرَّف يؤدي إلى رفض الاتصال (fail closed) ويُسجَّل، ولا يحدث رجوع إلى DIRECT.

تُرفض الحلقة المكوّنة من مراجع ثابتة — بما فيها الحلقة التي تعود عبر underlying-proxy الخاص بالعضو الأول في مجموعة ترحيل — عند تحميل الإعدادات. أما الحلقة التي لا تنشأ إلا بسبب ما تختاره مجموعة سياسات في هذه اللحظة فلا تُرفض نهائياً: فحين تختار المجموعة غير ذلك تعمل السياسة، لكن ما دامت الحلقة قائمة يُرفض كل اتصال يمر عبرها. وأيًّا كان شكل السلسلة، يُرفض الاتصال الذي تتداخل فيه المنابع لأكثر من 16 مستوى بدلاً من أن يُفَكّ تداخله بلا نهاية.

يحلّ المنبع أيضاً اسم خادم هذه السياسة: لا يُستعلم عن الخادم المُسلسل عبر المحلّل المحلي، ولا يرسل Chute إليه ping مباشراً، ولا إلى أي سياسة تأتي بعد العضو الأول في مجموعة ترحيل. يأتي زمن استجابته من فحوص سلامة المجموعات ومن اختبار زمن الاستجابة، وكلاهما يصل إليه عبر السلسلة — إذ تفحص مجموعات url-test وfallback وload-balance العضو المُسلسل عبر المسار نفسه الذي يسلكه الاتصال الفعلي.

يمكن تسلسل كل البروتوكولات ما عدا Tailscale (السياسة المدمجة TAILSCALE)، إذ ينشئ محرّكه اتصالاته بنفسه. السياسة التي تصل إلى خادمها عبر تدفق — HTTP وSOCKS5 وShadowsocks وVMess وVLESS وTrojan وAnyTLS وSSH وXHTTP عبر HTTP/1.1 أو HTTP/2 وغيرها — تفتح هذا التدفق عبر المنبع. أما Hysteria2 وTUIC وMASQUE وXHTTP عبر HTTP/3 (مع TLS وalpn=h3) فتتحدث QUIC، ويرسل WireGuard وAmneziaWG حزم بيانات خاصة بهما، لذا تمر كلها عبر ترحيل UDP الخاص بالمنبع: يجب أن يحمل المنبع — أو اختياره الحالي إن كان مجموعة — UDP، كما تفعل Shadowsocks وSOCKS5 وVMess وVLESS وTrojan وHysteria2، ولا يفعل بروكسي HTTP أو HTTPS. وعبر منبع لا يحمل UDP يُرفض كل اتصال يمر عبرها ويُسجّل، ولا يُرسل مباشرة أبداً. عند التسلسل ترسل سياسة QUIC حزماً لا تتجاوز 1200 بايت، ويستخدم نفق WireGuard أو AmneziaWG وحدة MTU داخلية قدرها 1280 ما لم تُكتب قيمة (mtu، أو wg-mtu في قسمه)، كي تظل الحزم المغلّفة ضمن مسار 1500 بايت. ويُبقي WireGuard وAmneziaWG وSSH اتصالاً واحداً لكل حركة مرورها عبر منبعها الخاص، لذا لا يمكن لأيٍّ منها أن يكون عضواً لاحقاً في مجموعة ترحيل.

ويمر UDP عبر السلسلة أيضاً. تحمل VMess وVLESS وTrojan وAnyTLS بيانات UDP داخل تدفق، لذا يعمل UDP الخاص بها عبر أي منبع. أما Shadowsocks (بما فيها ShadowsocksR وShadowsocks 2022) وSOCKS5 فتُرحّل UDP على شكل حزم بيانات، وكذلك بروتوكولات QUIC وWireGuard: لا يعمل UDP الخاص بها إلا ما دام المنبع يحمل UDP — إلا إذا استخدمت عقدة Shadowsocks الخيار udp-over-tcp، فهي تحمل UDP داخل تدفقات، فيعمل عبر أي منبع. ولا تحمل سياسات SSH وHTTP وHTTPS أي UDP. ويخضع UDP الذي لا تستطيع سياسة مُسلسلة حمله لـ udp-policy-not-supported-behaviour (القيمة الافتراضية REJECT).

يُستورد dialer-proxy (mihomo) وdetour (sing-box) في هذا الخيار، ويُستورد override: dialer-proxy الخاص بمزود البروكسي في underlying-proxy الخاص بالمزود. وتبقى مجموعة relay في Clash أو mihomo مجموعة ترحيل بأعضائها في الترتيب نفسه. ولإرسال كل أعضاء مجموعة سياسات عبر منبع واحد، اضبط underlying-proxy على المجموعة. ولإرسال كل سياسات البروكسي عبر منبع واحد، اضبط global-underlying-proxy في [General].

test-url: اختياري.

test-url=http://www.gstatic.com/generate_204

رابط اختبار زمن الاستجابة لهذه السياسة عندما تكون عضواً في مجموعة url-test أو fallback: تختبر المجموعة هذا العضو بهذا الرابط بدلاً من url الخاص بالمجموعة. وإن لم يُكتب، يُستخدم رابط المجموعة.

interface: اختياري

interface=en0

يرسل اتصالات TCP التي تجريها هذه السياسة إلى خادمها عبر واجهة الشبكة المسماة — en0 على Mac، وwlan0 على Android مثلاً — بدلاً من الواجهة التي يختارها المسار الافتراضي. وحين لا تكون تلك الواجهة متاحة يفشل الاتصال بدلاً من الخروج من طريق آخر؛ ويتيح allow-other-interface=true له أن يتبع المسار الافتراضي بدلاً من ذلك. يعمل على Chute Mac وChute Android، ويتجاهله iOS وtvOS. ولا يُربط ترحيل UDP، ولا البروتوكولات القائمة على QUIC (TUIC وHysteria2 وMASQUE)، ولا WireGuard أو Tailscale.

معاملات البروكسي مع AnyTLS

AnyTLS هو بروتوكول بروكسي قائم على TLS مع تمويه بالحشو.

AnyTLS = anytls, 1.2.3.4, 443, password, sni=example.com, skip-cert-verify=false

password: مطلوبة.

كلمة المرور المستخدمة للمصادقة.

sni (الافتراضي: اسم المضيف)

sni=exmaple.com

مثل TLS.

skip-cert-verify: اختياري

skip-cert-verify=true

مثل TLS.

مخطط الحشو: اختياري

يُكوَّن الحشو بـ stop=N بالإضافة إلى مفاتيح رقمية لكل حزمة:

AnyTLS = anytls, 1.2.3.4, 443, password, sni=example.com, stop=2, 0=30-30, 1=100-400+c

كل مخطط هو قائمة مقاطع موصولة بـ +، حيث يكون المقطع إما c (فحص) أو نطاق بايتات min-max (بحد أقصى 16384)، مثال stop=2, 0=30-30, 1=100-400+c. وتصلح , فاصلاً أيضاً، لكن بشرط أن تكون القيمة بين علامتي اقتباس — 1="100-400,c" — لأن الفاصلة غير المقتبسة تنهي الحقل وتكسر السطر. والأفضل استخدام +.

معاملات البروكسي مع TUIC

TUIC هو بروتوكول بروكسي قائم على QUIC يقدم ترحيل TCP و UDP متعدد الإرسال. وتُقبل الكلمة المفتاحية tuic-v5 (بصيغة Surge) أيضاً، وتُحفظ السياسة بصيغة tuic.

TUIC = tuic, 1.2.3.4, 443, uuid=uuid, password=password, sni=example.com, skip-cert-verify=false, alpn=h3

uuid: مطلوب.

معرف UUID للمصادقة.

password: مطلوبة.

كلمة المرور للمصادقة.

sni (الافتراضي: اسم المضيف)

sni=exmaple.com

مثل TLS.

skip-cert-verify: اختياري

skip-cert-verify=true

مثل TLS.

alpn: اختياري

alpn=h3

تحديد نص ALPN لاتصال QUIC.

معاملات البروكسي مع Hysteria2

Hysteria2 هو بروتوكول بروكسي قائم على QUIC لسيناريوهات الإنتاجية العالية.

Hysteria2 = hysteria2, 1.2.3.4, 443, auth=password, sni=example.com, skip-cert-verify=false, up=10, down=100, alpn=h3

auth: مطلوبة.

كلمة المرور/الرمز للمصادقة.

sni (الافتراضي: اسم المضيف)

sni=exmaple.com

مثل TLS.

skip-cert-verify: اختياري

skip-cert-verify=true

مثل TLS.

up: اختياري (Mbps)

up=10

عرض النطاق الترددي للرفع بـ Mbps. يُقبَل ويُحفَظ لكنه لا يُستخدم: فهو يغذّي متحكّم الازدحام Brutal الخاص بـ Hysteria2، وهذا المحرك لا يشغّله. ويُسجَّل تنبيه لكل سياسة تضبطه. أما الذي يصل إلى الشبكة فهو down=، أي المعدّل الذي يعلنه العميل عند المصادقة.

down: اختياري (Mbps)

down=100

عرض النطاق الترددي للتنزيل بـ Mbps.

alpn: اختياري

alpn=h3

تحديد نص ALPN لاتصال QUIC.

obfs: اختياري

obfs=salamander

تفعيل تمويه Salamander لحركة QUIC. يستخدم Salamander تشفير XOR مع BLAKE2b-256 لتمويه حزم QUIC، مما يجعلها مقاومة للفحص العميق للحزم (DPI).

obfs-password: اختياري

obfs-password=your-obfuscation-key

كلمة المرور/المفتاح المستخدم لتمويه Salamander. مطلوب عند تعيين obfs=salamander.

معاملات البروكسي مع WireGuard

WireGuard هو بروتوكول VPN حديث. يدعم Chute WireGuard كخادم بروكسي صادر، إما بشكل مضمن أو بالإشارة إلى قسم [WireGuard] مسمى.

تكوين مضمن:

WireGuard = wireguard, private-key=base64key, peer-public-key=base64key, self-ip=10.0.0.2, server=1.2.3.4, port=51820

مرجع قسم (موصى به):

WireGuard = wireguard, section-name=wg0

انظر إعدادات WireGuard لصيغة قسم [WireGuard].

private-key: مطلوب (للتكوين المضمن فقط).

مفتاح WireGuard الخاص مرمَّز بـ base64.

peer-public-key: مطلوب (للتكوين المضمن فقط).

مفتاح نظير WireGuard العام مرمَّز بـ base64.

self-ip: اختياري (مضمن).

عنوان IP المحلي المعين لواجهة WireGuard (مثال 10.0.0.2).

self-ip-v6: اختياري (مضمن).

عنوان IPv6 المحلي المعين لواجهة WireGuard.

server: مطلوب.

عنوان خادم WireGuard البعيد (قد يأتي من قسم [WireGuard] المشار إليه بدلاً من سطر السياسة).

port: مطلوب.

منفذ خادم WireGuard البعيد (قد يأتي من قسم [WireGuard] المشار إليه بدلاً من سطر السياسة).

preshared-key: اختياري.

مفتاح مشترك مسبقاً مرمَّز بـ base64 لمقاومة ما بعد الكم.

allowed-ips: اختياري (مضمن).

allowed-ips="10.0.0.0/8, 192.168.0.0/16"

الوجهات التي يحملها النظير، على شكل كتل CIDR مفصولة بفواصل؛ ضع القيمة بين علامتي اقتباس لأنها تحتوي على فواصل. والوجهة الواقعة خارجها تُرفض أو تُسقط، لأن النظير لا يستطيع توجيه ردّها. ومن دونه تُحمل كل الحركة. راجع إعدادات WireGuard لصيغة القسم.

keepalive: اختياري (بالثواني).

keepalive=25

فاصل keepalive المستمر لعبور NAT. ومن دونه لا يُرسَل أي keepalive.

mtu: اختياري.

mtu=1420

MTU لواجهة WireGuard.

reserved: اختياري.

reserved=0,1,2

بايتات محجوزة لترويسة حزمة WireGuard. يُحلَّل لكنه غير فعّال في المحرك الحالي — إذ لا تدعم واجهة BoringTun FFI هذه القيمة ويتم تجاهلها مع تسجيل تحذير.

معاملات البروكسي مع ShadowTLS

ShadowTLS هو بروتوكول بروكسي قائم على TLS يغلف حركة المرور داخل جلسة TLS 1.3 قياسية. ويتكلم Chute الإصدار v3 منه: إذ تُحمل كلمة المرور بوصفها HMAC في session_id داخل ClientHello، فتقع المصادقة داخل المصافحة لا بعدها.

وداخل النفق المنشأ يرسل Chute تحية SOCKS5 بلا مصادقة ثم SOCKS5 CONNECT، ولذلك يجب أن يكون الخادم خلف ShadowTLS بروكسي SOCKS5 بلا مصادقة. أما نشر shadow-tls الذي يمرّر إلى منفذ Shadowsocks بدل منفذ SOCKS5 فيُكمل مصافحة TLS ثم يفشل.

ShadowTLS = shadowtls, 1.2.3.4, 443, password=password, sni=example.com, skip-cert-verify=false, fingerprint=chrome

password: مطلوبة.

كلمة المرور المستخدمة لمصادقة مصافحة ShadowTLS.

sni (الافتراضي: اسم المضيف)

sni=example.com

مثل TLS. وكتابته هي أيضاً ما يشغّل التحقق من شهادة التغطية — انظر أدناه.

skip-cert-verify: اختياري

skip-cert-verify=true

ما يشغّل التحقق هو sni=. فمع كتابة sni= وغياب skip-cert-verify أو ضبطه على false، يُتحقَّق من سلسلة الشهادة ومن اسم المضيف في الشهادة التي يقدّمها الموقع الواجهة مقابل ذلك الاسم، ويفشل الاتصال عند فشل التحقق. أما بلا sni= فلا يُتحقَّق من الشهادة ويُسجَّل تحذير مرة واحدة لكل سياسة عند أول استخدام، لأن الاسم الوحيد المتاح هو اسم المرحِّل، وهو ليس اسم موقع التغطية. وskip-cert-verify=true يتخطى التحقق في الحالتين.

fingerprint: اختياري

fingerprint=chrome

بصمة عميل TLS للمحاكاة. القيم المدعومة تشمل chrome، firefox، safari، ios، edge، 360، qq، android، random، والأسماء الأخرى المذكورة تحت fingerprint. استخدام بصمة متصفح شائعة يساعد في تجنب الاكتشاف. لاحظ أن android و random ليسا مميزين هنا — إذ يُعاملان معاملة chrome. أما none وأي قيمة لا يتعرّف عليها Chute فترفض الاتصال، لأن حزمة TLS الخاصة بالنظام لا تستطيع إجراء هذه المصافحة.

معاملات البروكسي مع MASQUE

MASQUE هو بروتوكول بروكسي قائم على HTTP/3 يمرّر حركة المرور داخل نفق QUIC. تتطلب سياسة MASQUE الحقول type وhost وport، بينما يكون رمز المصادقة token اختيارياً.

ProxyMASQUE = masque, 1.2.3.4, 443, token=auth-token, mode=connect-udp, sni=example.com, alpn=h3, skip-cert-verify=false, mux=true

token: اختياري

token=auth-token

رمز مصادقة Bearer اختياري لخادم MASQUE. يُقبل أيضاً الاسم المستعار masque-token=.

mode: اختياري

mode=connect-udp

يُقبل للتوافق لكنه لا يغير سلوك النفق: تستخدم تدفقات TCP دائماً نفق CONNECT عادياً، وتستخدم تدفقات UDP دائماً connect-udp. ويُقبل أيضاً الاسم المستعار masque-mode=.

mux: اختياري

mux=true

تمكين تعدد الإرسال عبر اتصال QUIC مشترك.

sni / alpn / skip-cert-verify: اختياري

نفس TLS. بما أن MASQUE يعمل عبر QUIC، يُستخدم عادةً alpn=h3.

معاملات البروكسي مع SSH

انظر بروكسي SSH للتوثيق الكامل.