Nginx أم Caddy أم Traefik: أي وكيل تختار؟

Nginx مقابل Caddy مقابل Traefik: الإجابة المختصرة

تؤدي Nginx وCaddy وTraefik الوظيفة نفسها كـ reverse proxy: تستمع على المنفذ 443، وتقرأ اسم المضيف في كل طلب، ثم تمرّره إلى الخدمة الصحيحة على VPS الخاص بك. يمكن لأي واحد منها وضع أربعة تطبيقات ذاتية الاستضافة خلف عنوان IP عام واحد، وجميعها سريعة بما يكفي بحيث تكون تطبيقاتك هي الجزء الأبطأ. يكمن الاختلاف في طريقة حصول كل منها على شهادة TLS (أمان طبقة النقل)، ومقدار الإعداد الذي يتطلبه كل تطبيق إضافي. ويظهر الاختلاف الآخر لاحقاً، في اليوم الذي تحتاج فيه إلى شيء لا تشرحه البرامج التعليمية الشائعة.

اختر Caddy إذا أردت أن يتولى HTTPS عنك وكانت خدماتك تطبيقات ويب عادية. اختر Traefik إذا كان كل شيء يعمل ضمن Docker Compose وتضيف خدمة جديدة كل بضعة أسابيع. اختر Nginx إذا كنت تستخدمه بالفعل، أو إذا كنت تحتاج إلى تخزين الاستجابات مؤقتاً، أو شهادات العميل، أو إعادة توجيه TCP الخام، أو إعداد كبيراً قائماً لا تريد إعادة كتابته.

كيف يحصل كل واحد منها على شهادة TLS؟

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

يطلب Caddy الشهادة لأنك حدّدت اسم مضيف. اكتب app.example.com كعنوان موقع، وسيطلب Caddy شهادة عبر ACME (بيئة إدارة الشهادات التلقائية) من Let's Encrypt، ثم ينتقل إلى ZeroSSL إذا فشل ذلك، ويقدّم إعادة التوجيه من HTTP إلى HTTPS على المنفذ 80، ويجدد الشهادة تلقائياً. لا تحتاج إلى أداة ثانية أو مؤقت للتحقق من التجديد. تُخزَّن الشهادات في دليل بيانات المستخدم caddy، وهو /var/lib/caddy/.local/share/caddy عند التثبيت من حزمة. لذلك أضف هذا المسار إلى النسخ الاحتياطية، أو اقبل إصدار شهادة جديدة بعد إعادة بناء الخادم. إذا كان اسم المضيف غير عام، يوقّع tls internal الشهادة باستخدام سلطة الشهادات المحلية الخاصة بـCaddy. وهذا يوفّر النتيجة نفسها التي تحصل عليها عند إنشاء شهادة موقعة ذاتياً على Ubuntu، مع تولي Caddy عملية التجديد.

لا يحتوي Nginx على عميل ACME. يحصل Certbot على الشهادة، ثم يعيد المكوّن الإضافي --nginx كتابة كتلة الخادم لإضافة المستمع على المنفذ 443 وإعادة التوجيه. يعمل التجديد من خلال مؤقت systemd تثبته الحزمة، لذلك توجد خطوتان متحركتان وشيئان يجب التحقق منهما: يبيّن systemctl list-timers | grep certbot وجود المؤقت، ويثبت sudo certbot renew --dry-run أن مسار التجديد ما زال يعمل. تجد الخطوات التفصيلية في Certbot على Ubuntu 24.04 مع Nginx، وتدعم الأداة نفسها شهادة wildcard عبر تحدي DNS-01 عندما يكون لديك نطاقات فرعية أكثر مما تريد إدراجه.

يحتوي Traefik على عميل ACME خاص به. اضبط محلل شهادات واحداً في الإعدادات الثابتة، وبعد ذلك يمكن لكل جهاز توجيه استخدامه. تُخزَّن كل الحالة، بما في ذلك مفتاح الحساب والشهادات، في ملف acme.json واحد. يرفض Traefik استخدام هذا الملف إذا كان قابلاً للقراءة من أي مستخدم غير مالكه، ويبلغك بذلك قبل إسقاط محلل الشهادات:

