Documentation Index
Fetch the complete documentation index at: https://docs.openclaw.ai/llms.txt
Use this file to discover all available pages before exploring further.
متى تستخدمه
استخدم وضع مصادقةtrusted-proxy عندما:
- تشغّل OpenClaw خلف وكيل واعٍ بالهوية (Pomerium، أو Caddy + OAuth، أو nginx + oauth2-proxy، أو Traefik + forward auth).
- يتولى الوكيل كل المصادقة ويمرر هوية المستخدم عبر الرؤوس.
- تكون في بيئة Kubernetes أو حاويات يكون فيها الوكيل هو المسار الوحيد إلى Gateway.
- تواجه أخطاء مقبس الويب
1008 unauthorizedلأن المتصفحات لا يمكنها تمرير الرموز في حمولات WS.
متى لا تستخدمه
- إذا كان الوكيل لديك لا يصادق المستخدمين (مجرد منهٍ لـ TLS أو موازن تحميل).
- إذا كان هناك أي مسار إلى Gateway يتجاوز الوكيل (ثغرات جدار ناري، وصول عبر الشبكة الداخلية).
- إذا لم تكن متأكدًا مما إذا كان الوكيل لديك يزيل/يستبدل الرؤوس المعاد توجيهها بشكل صحيح.
- إذا كنت تحتاج فقط إلى وصول شخصي لمستخدم واحد (فكّر في Tailscale Serve + loopback لإعداد أبسط).
كيف يعمل
يضيف الوكيل رأس هوية
يضيف الوكيل رأسًا يتضمن هوية المستخدم المصادق عليه (مثل
x-forwarded-user: nick@example.com).يتحقق Gateway من المصدر الموثوق
يتحقق OpenClaw من أن الطلب جاء من عنوان IP لوكيل موثوق (مهيأ في
gateway.trustedProxies).سلوك إقران واجهة التحكم
عندما يكونgateway.auth.mode = "trusted-proxy" نشطًا ويجتاز الطلب فحوصات الوكيل الموثوق، يمكن لجلسات مقبس الويب الخاصة بواجهة التحكم الاتصال دون هوية إقران الجهاز.
الآثار:
- لم يعد الإقران بوابة الوصول الأساسية إلى واجهة التحكم في هذا الوضع.
- تصبح سياسة مصادقة الوكيل العكسي و
allowUsersهما التحكم الفعلي في الوصول. - أبقِ دخول Gateway مقفلًا على عناوين IP الخاصة بالوكيل الموثوق فقط (
gateway.trustedProxies+ جدار ناري).
التهيئة
مرجع التهيئة
مصفوفة عناوين IP للوكلاء المطلوب الوثوق بها. تُرفض الطلبات الواردة من عناوين IP أخرى.
يجب أن تكون
"trusted-proxy".اسم الرأس الذي يحتوي على هوية المستخدم المصادق عليه.
رؤوس إضافية يجب أن تكون موجودة حتى يُعد الطلب موثوقًا.
قائمة سماح لهويات المستخدمين. يعني الفراغ السماح لكل المستخدمين المصادق عليهم.
دعم اختياري صريح للوكلاء العكسيين عبر loopback على المضيف نفسه. القيمة الافتراضية
false.إنهاء TLS وHSTS
استخدم نقطة إنهاء TLS واحدة وطبّق HSTS هناك.- إنهاء TLS عند الوكيل (موصى به)
- إنهاء TLS عند Gateway
عندما يتولى الوكيل العكسي لديك HTTPS لـ
https://control.example.com، اضبط Strict-Transport-Security عند الوكيل لذلك النطاق.- مناسب جيدًا لعمليات النشر المواجهة للإنترنت.
- يبقي سياسة الشهادة وتقوية HTTP في مكان واحد.
- يمكن أن يبقى OpenClaw على HTTP عبر loopback خلف الوكيل.
إرشادات الطرح
- ابدأ أولًا بمدة قصوى قصيرة (على سبيل المثال
max-age=300) أثناء التحقق من حركة المرور. - زد إلى قيم طويلة الأمد (على سبيل المثال
max-age=31536000) فقط بعد ارتفاع الثقة. - أضف
includeSubDomainsفقط إذا كان كل نطاق فرعي جاهزًا لـ HTTPS. - استخدم التحميل المسبق فقط إذا كنت تستوفي عمدًا متطلبات التحميل المسبق لمجموعة نطاقاتك الكاملة.
- لا يستفيد التطوير المحلي المعتمد فقط على loopback من HSTS.
أمثلة إعداد الوكيل
Pomerium
Pomerium
يمرر Pomerium الهوية في مقتطف تهيئة Pomerium:
x-pomerium-claim-email (أو رؤوس مطالبات أخرى) وJWT في x-pomerium-jwt-assertion.Caddy مع OAuth
Caddy مع OAuth
يستطيع Caddy مع Plugin مقتطف Caddyfile:
caddy-security مصادقة المستخدمين وتمرير رؤوس الهوية.nginx + oauth2-proxy
nginx + oauth2-proxy
يصادق oauth2-proxy المستخدمين ويمرر الهوية في مقتطف تهيئة nginx:
x-auth-request-email.Traefik مع forward auth
Traefik مع forward auth
تهيئة الرموز المختلطة
يرفض OpenClaw التهيئات المبهمة التي يكون فيها كل منgateway.auth.token (أو OPENCLAW_GATEWAY_TOKEN) ووضع trusted-proxy نشطين في الوقت نفسه. قد تجعل تهيئات الرموز المختلطة طلبات loopback تصادق بصمت عبر مسار المصادقة الخاطئ.
إذا رأيت خطأ mixed_trusted_proxy_token عند بدء التشغيل:
- أزِل الرمز المشترك عند استخدام وضع الوكيل الموثوق، أو
- بدّل
gateway.auth.modeإلى"token"إذا كنت تقصد المصادقة المعتمدة على الرمز.
gateway.auth.password / OPENCLAW_GATEWAY_PASSWORD بدلًا من ذلك. يظل الرجوع إلى الرمز غير مدعوم عمدًا في وضع الوكيل الموثوق.
رأس نطاقات المشغل
مصادقة الوكيل الموثوق هي وضع HTTP حامل للهوية، لذا يمكن للمستدعين اختياريًا إعلان نطاقات المشغل باستخدامx-openclaw-scopes.
أمثلة:
x-openclaw-scopes: operator.readx-openclaw-scopes: operator.read,operator.writex-openclaw-scopes: operator.admin,operator.write
- عند وجود الرأس، يحترم OpenClaw مجموعة النطاقات المعلنة.
- عند وجود الرأس لكنه فارغ، يعلن الطلب عدم وجود نطاقات مشغل.
- عند غياب الرأس، تعود واجهات HTTP الحاملة للهوية العادية إلى مجموعة نطاقات المشغل الافتراضية القياسية.
- تكون مسارات HTTP الخاصة بالـ Plugin لمصادقة Gateway أضيق افتراضيًا: عند غياب
x-openclaw-scopes، يعود نطاق وقت التشغيل الخاص بها إلىoperator.write. - ما زال يجب على طلبات HTTP ذات أصل المتصفح اجتياز
gateway.controlUi.allowedOrigins(أو وضع الرجوع المتعمد لرأس Host) حتى بعد نجاح مصادقة الوكيل الموثوق.
x-openclaw-scopes صراحة عندما تريد أن يكون طلب الوكيل الموثوق أضيق من الافتراضيات، أو عندما يحتاج مسار Plugin لمصادقة Gateway إلى ما هو أقوى من نطاق الكتابة.
قائمة التحقق الأمنية
قبل تمكين مصادقة trusted-proxy، تحقّق مما يلي:- الوكيل هو المسار الوحيد: منفذ Gateway محمي بجدار ناري من كل شيء باستثناء وكيلك.
- trustedProxies في حدّه الأدنى: عناوين IP الفعلية لوكيلك فقط، وليس شبكات فرعية كاملة.
- مصدر وكيل loopback مقصود: تفشل مصادقة trusted-proxy على نحو مغلق لطلبات مصدر loopback ما لم يتم تمكين
gateway.auth.trustedProxy.allowLoopbackصراحة لوكيل على المضيف نفسه. - الوكيل يزيل الرؤوس: يكتب وكيلك فوق رؤوس
x-forwarded-*الواردة من العملاء، ولا يضيف إليها. - إنهاء TLS: يتعامل وكيلك مع TLS؛ ويتصل المستخدمون عبر HTTPS.
- allowedOrigins صريح: تستخدم واجهة التحكم غير العاملة عبر loopback قيمة صريحة لـ
gateway.controlUi.allowedOrigins. - allowUsers مضبوط (موصى به): قيّد الوصول بالمستخدمين المعروفين بدلا من السماح لأي شخص تمت مصادقته.
- لا توجد تهيئة رموز مختلطة: لا تضبط كلا من
gateway.auth.tokenوgateway.auth.mode: "trusted-proxy". - بديل كلمة المرور المحلية خاص: إذا قمت بتهيئة
gateway.auth.passwordللمتصلين الداخليين المباشرين، فأبق منفذ Gateway محميا بجدار ناري حتى لا يتمكن العملاء البعيدون غير المارين عبر الوكيل من الوصول إليه مباشرة.
تدقيق الأمان
سيضعopenclaw security audit علامة على مصادقة trusted-proxy بنتيجة ذات شدة حرجة. هذا مقصود؛ إنه تذكير بأنك تفوض الأمان إلى إعداد الوكيل لديك.
يتحقق التدقيق من:
- تذكير التحذير/الحرج الأساسي
gateway.trusted_proxy_auth - غياب تهيئة
trustedProxies - غياب تهيئة
userHeader - قيمة
allowUsersفارغة (تسمح لأي مستخدم تمت مصادقته) - تمكين
allowLoopbackلمصادر الوكيل على المضيف نفسه - سياسة أصل المتصفح مفقودة أو تحتوي على أحرف بدل على أسطح واجهة التحكم المكشوفة
استكشاف الأخطاء وإصلاحها
trusted_proxy_untrusted_source
trusted_proxy_untrusted_source
لم يأت الطلب من عنوان IP موجود في
gateway.trustedProxies. تحقّق من:- هل عنوان IP الخاص بالوكيل صحيح؟ (يمكن أن تتغير عناوين IP لحاويات Docker.)
- هل يوجد موزّع حمل أمام وكيلك؟
- استخدم
docker inspectأوkubectl get pods -o wideللعثور على عناوين IP الفعلية.
trusted_proxy_loopback_source
trusted_proxy_loopback_source
رفض OpenClaw طلب trusted-proxy من مصدر loopback.تحقّق من:
- هل يتصل الوكيل من
127.0.0.1/::1؟ - هل تحاول استخدام مصادقة trusted-proxy مع وكيل عكسي loopback على المضيف نفسه؟
- فضّل مصادقة الرمز/كلمة المرور للعملاء الداخليين على المضيف نفسه الذين لا يمرون عبر الوكيل، أو
- وجّه عبر عنوان وكيل موثوق غير loopback وأبق ذلك العنوان في
gateway.trustedProxies، أو - لوكيل عكسي مقصود على المضيف نفسه، اضبط
gateway.auth.trustedProxy.allowLoopback = true، وأبق عنوان loopback فيgateway.trustedProxies، وتأكد من أن الوكيل يزيل رؤوس الهوية أو يكتب فوقها.
trusted_proxy_user_missing
trusted_proxy_user_missing
كان رأس المستخدم فارغا أو مفقودا. تحقّق من:
- هل تم تهيئة وكيلك لتمرير رؤوس الهوية؟
- هل اسم الرأس صحيح؟ (غير حساس لحالة الأحرف، لكن الإملاء مهم)
- هل تمت مصادقة المستخدم فعلا لدى الوكيل؟
trusted_proxy_missing_header_*
trusted_proxy_missing_header_*
لم يكن أحد الرؤوس المطلوبة موجودا. تحقّق من:
- تهيئة وكيلك لتلك الرؤوس المحددة.
- ما إذا كانت الرؤوس تُزال في مكان ما ضمن السلسلة.
trusted_proxy_user_not_allowed
trusted_proxy_user_not_allowed
تمت مصادقة المستخدم لكنه غير موجود في
allowUsers. إما أن تضيفه أو تزيل قائمة السماح.trusted_proxy_origin_not_allowed
trusted_proxy_origin_not_allowed
نجحت مصادقة trusted-proxy، لكن رأس
Origin الخاص بالمتصفح لم يجتز فحوصات أصل واجهة التحكم.تحقّق من:- يتضمن
gateway.controlUi.allowedOriginsأصل المتصفح الدقيق. - أنك لا تعتمد على أصول أحرف البدل إلا إذا كنت تريد عمدا سلوك السماح للجميع.
- إذا كنت تستخدم عمدا وضع الرجوع إلى رأس Host، فتأكد من ضبط
gateway.controlUi.dangerouslyAllowHostHeaderOriginFallback=trueعن قصد.
WebSocket still failing
WebSocket still failing
تأكد من أن وكيلك:
- يدعم ترقيات WebSocket (
Upgrade: websocket،Connection: upgrade). - يمرر رؤوس الهوية في طلبات ترقية WebSocket (وليس HTTP فقط).
- لا يملك مسار مصادقة منفصلا لاتصالات WebSocket.
الترحيل من مصادقة الرمز
إذا كنت تنتقل من مصادقة الرمز إلى trusted-proxy:ذو صلة
- التهيئة — مرجع التهيئة
- الوصول البعيد — أنماط أخرى للوصول البعيد
- الأمان — دليل الأمان الكامل
- Tailscale — بديل أبسط للوصول المحصور في tailnet