كيفية إعداد خادم مصفوفة خلف وكيل Cloudflare

يمكن لخادم Matrix أن يعمل خلف Cloudflare، لكن الإعداد يعتمد على كيفية اكتشاف العملاء والخوادم المنزلية الأخرى له. يدعم وكيل HTTP القياسي من Cloudflare بروتوكول HTTPS على المنفذ 443؛ بينما يستخدم Synapse عادةً المنفذ 8448 افتراضيًا، وهو غير مدرج في قائمة المنافذ المُرَكَّزة القياسية من Cloudflare. يتمثل الحل الأمثل في إتاحة الوصول إلى Synapse عبر وكيل عكسي على المنفذ 443 ونشر سجلات Matrix المعروفة التي توجه حركة مرور العملاء والاتحاد إلى اسم المضيف هذا. أو بدلاً من ذلك، يمكن الإبقاء على الاتحاد على المنفذ 8448 وجعل سجل DNS هذا خاصًا بنظام أسماء النطاقات فقط.

@alice:example.comيستخدم هذا الدليل Synapse، وهو تطبيق Matrix الرسمي لخوادم المنازل، مع معرّفات Matrix ونقاط نهاية العميل كمثال matrix.example.com. استبدل هذه الأسماء والعناوين بمعلوماتك الخاصة. تفترض هذه التعليمات تثبيت Synapse وخادم وكيل عكسي HTTPS مسبقًا. لا تنطبق هذه التعليمات دون تغيير على جميع تطبيقات خوادم المنازل. تمت مراجعتها وفقًا لأحدث وثائق Cloudflare وElement Synapse بتاريخ 6 أكتوبر 2026.

اختر تصميم الشبكة المناسب

يُعدّ وكيل orange-cloud من Cloudflare وكيلاً عكسياً لبروتوكولي HTTP/HTTPS. وهو يعمل كوسيط بين العملاء وخادمك الأصلي لطلبات الويب المُوجّهة عبر الوكيل؛ ولا يُوجّه جميع منافذ TCP بشكل عشوائي. تشمل منافذ HTTPS القياسية لديه 443 و8443، ولكنه لا يشمل منفذ الاتحاد 8448 الشائع الاستخدام في Synapse. راجع منافذ الشبكة المدعومة من Cloudflare وقيود التوجيه عبر الوكيل .

يُستخدم التخطيط الأول أدناه. لا يقوم سجل DNS المُوَجَّه بالوكيل، في حد ذاته، بتكوين اكتشاف المصفوفة، أو التوجيه العكسي، أو بروتوكول أمان طبقة النقل (TLS)، أو سياسة جدار الحماية.

1. حدد اسم خادم المصفوفة قبل تكوين نظام أسماء النطاقات (DNS).

اسم خادم Matrix هو الجزء الذي يلي النقطتين في مُعرّف المستخدم. في هذا المثال، هو example.com، لذا فإن مُعرّفات المستخدمين هي مثل @alice:example.com. اسم مضيف العميل التقني هو matrix.example.com. يُمكّن هذا الفصل النطاق المُستخدم في مُعرّفات المستخدمين من البقاء ثابتًا بينما يتم توجيه حركة المرور إلى اسم مضيف آخر. إذا كان Synapse مُهيأً بالفعل، فلا تُغيّره server_nameبشكل عشوائي: فهو جزء من هوية المستخدم والغرفة، وتغييره يُعدّ عملية نقل، وليس تعديلًا للوكيل.

خطة لتقديم مستندين صغيرين لاكتشاف البيانات بصيغة JSON من نطاق اسم الخادم:

• https://example.com/.well-known/matrix/clientيُخبر العملاء المتوافقين باستخدام https://matrix.example.com.
• https://example.com/.well-known/matrix/serverيطلب من خوادم المنازل الأخرى الوصول إلى الاتحاد على matrix.example.com:443.

يحتاج مستند العميل إلى Access-Control-Allow-Origin: *رأس استجابة. يتضمن دليل تفويض Synapse أمثلة على هذه السجلات وبنيتها المتوقعة: تفويض اتحاد Synapse .

2. إنشاء سجلات نظام أسماء النطاقات (DNS) الخاصة بـ Cloudflare

في نظام أسماء النطاقات (DNS) الخاص بـ Cloudflare، أنشئ Aسجلًا باسم matrixيشير إلى عنوان IPv4 العام للخادم. أضف AAAAسجلًا آخر فقط إذا كان المصدر يتمتع باتصال IPv6 فعال وجدار حماية مُهيأ لـ IPv6. اضبط حالة وكيل اسم مضيف الويب على "مُوَجَّه" (سحابة برتقالية). إذا كان النطاق الرئيسي يشير أيضًا إلى هذا الخادم وسيُقدِّم الملفات المعروفة، فقم بتوجيه سجل الويب الخاص به أيضًا.

