Nginx (обратный прокси)

Если вы хотите обращаться к Teable по доменному имени, включить HTTPS (терминацию SSL) или сохранить Teable в частной сети за единым шлюзом, распространённым решением будет разместить Nginx перед Teable.

Ключевые моменты:

PUBLIC_ORIGIN должен совпадать с окончательным публичным URL, который используют ваши пользователи (например, https://teable.example.com, без завершающего /)
Мы настоятельно рекомендуем использовать HTTPS + сертификаты по умолчанию (не передавайте рабочий трафик по обычному HTTP)
Если вы используете функции WebSocket, обратный прокси должен передавать заголовки Upgrade/Connection

Teable обычно используется в сценариях совместной работы / реального времени, поэтому включённая поддержка WebSocket — наиболее надёжная настройка. Даже при преимущественно однопользовательской работе эти настройки, связанные с WebSocket, не повлияют на обычный доступ.

Рекомендуется: HTTPS (по умолчанию / рабочая среда)

Используйте HTTPS по умолчанию: обслуживайте конечных пользователей через 443; сохраняйте порт 80 только для перенаправления на 443 (или для проверок ACME HTTP-01). Ниже приведён пример для рабочей среды (HTTPS + WebSocket + перенаправление HTTP→HTTPS). Замените домен и пути к сертификатам:

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 для автоматического выпуска и продления
Инструменты с GUI: Nginx Proxy Manager может запрашивать сертификаты и автоматически продлевать их через свой интерфейс

Пример 1: минимальный `location /` (быстрый старт)

Примечание: Это пример только с HTTP для внутренних сетей или быстрой проверки. Для рабочей среды предпочтительна приведённая выше конфигурация HTTPS.

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 вручную, инструменты с GUI помогут управлять доменами, сертификатами и прокси-хостами:

Nginx Proxy Manager (NPM): распространённый вариант в конфигурациях на основе Docker

Для Nginx Proxy Manager типичная настройка выглядит так:

Создайте Proxy Host: установите для Доменные имена значение teable.example.com, для Схема — http, для Имя хоста / IP для перенаправления — 127.0.0.1 (или teable внутри сети Docker), а для Порт перенаправления — 3000
Включите поддержку WebSocket: включите поддержку WebSocket в настройках Proxy Host (название зависит от версии)
Выпустите/подключите SSL: запросите/выберите сертификат Let’s Encrypt и при необходимости принудительно включите перенаправление HTTPS
Не забудьте о среде Teable: установите PUBLIC_ORIGIN в окончательный публичный URL (например, https://teable.example.com)

AI

Space

Automation

Base

Authority Matrix

SSO

Comparison

Nginx (обратный прокси)

Рекомендуется: HTTPS (по умолчанию / рабочая среда)

Сертификаты (выпуск / продление)

Пример 1: минимальный `location /` (быстрый старт)

Советы по Docker

Распространённые ошибки

Nginx Proxy Manager (NPM)

​Рекомендуется: HTTPS (по умолчанию / рабочая среда)

​Сертификаты (выпуск / продление)

​Пример 1: минимальный location / (быстрый старт)

​Советы по Docker

​Распространённые ошибки

​Nginx Proxy Manager (NPM)

Рекомендуется: HTTPS (по умолчанию / рабочая среда)

Сертификаты (выпуск / продление)

Пример 1: минимальный `location /` (быстрый старт)

Советы по Docker

Распространённые ошибки

Nginx Proxy Manager (NPM)