connect Podًا بعيدًا عبر HTTPS، يحتاج
comfyui-mcp إلى مسار wss:// صالح لـ TLS من لوحة المتصفح على الـ Pod عائدًا
إلى جسر الوكيل على جهازك (فـ ws:// العادي من صفحة https:// يحجبه المتصفح).
والافتراضي هو نفق cloudflared سريع — بلا إعداد، لكنه عابر (اسم مضيف عشوائي
جديد في كل تشغيل).
للمؤسسات التي تحتاج إلى امتلاك ذلك المسار من طرف إلى طرف — فلا يمرّ قناة
التحكم عبر طرف ثالث، أو نطاق ثابت لقواعد الجدار الناري/التدقيق، أو بلا اعتماد
على خدمة خارج بنيتك — يدعم comfyui-mcp توجيه الجسر الآمن عبر مُرحِّل تشغّله
أنت، بدل النفق السريع الافتراضي.
التنفيذ المرجعي مفتوح المصدر:
artokun/comfyui-mcp-relay —
عامل Cloudflare + Durable Object، برخصة MIT، وموسوم كقالب GitHub حتى تضغط
Use this template وتملك نسختك في ثوانٍ. انسخه، أو انشره كما هو، أو كيّفه
على أي بنية قادرة على WebSocket تشغّلها مؤسستك أصلًا — ويوثّق README بروتوكول
السلك ودورة حياة الجلسة ومفاضلات التصميم (التعدّد والمصادقة والإسبات) بالكامل.
لماذا الاستضافة الذاتية
- إقامة البيانات / الامتثال — يحمل الجسر استدعاءات الأدوات وعمليات المخطط (لا بايتات الصور، التي تتدفّق مباشرة بين الـ Pod والمتصفح)، لكن بعض المؤسسات ما تزال تحتاج إلى أن تبقى قناة التحكم تلك داخل بنية تشغّلها هي.
- بلا اعتماد تشغيلي على طرف ثالث — نقطة نهاية ثابتة مملوكة بدل الاعتماد على توفّر مُرحِّل خارجي.
- قواعد الجدار الناري / التدقيق — نطاق ثابت تتحكّم فيه أسهل في الإذن والتسجيل من اسم مضيف عابر يتغيّر في كل جلسة.
كيف تتلاءم القطع
كلا طرفي الجسر يتّصلان إلى الخارج — فلا حاجة إلى منفذ وارد مفتوح في أي مكان. ومهمّة مُرحِّلك هي أن يقرن منسّقًا واحدًا (يعمل على جهاز المستخدم) باتصالات لوحة المتصفح على الـ Pod الذي يقوده، وينقل البايتات بينهما؛ ولا يحتاج أبدًا إلى فهم بروتوكول استدعاء الأدوات الخاص بـ comfyui-mcp الذي يركب فوق ذلك. بعد نشر مُرحِّل، يكفي توجيه comfyui-mcp إليه بعدّة متغيّرات بيئة:COMFYUI_MCP_TUNNEL_BACKEND غير مضبوط، يواصل comfyui-mcp استخدام
سلوك النفق السريع العابر الافتراضي — وهذا اختياري بالكامل.