احتفظ بالسجلات غير ذات الصلة، بما في ذلك سجلات البريد، بإعدادات DNS الخاصة بها فقط. لا يتم توجيه سجلات MX وTXT عبر الوكيل. توضح Cloudflare أن سجل A أو AAAA أو CNAME المُوَجَّه عبر الوكيل يُوجِّه طلبات HTTP/HTTPS من خلال Cloudflare، بينما يُعيد DNS فقط عنوان المصدر مباشرةً: سلوك حالة وكيل Cloudflare .

اسمح باستقبال طلبات HTTPS الواردة من Cloudflare إلى الخادم الأصلي. لمزيد من الحماية، قيّد جدار الحماية الخاص بالخادم الأصلي بنطاقات عناوين IP المنشورة من Cloudflare، وحافظ على تحديث هذه النطاقات. إذا كان عنوان IP الخاص بالخادم مكشوفًا قبل تفعيل المنطقة، فإن توجيه DNS عبر الوكيل لا يُبطل هذا العنوان القديم؛ لذا يُنصح بتغيير عنوان IP الخاص بالخادم الأصلي بعد التفعيل. لا تفترض أن رمز السحابة البرتقالي وحده يمنع الوصول المباشر إلى الخادم الأصلي.

3. قم بتكوين بروتوكول HTTPS بين Cloudflare والمصدر

في إعدادات SSL/TLS الخاصة بـ Cloudflare، استخدم الوضع الكامل (الصارم) عندما يُقدّم المصدر شهادة صالحة لاسم المضيف، مثل شهادة موثوقة علنًا أو شهادة CA الخاصة بمصدر Cloudflare. يقوم الوضع الكامل (الصارم) بتشفير اتصال Cloudflare بالمصدر والتحقق من صحة شهادة المصدر؛ بينما لا يوفر الوضع المرن نفس مسار TLS من البداية إلى النهاية. راجع وثائق Cloudflare الخاصة بالوضع الكامل (الصارم) .

قم بتثبيت الشهادة والمفتاح الخاص على الخادم الوكيل العكسي، وليس بالضرورة في Synapse. يجب أن يستمع الخادم الوكيل العكسي على المنفذ العام 443، وأن يُعيد توجيه طلبات Matrix داخليًا إلى مُستمع HTTP الخاص بـ Synapse، والذي يكون عادةً على المنفذ 8008. لا تُعرّض مُستمع Synapse للعامة إذا كان من المُفترض أن يكون الخادم الوكيل العكسي هو نقطة الدخول الوحيدة.

4. أخبر Synapse أنه موجود خلف وكيل عكسي موثوق به

في مُستمع HTTP ذي الصلة homeserver.yaml، فعّل معالجة الرؤوس المُعاد توجيهها. مثال مُبسّط لخادم غير مُغلّف:

listeners:
  - port: 8008
    type: http
    tls: false
    x_forwarded: true
    bind_addresses: ['127.0.0.1']
    resources:
      - names: [client, federation]
        compress: false

قم بدمج هذه الإعدادات في المستمع الحالي بدلاً من استبدال التكوين بالكامل. توصي وثائق Synapse المُحدّثة x_forwarded: trueباستخدام خادم وكيل عكسي، وتقترح الربط بالمضيف المحلي (localhost) عند تشغيل الوكيل على نفس المضيف. في حالة نشر الحاويات، قد يؤدي ربط Synapse بحلقة الاسترجاع الخاصة بالحاوية إلى منع وكيل المضيف من الوصول إليه؛ استخدم عنوان شبكة الحاوية أو الخدمة وقم بحماية هذا المسار بجدار ناري. راجع دليل الوكيل العكسي الحالي لـ Synapse قبل تغيير إعدادات المستمع.

لا تُعتبر رؤوس التوجيه موثوقة إلا عندما يقبل Synapse حركة المرور من خادم الوكيل الذي تتحكم به. إذا كان Cloudflare هو المسار الوحيد المتاح للإنترنت، فامنع الوصول العام المباشر إلى المصدر، وقم بتهيئة خادم الوكيل لتمرير عنوان العميل الصحيح. $remote_addrوإلا، فسيكون عنوان Nginx هو عنوان Cloudflare لأن Cloudflare متصل بـ Nginx. قبل استخدام رأس التوجيه، قم بتهيئة وحدة real-IP في Nginx بحيث تثق فقط بنطاقات المصادر المنشورة من Cloudflare CF-Connecting-IP؛ ولا تثق أبدًا بهذا الرأس من عملاء الإنترنت العشوائيين. حافظ على خصوصية واجهة برمجة تطبيقات إدارة Synapse إلا إذا كان لديك سبب محدد لعرضها.

