> ## Documentation Index
> Fetch the complete documentation index at: https://help.teable.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Nginx (الوكيل العكسي)

> إعداد الوكيل العكسي Nginx الموصى به لـ Teable: ‏HTTPS (الشهادات)، وWebSocket، ونصائح Docker، وNginx Proxy Manager.

إذا أردت الوصول إلى Teable عبر اسم نطاق، أو تمكين HTTPS (إنهاء اتصال SSL)، أو إبقاء Teable في شبكة خاصة خلف بوابة واحدة، فمن الشائع وضع Nginx أمام Teable.

<Callout type="info">
  النقاط الأساسية:

  * يجب أن يطابق `PUBLIC_ORIGIN` عنوان URL العام النهائي الذي يستخدمه مستخدموك (مثل `https://teable.example.com`، دون `/` لاحقة)
  * نوصي بشدة باعتماد **HTTPS + الشهادات** إعدادًا افتراضيًا (لا تشغّل حركة بيانات الإنتاج عبر HTTP غير مشفّر)
  * إذا كنت تعتمد على ميزات WebSocket، فيجب أن يمرر الوكيل العكسي ترويسات `Upgrade/Connection`
</Callout>

<Tip>
  يُستخدم Teable عادةً في تدفقات عمل **تعاونية وفورية**، ولذلك يكون إبقاء دعم WebSocket مفعّلًا الإعداد الأكثر موثوقية غالبًا. وحتى إذا كان الاستخدام فرديًا في معظمه، فلن يؤثر إبقاء هذه الإعدادات المرتبطة بـ WebSocket في الوصول العادي.
</Tip>

## الموصى به: HTTPS (الافتراضي / الإنتاج)

اعتمد HTTPS إعدادًا افتراضيًا: **قدّم الخدمة للمستخدمين النهائيين عبر المنفذ 443**، وأبقِ المنفذ 80 لإعادة التوجيه إلى 443 فقط (أو لاختبارات ACME HTTP-01).

فيما يلي مثال مناسب لبيئة الإنتاج (HTTPS + WebSocket + إعادة توجيه HTTP إلى HTTPS). استبدل النطاق ومسارات الشهادات:

```nginx theme={null}
upstream teable {
  server 127.0.0.1:3000;
  # إذا كان Nginx يعمل في شبكة Docker نفسها التي يعمل فيها Teable:
  # server teable:3000;
}

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

# لا يُستخدم المنفذ 80 إلا لإعادة التوجيه (أو لاختبارات ACME)
server {
  listen 80;
  server_name teable.example.com;
  return 301 https://$host$request_uri;
}

server {
  listen 443 ssl http2;
  server_name teable.example.com;

  ssl_certificate     /etc/letsencrypt/live/teable.example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/teable.example.com/privkey.pem;

  # إذا كنت متأكدًا من ضرورة استخدام النطاق لـ HTTPS دائمًا، فيمكنك تمكين HSTS (استخدمه بحذر)
  # add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

  location / {
    proxy_pass http://teable;

    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 https;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;
    proxy_set_header Host $host;

    proxy_http_version 1.1;
  }
}
```

### الشهادات (الإصدار / التجديد)

* **Let’s Encrypt (موصى به)**: استخدم Certbot أو acme.sh للإصدار والتجديد التلقائيين
* **الأدوات ذات الواجهة الرسومية**: يستطيع Nginx Proxy Manager طلب الشهادات وتجديدها تلقائيًا من واجهته

## المثال 1: الحد الأدنى لإعداد `location /` (بدء سريع)

> ملاحظة: هذا مثال يعمل عبر **HTTP فقط** للشبكات الداخلية أو التحقق السريع. في بيئة الإنتاج، استخدم تهيئة HTTPS أعلاه.

```nginx theme={null}
upstream teable {
  server 127.0.0.1:3000;
  # إذا كان Nginx يعمل في شبكة Docker نفسها التي يعمل فيها Teable:
  # server teable:3000;
}

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

server {
  listen 80;
  server_name teable.example.com;

  location / {
    proxy_pass http://teable;

    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_set_header Host $host;

    proxy_http_version 1.1;
  }
}
```

## نصائح Docker

* **تشغيل Nginx على المضيف وتشغيل Teable في حاويات**: استخدم عادةً `proxy_pass http://127.0.0.1:3000;` (بافتراض نشر الربط `3000:3000`)
* **تشغيل Nginx وTeable في شبكة Docker نفسها**: يمكنك التوجيه باستخدام اسم الخدمة أو الحاوية، مثل `proxy_pass http://teable:3000;`

## أخطاء شائعة

* **تجنب إعادة كتابة المسارات**: قد تؤدي إعادة الكتابة إلى تعطيل التوجيه الداخلي في Teable ما لم تكن تعرف تمامًا ما تفعله.
* **تأكد من صحة `PUBLIC_ORIGIN`**: فهو يؤثر في عناوين URL المولّدة، وعمليات إعادة التوجيه، وتدفقات الاستيراد والرفع، ومعاودة الاتصال، وغير ذلك.

## Nginx Proxy Manager ‏(NPM)

إذا لم ترغب في كتابة تهيئة Nginx يدويًا، فيمكن للأدوات ذات الواجهة الرسومية مساعدتك على إدارة النطاقات والشهادات ومضيفي الوكيل:

* **Nginx Proxy Manager ‏(NPM)**: شائع في الإعدادات المستندة إلى Docker

يكون الإعداد المعتاد في **Nginx Proxy Manager** كما يلي:

* **إنشاء مضيف وكيل**: اضبط `أسماء النطاقات` على `teable.example.com`، و`المخطط` على `http`، و`اسم المضيف / عنوان IP لإعادة التوجيه` على `127.0.0.1` (أو `teable` داخل شبكة Docker)، و`منفذ إعادة التوجيه` على `3000`
* **تمكين دعم WebSocket**: فعّل دعم WebSocket في خيارات مضيف الوكيل (يختلف اسم الخيار حسب الإصدار)
* **توفير/إرفاق SSL**: اطلب شهادة Let's Encrypt أو اخترها، وفعّل إعادة التوجيه الإجباري إلى HTTPS اختياريًا
* **لا تنسَ بيئة Teable**: اضبط `PUBLIC_ORIGIN` على عنوان URL العام النهائي (مثل `https://teable.example.com`)