-
Notifications
You must be signed in to change notification settings - Fork 8
Protocols and Transports.ar
يأتي هذا الدليل من ملف 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 (مكتوب أيضًا tcp)، ws، grpc، httpupgrade، xhttp (أيضًا splithttp)، kcp و 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 يثبت هذا الاختلاف لذا فهو
الفجوة المعروفة بدلا من المفاجأة.
لا يعني رفض 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: الإعداد والحدود.
- Architecture and data flow
- Development and testing
- Documentation map
- Getting started
- Install on Linux and Raspberry Pi
- Install on macOS
- Install on Windows
- Installation
- Licence and credits
- Page template
- Panel and configuration
- Protocols and transports
- Releases and maintenance
- Security and privacy
- Caspian SNI spoofing and TLS splitting for DPI circumvention
- Third-party code and credits
- Translations
- Troubleshooting for home users