5. توجيه مسارات المصفوفة دون إعادة كتابتها

قم بتهيئة خادم الوكيل العكسي لإرسال كل من الطلب /_matrixوعنوان URL /_synapse/clientإلى Synapse. حافظ على عنوان URL للطلب بدقة. قد تفشل توقيعات طلبات اتحاد Synapse إذا قام خادم الوكيل بفك تشفير أو توحيد أجزاء المسار المشفرة.

إليك مثالًا مُختصرًا لـ Nginx matrix.example.com. يفترض هذا المثال أن توجيهات شهادة TLS الخاصة بك مُهيأة بالفعل لكتلة الخادم هذه، وأن الخادم الوكيل العكسي و Synapse يعملان على نفس المضيف:

server {
    listen 443 ssl;
    server_name matrix.example.com;

    location ~ ^(/_matrix|/_synapse/client) {
        proxy_pass http://127.0.0.1:8008;
        proxy_set_header X-Forwarded-For $remote_addr;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Host $host;
        proxy_http_version 1.1;
        client_max_body_size 50M;
    }
}

لا تُضِف لاحقة URI إلى موقع التعبير النمطي هذا proxy_pass. تشير وثائق Synapse للوكيل إلى أن توحيد URI يُعد سببًا لأخطاء توقيع الاتحاد. اضبط أيضًا client_max_body_sizeليتوافق مع حد التحميل في Synapse وأي حد لخطة Cloudflare ينطبق على منطقتك. القيمة 50Mالمذكورة أعلاه هي مثال فقط، وليست توصية عامة.

تدعم Cloudflare تقنية WebSockets في باقاتها، ويمكن لعملاء Matrix استخدام اتصالات طويلة الأمد. تأكد من أن خادم البروكسي الخاص بك يسمح بالترقية، وأن أي جدار حماية لتطبيقات الويب (WAF) أو قواعد تحديد معدل الطلبات لا تمنع طلبات Matrix المشروعة. توضح وثائق WebSockets الخاصة بـ Cloudflare كيفية تعاملها مع الاتصالات المُرَقَّاة.

6. انشر الردود المعروفة

أرسل الردين التاليين عبر example.comبروتوكول HTTPS. يمكنك إرسالهما من خادم الويب الخاص بك، أو من مضيف ثابت، أو من مضيف افتراضي منفصل. تأكد من فصل مستندات العميل عن مستندات الاتحاد.

GET /.well-known/matrix/client
HTTP/1.1 200 OK
Content-Type: application/json
Access-Control-Allow-Origin: *

{"m.homeserver":{"base_url":"https://matrix.example.com"}}

GET /.well-known/matrix/server
HTTP/1.1 200 OK
Content-Type: application/json

{"m.server":"matrix.example.com:443"}

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

7. حافظ على ديناميكية حركة مرور واجهة برمجة التطبيقات (API) وحدود التحميلات.

