Skip to content

Protocols and Transports.ar

Iman edited this page Sep 10, 2026 · 3 revisions

البروتوكولات ووسائل النقل

ويكي قزوين

يأتي هذا الدليل من ملف README الموجود. تحتفظ قياساتها بتواريخها الأصلية. لا يُبلغ نقل التوثيق هذا عن تشغيل اختباري جديد. English | فارسی | Русский | 中文

ما يمكنك لصقه وما سوف يرفضه

قمت بإحضار التكوين. وهذا ما يقبله الصندوق، مأخوذ من الكود الذي يقوم بالقبول وليس من قائمة الرغبات. تم قياس كل صف مقابل internal/link والمحرك المثبت.

إنه يعمل تم رفضه
مشاركة الروابط vless:// vmess:// ss:// socks:// trojan:// hysteria2:// hy2:// tuic:// ssr:// wireguard:// anytls:// naive+https:// hysteria:// (الإصدار 1)
المستندات الملصقة Clash and Clash.Meta YAML، الخام xray JSON، قائمة الروابط واحدة لكل سطر، اشتراك base64 blob عنوان URL للاشتراك، ومستند Clash مغلف بقاعدة 64، ومصفوفة JSON، ونص يكون سطره الأول عبارة عن تعليق
وسائل النقل raw (مكتوب أيضًا tcpws، grpc، httpupgrade، xhttp (أيضًا splithttpkcp و mkcp h2، h3، http، quic، gun
الأمن none، tls، reality xtls (النوع القديم)، allowInsecure
تدفق دون المستوى xtls-rprx-vision أو xtls-rprx-vision-udp443 أو لا شيء كل قيمة أخرى

h2 وh3 في هذا العمود المرفوض هما أسماء نقل. HTTP/2 وHTTP/3 يتم حمل أنفسهم: type=xhttp مع security=tls، وTLS ALPN يقرر الذي. راجع يتم تنفيذ HTTP/2 وHTTP/3 تحت عنوان مختلف الاسم.

ستة أشياء تفاجئ الناس، لذا فهي هنا وليس في الحاشية:

يتم استخدام الرابط الأول فقط. قم بلصق أربعين خادمًا وقمت بتكوين واحد؛ ال تخبرك اللوحة بعدد ما وجدته. يحتاج ss:// وsocks:// إلى نموذج base64 معلومات المستخدم الخاصة بهم، والتهجئة البسيطة method:password@host هي رفض. يعمل REALITY على raw وxhttp وgrpc فقط، لذلك يتم إقرانه مع يتم رفض WebSocket بواسطة المحرك في وقت اللصق بدلاً من الفشل لاحقًا. security= يجب أن يكون صغيرًا هنا على الرغم من أن المحرك نفسه ليس كذلك الرعاية، ويتم إبلاغك بالحرف الكبير TLS كـ none. plugin= يتم تجاهل المعلمة الموجودة على رابط ss:// دون ذكر ذلك. والاشتراك تم رفض عنوان URL الذي تم لصقه في مربع التكوين، لأن هذا المربع يأخذ التكوينات: the يتم إدخال العنوان في حقل الاشتراك بجانبه، ويقوم Caspian بجلبه فقط عند الضغط على الزر، من خلال النفق.

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

البروتوكولات ووسائل النقل

يحمل رابط المشاركة ثلاثة أشياء منفصلة، ويساعد على الفصل بينها: بروتوكول الوكيل، والنقل الذي يحمله، وطبقة التشفير المغلفة حول هذا النقل. رابط VLESS عبر WebSocket مع TLS ورابط VLESS عبر TCP العادي مع REALITY هما نفس البروتوكول الذي يصل إلى نفس النوع الخادم بطريقتين مختلفتين. لقد فشلوا بطرق مختلفة.

بروتوكولات الوكيل هي المخططات السبعة المذكورة أعلاه. VLESS هو الأكثر من ذلك تستخدم أمثلة هذا المستند، لأنه تم تصميم REALITY من أجله. لا شيء في الجهاز خاص به. المحلل اللغوي ينتج وصفا، يقوم internal/xcfg بتكوين مستند المحرك حوله وبقية الصندوق لا يعرف البروتوكول الذي يحمله.

تأتي عمليات النقل من xray-core ويتم تسميتها في المحلل اللغوي المباع:

  • tcp، مكتوب أيضًا raw
  • ws، لـ WebSocket
  • httpupgrade
  • xhttp، البروتوكول الذي كان يسمى سابقًا SplitHTTP. كلا التهجئة تحليل
  • grpc
  • kcp وmkcp، لـ mKCP

h2، http، h3 وquic ليسوا في تلك القائمة. نسخة المحرك هذه الدبابيس إزالتها، لذلك يتم رفض الارتباط الذي يطلب واحدًا بدلاً من حمله، و TestRemovedTransportsAreRefusedWithASentence في internal/link يحمل ذلك الرفض في مكانه

تعتمد مدى جودة قراءة الرفض على المسار الوارد. وثيقة Clash تسمي واحدًا يحصل على جملة حول النقل. نفس النقل في معلمة type= على رابط المشاركة يصل كرسالة عامة "لم يكن هناك شيء في النص الملصق وكيلاً الرابط يفهمه هذا المربع"، وهو صحيح وغير مفيد. TestRemovedTransportInAURIIsReportedLessWell يثبت هذا الاختلاف لذا فهو الفجوة المعروفة بدلا من المفاجأة.

يتم تنفيذ HTTP/2 وHTTP/3 تحت اسم مختلف

لا يعني رفض type=h2 أو type=quic أن الصندوق لا يمكنه التحدث بهما. وهذا يعني أن الإملاء انتقل. استبدل XHTTP كليهما، ويختار HTTP الخاص به الإصدار من TLS ALPN بدلاً من اسم النقل:

ماذا تريد ماذا أكتب
HTTP/3، وهو QUIC type=xhttp مع security=tls، alpn=h3 وmode=stream-one
HTTP/2 type=xhttp مع security=tls وأي ALPN ليس h3 بالضبط
سريع، دون XHTTP رابط hysteria2://، وهو رابط QUIC بالأسفل ويحتاج إلى alpn=h3

تصل المفاتيح إلى المحرك دون أن يمسها أحد: internal/xcfg يحمل الصادر كـ JSON غير شفاف ولا يقوم بفك ترميزه مطلقًا، لذلك alpn وmode وxmux وضبط QUIC تصل الكتلة تمامًا كما تم لصقها.

أربعة تفاصيل تحدد ما إذا كنت ستحصل على h3 أو ستحصل على شيء آخر بصمت:

يجب أن تكون alpn قيمة واحدة بالضبط ويجب أن تكون تلك القيمة h3. الكتابة يمنحك alpn=h3,h2 HTTP/2 بدون تحذير، لأن المحرك يأخذ قائمة بأي طول آخر كطلب للإصدار 2. REALITY يفرض HTTP/2 كلما إنه موجود، لذا فإن REALITY وh3 متنافيان ويتم الاقتران بينهما كنت H2 بدلا من خطأ. يجب تعيين mode بشكل صريح، لأن يتم الحل الافتراضي إلى packet-up بدلاً من شكل stream-one للمحرك أسماء كبديل QUIC. وdownloadSettings للتحميل المقسم و تم رفض التنزيل مع mode: stream-one؛ يحتاج هذا المزيج stream-up.

هناك تصادم واحد في المفردات يستحق ذكره بوضوح، لأنه يقرأ مثل التناقض: تم رفض type=h3، ومطلوب alpn=h3. هم مجالات مختلفة. الأسماء الأولى لوسيلة نقل لم تعد موجودة؛ الثاني أسماء البروتوكول الذي تم التفاوض عليه داخل TLS.

يتم قبول هذه التكوينات والتحقق من صحتها بواسطة الصندوق. لم يفعلوا ذلك بعد تم دفعه ضد خادم مباشر من هنا، لذا تعامل مع الصف باعتباره صف المحرك القدرة وليس كشيء شاهده هذا المشروع العمل.

طبقة الأمان هي reality أو tls أو none.

ليست كل مجموعة مفيدة بنفس القدر. عادةً ما يتم إقران REALITY مع عادي TCP، لأن طريقته بأكملها هي استعارة مصافحة TLS لموقع حقيقي، لذلك إن تغليفها بطبقة TLS أخرى يهزم هذه النقطة. WebSocket وHTTPUpgrade و يوجد XHTTP ليبدو مثل حركة مرور الويب العادية لشيء يقوم بفحص ملف اتصال، وعادة ما يتم إقرانها مع TLS لنفس السبب العادي الموقع هو. WebSocket مع security=none هو الشكل الوحيد الذي يجب التفكير فيه مرتين حول. إنه نص عادي على السلك، ولا يكون معقولًا إلا عندما يكون هناك شيء آخر يوفر بالفعل التشفير، مثل CDN الذي ينهي TLS أمام الخادم.

ثلاث مطالبات مختلفة، متباعدة

التمييز أدناه هو أهم شيء في هذه الوثيقة. اقرأ عناوين الأعمدة قبل الصفوف.

المطالبة ما يرتكز عليه ما يستحق
المحلل يقبل ذلك internal/link، ووثيقة المحرك الذهبي المخصصة الوثيقة مستقرة. لم يتم الاتصال بأي شيء
يحمل بايت test/tunnel، خادم حقيقي للأشعة السينية على الاسترجاع انتقلت حركة المرور من خلال البروتوكول. لا يوجد مخرج IP ولا جهاز ولا إنترنت
لقد ثبت من النهاية إلى النهاية test/hardware، هاتف حقيقي على نقطة الاتصال غادرت حركة المرور الحقيقية الصندوق وتم التقاط عنوان الخروج وتسميته

ما حمل البايتات من خلال خادم حقيقي

تمت الإضافة بواسطة test/tunnel. يتم تنفيذ كل مخطط يقبله المحلل اللغوي من النهاية إلى النهاية مقابل مثيل حقيقي للأشعة السينية، تم إنشاؤه من تبعية هذه الوحدة الخاصة و يتم تحميلها من خلال نفس اللودر الذي يستخدمه internal/engine. جانب العميل هو مسار المنتج، بدون تعديل: link.Parse، ثم xcfg.Build، ثم engine.Engine.Start. لا يوجد تكوين مكتوب بخط اليد.

البروتوكول النقل الأمن يحمل طلب HTTP
ليس برنامج التعاون الفني (الخام) لا شيء نعم
VMess برنامج التعاون الفني (الخام) لا شيء نعم
Shadowsocks، aes-256-gcm برنامج التعاون الفني (الخام) لا شيء نعم
الجوارب برنامج التعاون الفني (الخام) لا شيء نعم
Trojan برنامج التعاون الفني (الخام) TLS، مثبت بواسطة الملخص نعم
Hysteria2، والاسم المستعار hy2 كويك TLS، مثبت بواسطة الملخص نعم

أربعة عناصر تحكم توقف الطلب الذي تخطى النفق من المرور، والأربعة جميعهم تشغيل بدلا من التأكيد في النثر. لا يتم إخبار العميل أبدًا بمكان وجوده Origin، ويتم إعطاؤه اسم .invalid ومنفذ الشرك. الاسم لا يمكن حلها، ويقول الجناح ذلك بصوت عالٍ إذا كان هناك محلل على الجهاز يجيب عليه على أي حال. يتحقق الأصل من مكان معالجة الطلب، وليس فقط أنه وصل. يقوم الشرك بإحصاء عدد الزيارات الخاصة به، ويجب إضافة طلب عبر النفق لا شيء. TestEveryCarriageProofCanFail و TestTheProofRejectsARequestThatDidNotGoThroughTheTunnel هي التي تصنع تلك الأشياء تسيطر على الأدلة بدلا من النية.

اقرأ كل صف بشكل ضيق. كل صف ما عدا Hysteria2 يعمل على TCP الخام. لا يوجد صف محركات الأقراص REALITY، الذي يحتاج جانب الخادم الخاص به إلى هدف مصافحة حقيقي. Shadowsocks هو aes-256-gcm فقط، لأن شفرات 2022 تأخذ مسارًا برمجيًا مختلفًا. كل صف يحمل طلب TCP، ويتم إيقاف تشغيل UDP Associate. كل شيء على الاسترجاع، لذلك لم يتم القبض على أي خروج IP ولا شيء يمكن أن يكون.

يقرأ TestEveryProtocolTheParserAcceptsIsDrivenEndToEnd المخطط المقبول قائمة من مصدر internal/link، لذلك لا يمكن إضافة المخطط الثامن بدون صف هنا.

ما تم إثباته بالفعل على الأجهزة

يوضح الجدول أدناه ما اجتازته حركة المرور الحقيقية مع التقاط عنوان IP للخروج. ذلك ليس ما يقبله المحلل اللغوي، وليس ما تحمله مجموعة الاسترجاع.

البروتوكول النقل الأمن ثبت نهاية إلى نهاية
ليس برنامج التعاون الفني (الخام) REALITY نعم، على ثلاثة خوادم منفصلة
ليس دبليو إس (ويب سوكيت) لا شيء، بالإضافة إلى تشفير VLESS نعم
ليس دبليو إس (ويب سوكيت) TLS نعم، من خلال CDN
ليس httpupgrade TLS نعم، من خلال CDN
ليس xhttp TLS نعم
VMess، Trojan، Shadowsocks، الجوارب، الهستيريا2 أي أي لا

تم إثبات كل هذه الأشياء من خلال تشغيل متصفح حقيقي على هاتف حقيقي متصل بـ نقطة اتصال. تم الحصول على عنوان الخروج من مصدرين مستقلين ومطابقته إلى الخادم أسماء التكوين. تم استخدام ثلاثة خوادم مختلفة و أعاد كل منها عنوانًا مختلفًا، لذا لا يمكن إجراء قراءة متكررة أو مخزنة مؤقتًا مخطئ لنفق العمل.

والصف الذي لم يثبت ليس ادعاء بالكسر. ومن الادعاء بذلك لم يشاهد أحد حزمة تخرج من النهاية البعيدة، وهو شيء مختلف والشيء الوحيد الذي يعامله هذا المشروع كدليل. وثيقة المحرك لكل منهما النقل ينتج IS مثبتًا كملف ذهبي، لذا تغيير في كيفية واحد يظهر مؤلف على شكل فرق. وهذا يثبت أن الوثيقة مستقرة ولا تقول شيئًا حول ما إذا كان النقل يتصل.

لماذا لا يزال الصف الذي لا يحتوي على أمان النقل مشفرًا

يدور العمود security أعلاه حول الطبقة المغلفة حول النقل، و none لا يعني "عدم وجود تشفير". وهذا يعني عدم وجود TLS ولا REALITY. الذي - التي يستحق أن نكون دقيقين بشأنه، لأن قراءته بالطريقة الأخرى ستكون مثيرة للقلق وقراءتها بسخاء شديد ستكون أسوأ.

VLESS في حد ذاته لا يحمل أي تشفير. إنه بروتوكول عديم الجنسية يتوقع الطبقة الموجودة أسفلها لتوفير السرية، والتي عادة ما تكون REALITY أو TLS. رابط VLESS عبر WebSocket مع security=none ولن يكون هناك أي شيء آخر نص عادي على السلك، وسيتم إثبات عنوان الخروج أثناء كل حزمة كان قابلاً للقراءة بواسطة أي شيء على المسار.

ما يجعل هذا الصف آمنًا هو تشفير VLESS، الموجود في الرابط المعلمة encryption=. وهو عبارة عن تبادل مفاتيح هجين، ML-KEM-768 لـ مقاومة ما بعد الكم مع X25519، المطبقة على طبقة VLESS نفسها وليس تحتها. لذلك يتم تشفير حركة المرور، ويتم تشفيرها بواسطة شيء مصمم للبقاء آمنًا ضد المهاجم الذي يسجله اليوم و لديه جهاز كمبيوتر الكم في وقت لاحق. رابط يحمل encryption=none AND security=none ليس لديه أي منهما، وهذا هو المزيج الذي يجب رفضه.

هذا ليس إطار عمل بروتوكول الضوضاء (noiseprotocol.org). لا شيء في هذا الجهاز، في محلل ارتباط المشاركة المباع، أو في المحرك الذي ينفذ الضوضاء. تظهر كلمة "ضوضاء" في تكوين xray-core لشيء غير ذي صلة، حشو حركة المرور بالبايتات العشوائية لتغيير شكلها على السلك، وهو التعتيم وليس المصافحة. الشيء الذي يعطي هذا الصف السرية هي تشفير VLESS، والاسم مهم لأن الاثنين تقديم ضمانات مختلفة.

تم قياسه وليس افتراضه بتاريخ 30-08-2026. لا تقوم هذه الحزمة بإعادة بناء ملف المجال الصادر حسب المجال. إنه يعيد تسلسل ما أنتجه المحلل اللغوي، و تسير إعدادات البروتوكول على شكل نقطة غير شفافة. ولهذا السبب المعلمة ينجو. ولهذا السبب أيضًا لن ينكسر أي شيء إذا توقف عن البقاء: لا يوجد حقل سيكون مفقودًا، ولن يتغير أي نوع، ولن يلاحظ أي اختبار آخر، بينما حمل النفق حركة مرور المستخدم بشكل واضح مع بقاء كل فحص باللون الأخضر. TestVLESSEncryptionSurvivesIntoTheEngineDocument في internal/link هو Guard، وقد تمت مشاهدته وهو يفشل في مواجهة هذا التخفيض الصامت من قبل تم الاحتفاظ به.

اسم الشهادة غير متطابق، والإصلاح من جانب العميل

نتيجة واحدة تستحق التسجيل، لأنه خطأ هذا الجهاز بشكل صحيح يرفض الورق. أشار تكوينان إلى عنوان الخادم الخاص بينما يحمل اسم TLS الخاص بـ CDN أمامه. أفاد المحرك:

النقل/الإنترنت/httpupgrade: فشل في طلب الطلب ... Tls: فشل في التحقق من الشهادة: x509: الشهادة صالحة لـ , not

هذه شهادة لا تتطابق حقًا مع الاسم المطلوب، و رفض ذلك هو السلوك الذي تريده. قبول ذلك يعني أن النفق يمكن أن يفعل ذلك يتم إنهاؤها بأي شيء يحمل أي شهادة.

السبب والإصلاح كلاهما من جانب العميل، ولا يوجد تغيير في الخادم مطلوب. يحمل رابط المشاركة اسمين يفترض الأشخاص أن عليهما مطابقتهما والقيام به ليس:

sni اسم TLS يتحقق من صحة الشهادة مقابل استضافة الاسم الذي يوجه الخادم الطلب عليه، وهو رأس HTTP

الروابط الفاشلة تحمل اسم CDN في كليهما. من خلال CDN الذي يعمل، لأن CDN يحمل شهادة لذلك. وأشار مباشرة إلى الأصل ذلك لا يمكن، لأن الأصل يحمل شهادة للقمة فقط. اضبط sni على الاسم الذي تحمله الشهادة بالفعل، واترك host كاسم مسارات الخادم على:

sni=example.com host=cdn.example.com

تم القياس بتاريخ 30-08-2026. رابطان فشلا بسبب خطأ في الشهادة فوق كل من متصل بعد ذلك تغيير واحد. تم التقاط عناوين الخروج من مصدرين مستقلين ومتطابقين مع خوادمهم الخاصة، وتسريب DNS و تم تمرير الشيكات المغلقة الفاشلة في نفس التشغيل.

لذا، إذا فشلت عملية النقل فقط عند الإشارة مباشرة إلى الأصل، قارن sni ضد الأسماء البديلة لموضوع شهادة المنشأ قبل الشك النقل. openssl s_client -connect <address>:443 -servername <name> يطبع ما يقدمه الخادم بالفعل.

تأخذ اللوحة رابطًا تم لصقه وليس صورة

إن إسقاط صورة QR موصوف في التصميم، القسم 5.2، وهو ليس كذلك تم التنفيذ. internal/panel/qr هو برنامج تشفير فقط، ولا يوجد معالج فيه يقرأ internal/panel التحميل متعدد الأجزاء. رمز الاستجابة السريعة الذي تنتجه اللوحة هو الذي يقوم الهاتف بمسحه ضوئيًا للانضمام إلى نقطة الاتصال. internal/panel/view.go يبنيها مع qr.Encode وqr.WiFiJoin، لذلك لا توجد مكتبة صور ولا توجد خدمة عن بعد المعنية.

الإنجليزية: HTTP/2، HTTP/3 | English | فارسی: HTTP/2، HTTP/3 | فارسی | الروسية: HTTP/2، HTTP/3 | Русский | مثل: HTTP/2، HTTP/3 | 中文

أدلة Caspian: الإعداد والبروتوكولات المدعومة · انتحال SNI للتحايل على DPI: الإعداد والحدود.

Clone this wiki locally