The ACME resolver "le" is skipped from the resolvers list because: unable to get ACME account: permissions 660 for /letsencrypt/acme.json are too open, please use 600

اربط دليلاً واترك Traefik ينشئ الملف بنفسه. أنشئ الدليل أولاً باستخدام touch، وسيَرث قناع الصلاحيات umask الخاص بك. هكذا يواجه معظم الناس ذلك السطر.

هناك أمر واحد ينطبق على الأدوات الثلاث كلها. يحتاج تحدي HTTP-01 إلى أن يكون المنفذ 80 قابلاً للوصول من الإنترنت، لأن جهة إصدار الشهادة تتصل به من الخارج. إذا فتحت المنفذ 443 فقط، فسيفشل الإصدار بطريقة تبدو كأنها مشكلة DNS.

مهمة توجيه التطبيقين نفسيهما في 3 إعدادات

المهمة: يوجّه app.example.com إلى خدمة على 127.0.0.1:8080، ويوجّه files.example.com إلى خدمة على 127.0.0.1:8081، وكلاهما عبر HTTPS. فيما يلي الإعداد الكامل لكل Proxy، حتى يظهر الفرق في مقدار التفصيل بدلاً من الاكتفاء بوصفه.

Nginx

# /etc/nginx/sites-available/app.example.com
server {
    listen 80;
    server_name app.example.com;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

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

sudo ln -s /etc/nginx/sites-available/app.example.com /etc/nginx/sites-enabled/
sudo nginx -t
sudo systemctl reload nginx
sudo certbot --nginx -d app.example.com

إن طباعة syntax is ok وtest is successful عبر nginx -t هي الفحص الذي يجب تشغيله قبل كل إعادة تحميل. التطبيق الثاني هو الكتلة نفسها، مع تغيير اسم المضيف والمنفذ. أسطر proxy_set_header ليست زائدة: عندما يحدّد proxy_pass عنواناً، يرسل nginx Host: 127.0.0.1:8080 إلى الخدمة الخلفية افتراضياً. لذلك، سيرسل التطبيق الذي ينشئ عناوين URL مطلقة من ترويسة Host المستخدمين إلى localhost. يوضّح هذا الشرح التفصيلي لكتلة خادم nginx وظيفة كل ترويسة من هذه الترويسات الأربع، وسبب تغيير الشرطة المائلة اللاحقة في proxy_pass للمسار الذي يستلمه التطبيق دون ظهور خطأ واضح، وذلك توجيهاً بتوجيه.

Caddy

app.example.com {
	reverse_proxy 127.0.0.1:8080
}

files.example.com {
	reverse_proxy 127.0.0.1:8081
}

sudo caddy validate --config /etc/caddy/Caddyfile
sudo systemctl reload caddy

هذا هو الملف كاملاً. يضبط reverse_proxy وX-Forwarded-For وX-Forwarded-Proto وX-Forwarded-Host بنفسه، ويتجاهل افتراضياً ما أرسله العميل في هذه الترويسات. لذلك، لا يستطيع الطلب خداع خدمتك الخلفية بشأن مصدره. تأتي الشهادات وإعادة التوجيه من المنفذ 80 والتجديد كلها من عنواني الموقع. ولا يطلبها أي شيء آخر في الملف.

Traefik

يحتاج Traefik إلى إعداد ثابت قبل أن يوجّه أي طلب. وبصفته خدمة Compose، باستخدام وسم الصورة الحالي حتى August 2026:

services:
  traefik:
    image: traefik:v3.7
    command:
      - "--providers.docker=true"
      - "--providers.docker.exposedbydefault=false"
      - "--entrypoints.web.address=:80"
      - "--entrypoints.websecure.address=:443"
      - "--certificatesresolvers.le.acme.email=you@example.com"
      - "--certificatesresolvers.le.acme.storage=/letsencrypt/acme.json"
      - "--certificatesresolvers.le.acme.httpchallenge.entrypoint=web"
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
      - ./letsencrypt:/letsencrypt

بعد ذلك، يضمّن كل تطبيق إعداد التوجيه الخاص به في labels، داخل ملف Compose الخاص به:

    labels:
      - "traefik.enable=true"
      - "traefik.http.routers.app.rule=Host(`app.example.com`)"
      - "traefik.http.routers.app.entrypoints=websecure"
      - "traefik.http.routers.app.tls.certresolver=le"
      - "traefik.http.services.app.loadbalancer.server.port=8080"

يشير loadbalancer.server.port إلى المنفذ داخل الحاوية، وليس إلى منفذ منشور، لأن Traefik يصل إلى الحاوية عبر شبكة Docker مشتركة. ولا يحتاج التطبيق إلى سطر ports: إطلاقاً. وهذه هي الفائدة الفعلية: لا يُنشر سوى Traefik. يرد الإعداد الكامل، بما في ذلك الشبكة المشتركة وmiddleware إعادة التوجيه، في توجيه عدة تطبيقات باستخدام Traefik وDocker Compose.

ما مقدار الإعدادات التي يتطلبها كل تطبيق إضافي؟

[
  {
    "tool": "Nginx",
    "proxy_setup_lines": 0,
    "lines_per_app": 11
  },
  {
    "tool": "Caddy",
    "proxy_setup_lines": 0,
    "lines_per_app": 3
  },
  {
    "tool": "Traefik",
    "proxy_setup_lines": 17,
    "lines_per_app": 5
  }
]

استناداً إلى الكتل الواردة أعلاه، يبلغ عدد الأسطر غير الفارغة في كتلة خادم Nginx 11، وتكتبها مجدداً لكل اسم مضيف. أما كتلة الموقع في Caddy فتتكون من 3 أسطر. ويتطلب Traefik 17 أسطر من الإعدادات الثابتة قبل أن يعالج طلباً واحداً، ثم 5 من labels لكل تطبيق.

اقرأ المفاضلة، ولا تبحث عن فائز فقط. يكلّف Traefik أكبر قدر من الإعدادات قبل إضافة التطبيق الأول، وأقل قدر لكل تطبيق بعد ذلك، ويتساوى الإجماليان تقريباً عند الموقع الثالث. قبل ذلك، تكون الإعدادات الثابتة عبئاً لم تكن تحتاج إليه. بعد ذلك، تتفوق labels وتستمر في التقدم، لأن إعداد التوجيه يوجد بجانب الخدمة التي يوجّه إليها. احذف الخدمة، فيُحذف route الخاص بها معها. وهذه نقطة لا تتعامل معها ملفات الإعداد المركزية جيداً: بقاء كتل خوادم قديمة لتطبيقات توقفت عن الوجود منذ أشهر.

كما أن عدّ الأسطر يعطي Nginx أفضلية ظاهرية. تحتاج كل كتلة من هذه الكتل إلى symlink، وإلى nginx -t، وإلى reload، وإلى تشغيل certbot، بينما يتطلب تعديل Caddy عملية reload واحدة، ولا يتطلب تعديل Traefik أي أمر على الإطلاق. تعيد الأدوات الثلاث تحميل الإعدادات من دون قطع الاتصالات النشطة. والفرق هو عدد الخطوات المنفصلة التي عليك تذكرها في الساعة الواحدة صباحاً.

ما الأداة التي تتعرّف على حاوياتك؟

يراقب Traefik مقبس Docker، وينشئ أجهزة التوجيه من التسميات الموجودة على الحاويات عند بدء الحاويات وتوقفها. لا توجد أداة أخرى هنا تفعل ذلك. يحتاج كل من Nginx وCaddy إلى تعديل إعداد وإعادة تحميل عند ظهور حاوية جديدة، كما يحتاجان إلى عنوان يمكنهما الوصول إليه: إما منفذ منشور على loopback، أو شبكة Docker مشتركة متصل بها الـproxy.

لهذه الميزة تكلفة، ومن المهم توضيحها. يقرأ Traefik /var/run/docker.sock. يمكن لأي طرف يستطيع الاتصال بهذا المقبس تشغيل حاوية مع تثبيت نظام ملفات المضيف داخلها، ما يمنحه root على المضيف. يقلل تثبيت المقبس بوضع القراءة فقط من الخطر، لكنه لا يزيله. إذا كان ذلك مهماً وفق نموذج التهديد لديك، فضع socket proxy بينهما، بحيث يتيح فقط نقاط النهاية الخاصة بقائمة الحاويات التي يحتاج إليها Traefik.

يمكن لـCaddy تنفيذ الاكتشاف المستند إلى التسميات عبر plugin من المجتمع، لكن plugins في Caddy تُضمَّن وقت التجميع. لذلك عليك إنشاء ملف ثنائي مخصص أو image مخصصة تتضمن xcaddy، ثم تصبح مسؤولاً عن هذا الإصدار وتحديثاته. بالنسبة إلى ثلاث أو أربع خدمات، يكون تعديل Caddyfile أقل جهداً.

WebSockets والبث: ما الذي يتعطل، ولماذا

يحتاج Nginx إلى إعداد إضافي. يبدأ اتصال WebSocket كطلب HTTP يحمل Upgrade: websocket، ولا يمرّر nginx الرؤوس hop-by-hop إلى الخادم الخلفي إلا إذا طلبت منه ذلك.

# /etc/nginx/conf.d/upgrade-map.conf
map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

بعد ذلك، يجب أن تكون الأسطر الثلاثة التالية موجودة كلها داخل كتلة location:

        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;

إذا حذفتها، تعرض وحدة تحكم المتصفح WebSocket connection to 'wss://app.example.com/ws' failed، بينما يسجل الخادم الخلفي طلب GET عادياً. يوجد map لأن إرسال Connection: upgrade ثابت في كل طلب سيشمل أيضاً الطلبات العادية التي يجب أن تقول close.

هناك إعدادان افتراضيان آخران في Nginx يسببان مشكلات. قيمة proxy_read_timeout هي 60 ثانية، وهي تنطبق على النفق بعد الترقية. لذلك يغلق الـproxy اتصال WebSocket الذي لا يشهد حركة لمدة دقيقة. كما تصل server-sent events متأخرة أو على دفعات إلى أن تضبط proxy_buffering off; في ذلك الموقع، لأن nginx يحتفظ بالاستجابة في ذاكرته المؤقتة بينما تنتظرها صفحتك.

ينفّذ Caddy الترقية ويحوّل الاتصال إلى نفق ثنائي الاتجاه دون أي توجيهات. كما يرسل البيانات فوراً عندما تكون الاستجابة text/event-stream أو لا يكون طولها معروفاً، لذلك يعمل البث دون تعديل. يمرّر Traefik عمليات الترقية ولا يخزّن الاستجابات مؤقتاً، ما لم تضف middleware ‏buffering بنفسك. إذا كانت خدماتك تتضمن الدردشة، أو طرفية ويب، أو عرضاً مستمراً للسجلات، أو لوحات معلومات مباشرة، فسيؤثر ذلك فعلياً في مقدار الإعداد الذي ستكتبه وتصحيحك له.

map $http_upgrade $connection_upgrade {
    default upgrade;
    ''      close;
}

server {
    listen 80;
    server_name app.example.com;
    client_max_body_size 64m;

    location / {
        proxy_pass http://127.0.0.1:8080;
        proxy_http_version 1.1;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection $connection_upgrade;
        proxy_read_timeout 3600s;
        proxy_buffering off;
    }
}

ماذا يحدث عندما تحتاج إلى شيء غير اعتيادي؟

هنا يثبت Nginx قيمة أسطر الإعداد الإضافية.

• شهادات العميل، وتُسمى أيضاً mTLS (‏TLS متبادل)، حيث يجب على العميل تقديم شهادة أيضاً. يتطلب Nginx وجود ssl_client_certificate /etc/ssl/ca.pem; وssl_verify_client on; داخل كتلة الخادم. أما Caddy فيتطلب كتلة client_auth داخل tls. ولا يمكن لملصقات Traefik التعبير عن ذلك إطلاقاً؛ إذ تعرّف خيار TLS في موفّر ملفات، ثم تشير إليه من جهاز التوجيه باستخدام traefik.http.routers.app.tls.options=mtls@file. ويُستثنى نموذج وضع كل شيء في الملصقات عند احتياجك إلى ذلك للمرة الأولى.
• التحميلات الكبيرة. يحد Nginx أحجام أجسام الطلبات إلى 1 MB افتراضياً. يعيد التحميل الأكبر 413 Request Entity Too Large، ويذكر سجل الأخطاء client intended to send too large body. ارفع القيمة عبر client_max_body_size. لا يفرض Caddy وTraefik أي حد افتراضي لحجم الجسم، لذلك يصل الطلب إلى تطبيقك، ويحدد حد التطبيق نفسه النتيجة.
• التخزين المؤقت للاستجابات. يوفّر Nginx proxy_cache، وهو ناضج ومستقر. يحتاج Caddy إلى إضافة مضمّنة في عملية البناء. ولا يتضمن الإصدار مفتوح المصدر من Traefik أي ذاكرة تخزين مؤقت HTTP على الإطلاق، وهذا يفاجئ من يفترضون أن كل وكيل يعالج التخزين المؤقت.
• TCP أو UDP خام، لمنفذ قاعدة بيانات أو خادم ألعاب. يوفّر Nginx وحدة stream. ويحتوي Traefik على أجهزة توجيه TCP وUDP ضمن نقاط دخول مستقلة. أما Caddy فيحتاج إلى إضافة أخرى، أي إلى بناء مخصص آخر.
• خادم ويب موجود خلف الوكيل مسبقاً. إذا كانت الخدمة تطبيق PHP تقليدياً، فإن حزمة LAMP على Ubuntu 24.04 تتضمن Apache مسبقاً. ويؤدي وضع وكيل أمامها إلى وجود موضعين يضبطان الرؤوس وموضعين يمكنهما إعادة كتابة عنوان URL. حدّد أيهما ينهي TLS، ثم أبقِ الآخر على HTTP عادي مرتبطاً بواجهة loopback.

مصيدة جدار الحماية الناتجة عن هذا الخيار

الهدف من الـreverse proxy هو فتح المنفذين 80 و443 فقط. لكن Docker يلغي ذلك بهدوء. يؤدي نشر منفذ باستخدام -p 8080:80 إلى كتابة قاعدة DNAT في جدول nat، وتُقيَّم هذه القاعدة قبل قواعد INPUT التي يديرها ufw. لذلك لا يحظرها ufw deny 8080، ويصبح تطبيقك متاحاً على الإنترنت العام إلى جانب الـproxy الذي أعددته بعناية. اربط المنافذ المنشورة بواجهة loopback باستخدام 127.0.0.1:8080:80، أو احذف ports: بالكامل ودَع الـproxy يصل إلى الحاوية عبر شبكة Docker، وهذا ما يفعله مثال Traefik أعلاه. تجد شرح الآلية والإصلاح في سبب تجاوز المنافذ المنشورة في Docker لـufw.

اختبر ذلك من جهاز ليس هو VPS، لأن الاختبار الذي تشغّله على الخادم نفسه ينجح دائماً:

curl --max-time 5 http://your.server.address:8080

النتيجة المطلوبة هي Connection refused أو انتهاء مهلة. تشير استجابة HTTP إلى أن التطبيق يمكن الوصول إليه من دون المرور عبر الـproxy، وأن كل ما أعددته أعلاه لا يؤدي أي وظيفة.

أي Reverse Proxy ينبغي أن تختار؟

مواقع ثابتة في الغالب، مع تطبيق أو تطبيقين: Caddy. يلغي HTTPS التلقائي أكبر مهمة متكررة لديك. وتبقى الإعدادات قصيرة بما يكفي لقراءتها في شاشة واحدة، كما يتطلب الموقع الثابت سطر root وسطر file_server داخل كتلة الموقع نفسها. أما المقابل، فهو توفر عدد أقل من الحلول الجاهزة للنسخ واللصق عند حدوث مشكلة غير متوقعة.

مختبر منزلي يعتمد على docker-compose وتواصل إضافة خدمات إليه: Traefik. بعد إضافة الخدمة الثالثة، تصبح labels أقل جهداً من تعديل ملف مركزي، كما أن حذف الخدمة يحذف route الخاص بها. خصص فترة بعد الظهر للإعداد الأول، لأن entrypoints وrouters وservices وmiddlewares مصطلحات جديدة عليك. يظهر الخطأ المطبعي في label عادةً على شكل 404 من Traefik بدلاً من فشل بدء التشغيل، لذلك اقرأ docker logs traefik بحثاً عن خطأ التحليل قبل افتراض أن التطبيق معطّل.

لديك إعداد Nginx قائم، أو تحتاج إلى أي ميزة من القائمة أعلاه: Nginx. فهو يوفّر حلاً جاهزاً لتخزين الاستجابات مؤقتاً ولشهادات العميل، وتفترضه أدلة الجهات الخارجية كلها تقريباً. أما المقابل، فهو أنك تضبط الشهادات ودعم websocket بنفسك بدلاً من الحصول عليهما تلقائياً.

تنطبق قاعدة واحدة مهما كان اختيارك. تستمع عملية واحدة فقط على الواجهة العامة، بينما تستمع جميع العمليات الأخرى على loopback أو على شبكة Docker خاصة.

FAQ

ما هو Reverse Proxy الأنسب لعدة تطبيقات Docker على VPS واحد؟

بالنسبة إلى ثلاث أو أربع خدمات تضيفها من وقت إلى آخر، يثبت Traefik جدواه، لأن كل تطبيق يحتوي على labels التوجيه الخاصة به ولا يحتاج إلى تعديل ملف مركزي. إذا كانت الخدمات مستقرة، وكان هدفك الأساسي هو التوقف عن إدارة HTTPS بنفسك، فإن Caddy أسهل تعلماً وأقل عرضة للأخطاء. اختر Nginx إذا كنت تعرفه مسبقاً، أو إذا كنت تحتاج إلى ميزة لا يوفرها الآخران، مثل التخزين المؤقت للاستجابات أو مستمع TCP عادي.

هل يحتاج Caddy فعلاً إلى أي إعداد للشهادة؟

في الحالة المعتادة، نعم. يكفي تحديد اسم مضيف عام كعنوان للموقع. يطلب Caddy الشهادة عبر ACME، ويقدم إعادة التوجيه من المنفذ 80، ويجدد الشهادة قبل انتهاء صلاحيتها. لكن يجب تحقق شرطين. يجب أن يكون المنفذ 80 قابلاً للوصول من الإنترنت لتحدي HTTP-01، ويجب أن يكون سجل DNS من النوع A أو AAAA لاسم المضيف موجهاً مسبقاً إلى VPS، لأن جهة إصدار الشهادة تحل الاسم وتتصل به من جديد.

هل يمكنني تشغيل Nginx وTraefik على VPS نفسه؟

ليس على المنافذ نفسها. يفشل أي منهما إذا بدأ تشغيله ثانياً لأنه لا يستطيع ربط المنفذ، ويعرض nginx الرسالة bind() to 0.0.0.0:443 failed (98: Address already in use)، بينما يسجل Traefik خطأ ربط مشابهاً ثم يتوقف. شغّل Reverse Proxy واحداً على المنفذين 80 و443، وضع كل شيء آخر خلفه. إذا كنت تنقل الخدمات، فانقل أسماء المضيفين واحداً تلو الآخر: اجعل الـproxy الأمامي يوجّه الطلبات مؤقتاً إلى الـproxy القديم عبر منفذ loopback حتى تنقل الموقع الأخير.

لماذا تنقطع اتصالات WebSocket لدي بعد 60 ثانية خلف Nginx؟

تكون proxy_read_timeout مضبوطة افتراضياً على 60 ثانية، وتنطبق على النفق بعد اكتمال الترقية. لذلك يغلق الـproxy الاتصال الذي لا يشهد حركة مرور لمدة دقيقة، وليس التطبيق. ارفع القيمة في ذلك المسار باستخدام proxy_read_timeout 3600s;، أو اجعل التطبيق يرسل إطار ping كل 30 ثانية. لا يغلق Caddy وTraefik الاتصالات الخاملة التي تمت ترقيتها بعد مؤقت مدته دقيقة واحدة، ولذلك قد يبدو التطبيق نفسه مستقراً خلفهما وغير مستقر خلف Nginx.