لا تقم بتخزين استجابات واجهة برمجة تطبيقات Matrix المُصادق عليها مؤقتًا. أضف قاعدة تخزين مؤقت في Cloudflare لتجاوز التخزين المؤقت لمسارات واجهة برمجة تطبيقات Matrix، بما في ذلك [اسم المسار 1] /_matrix/*و /_synapse/client/*[اسم المسار 2]، إلا إذا كان لديك سببٌ مُختَبَرٌ بعناية للتعامل مع استجابة عامة مُحددة بشكل مختلف. تجنّب قواعد جدار حماية تطبيقات الويب (WAF) أو قواعد الروبوتات العامة التي تُشكّك في نقاط نهاية الاتحاد أو تحظرها؛ إذ تأتي طلبات الاتحاد من العديد من الخوادم المنزلية المستقلة. إذا كانت قاعدة الأمان ضرورية، فاختبرها على تسجيل دخول العميل، والمزامنة، وتحميل الوسائط، والاتحاد قبل تطبيقها بشكل عام.

توجد عدة حدود مستقلة لحجم الملفات المرفوعة: حدود العميل، وحدود خطة أو منطقة Cloudflare، وحدود حجم البيانات في الخادم الوكيل العكسي، وحدود Synapse max_upload_size. يشير الخطأ 413 إلى أن أحد هذه الحدود رفض الطلب. تنشر Cloudflare حدود الرفع الخاصة بكل خطة، وتوضح أنه يمكن تعديل هذه الإعدادات ضمن القيود الموثقة: صفحة استكشاف أخطاء الخطأ 413 على موقع Cloudflare . ارفع الحدود الضرورية فقط، واختبر الملف بحجم أصغر من الحد الأقصى المُحدد قبل زيادتها.

8. التحقق من وصول العميل واكتشافه وربطه

قم بتشغيل هذه الفحوصات من جهاز خارج شبكة خادمك. استبدل أسماء المضيفين المذكورة في المثال:

curl -i https://example.com/.well-known/matrix/client
curl -i https://example.com/.well-known/matrix/server
curl -i https://matrix.example.com/_matrix/client/versions
curl -i https://matrix.example.com/health

يجب أن تُعيد أول طلبين رمز HTTP 200، ومحتوى JSON، والقيم المتوقعة. يجب أن يتضمن مستند العميل ترويسة CORS. يجب أن تُعيد نقطة نهاية إصدارات العميل بيانات JSON من Synapse عبر Cloudflare. تُعيد نقطة نهاية صحة Synapse رمز HTTP 200 عند الوصول إليها عبر مستمع مُهيأ، ولكنها لا تُغني عن التحقق من تسجيل الدخول أو الاتحاد.

ثم سجّل الدخول باستخدام عميل Matrix باستخدام معرّف ينتهي بـ :example.com، وانضم إلى غرفة مستضافة في مكان آخر، وتأكد من مزامنة الرسائل وتحديثات العضوية. استخدم أداة اختبار اتحاد Matrix أو خادمًا منزليًا ثانيًا للتحقق من اكتشاف الخادم والاتحاد. /_matrix/client/versionsيُثبت نجاح الطلب إلى فقط أن المسار المواجه للعميل يعمل؛ ولا يُثبت صحة اكتشاف الاتحاد أو التوقيع أو الاتحاد الصادر.

كيف يبدو النجاح؟ ومتى يجب تغيير التصميم؟

• يتصل العملاء من خلال Cloudflare: يتم حل DNS إلى عناوين Cloudflare، ويستخدم HTTPS الشهادة المقصودة، وتقوم واجهة برمجة تطبيقات عميل Matrix بإرجاع استجابة.
• الاكتشاف صحيح: كلا عنواني URL المعروفين يعيدان JSON الصحيح، ويجتاز مستند العميل عمليات التحقق من المصادر المختلفة.
• يعمل نظام الاتحاد: يكتشف خادم بعيد نقطة النهاية المُعلنة ويمكنه تبادل حالة الغرفة. إذا فشل تفويض المنفذ 443 بينما يعمل المنفذ 8448 المباشر، فافحص سجل الشبكة المعروف، وتوجيه مسار الوكيل، وقواعد جدار حماية تطبيقات الويب (WAF).
• تتم عمليات التحميل بالحجم المتوقع: اختبر عملية تحميل نموذجية. إذا نجحت عمليات التحميل للملفات الصغيرة، بينما أعادت الملفات الأكبر حجماً الخطأ 413، فقارن حدود الحجم الأربعة جميعها بدلاً من تغيير إعدادات Synapse فقط.
• المصدر ليس مسارًا عامًا بديلًا: يجب حظر الطلبات المباشرة إلى المصدر أو تقييدها وفقًا للتصميم. إذا استمرت هذه الطلبات في الوصول إلى خدمة Matrix، فقم بتصحيح إعدادات جدار الحماية والوكيل الموثوق.

استخدم ربط DNS فقط على المنفذ 8448 إذا كانت متطلباتك أو تطبيقك لا يسمح بتوجيه الربط على المنفذ 443، ولكن اعلم أن هذا يكشف عنوان المصدر ويزيل حماية وكيل HTTP من Cloudflare لهذا الاسم المضيف. يُعد Spectrum خيارًا آخر للمنافذ غير القياسية، ويخضع ذلك لتوافر المنتج وقيود الخطة. كما أن استخدام وكيل Cloudflare يعني إنهاء TLS عند Cloudflare قبل إنشاء اتصال TLS ثانٍ مع مصدرك؛ يحمي تشفير Matrix من طرف إلى طرف محتوى الرسائل المشفرة، ولكنه لا يخفي بيانات تعريف الاتصال أو المحتوى غير المشفر من طرف إلى طرف عن الخدمات التي تعالج طلب HTTP. اختر البنية بناءً على متطلبات الخصوصية والربط والتوافر، ثم أعد الاختبار بعد إجراء تغييرات على DNS أو الشهادات أو Synapse أو قواعد Cloudflare.