Архитектура Nginx

Схема Nginx для клиентского сайта, панели, API, файлов и канала реального времени

Nginx является единой публичной точкой входа iEXExchanger. Он завершает HTTPS, выбирает сайт по имени домена, отдаёт статические файлы и передаёт динамические запросы нужному внутреннему процессу.

Базовые роли веб-сервера, reverse proxy и FastCGI объяснены в статье «Что такое Nginx».

Карта трафика

Входящий запрос	Назначение
ваш_домен/	SSR-процесс клиентского сайта
Подтверждённые пути API на ваш_домен	Серверная часть iEXExchanger
Подтверждённые пути файлов	Разрешённые каталоги статических файлов
Подтверждённый путь реального времени	Внутренний процесс Reverb с WebSocket
app.ваш_домен	Публичный каталог PHP-приложения через FastCGI

Пути API, файлов и канала реального времени берите из текущей поставки и активной конфигурации. Не создавайте широкое правило вида «всё с /api» без сверки: оно может перехватить клиентский маршрут или отправить приватный адрес не тому приложению.

Граница публичного доступа

Nginx слушает публичные 80 и 443. SSR, PostgreSQL, Redis и Reverb слушают только loopback или защищённую приватную сеть. Их внутренние порты обозначаются как <SSR_PORT> и <REALTIME_PORT> и не открываются в сетевом экране.

Cloudflare, если он включён, подключается к Nginx по HTTPS. Nginx не должен перенаправлять публичный запрос обратно через Cloudflare к тому же серверу без явной необходимости: такая петля усложняет диагностику и правила доступа.

Владение конфигурацией

На чистой установке виртуальные хосты создаёт установщик iEXExchanger. Перед изменением определите активный файл и проверьте, не будет ли он заменён при обслуживании или обновлении. На существующем сервере с FASTPANEL отдельно выясните, какие файлы генерирует панель и какой include предназначен для пользовательских вставок.

Активную конфигурацию показывают команды:

sudo nginx -t
sudo nginx -T

nginx -t проверяет синтаксис и возможность открыть используемые файлы. nginx -T дополнительно выводит всю конфигурацию; не публикуйте его вывод без очистки доменов, путей и заголовков. Назначение ключей описано в официальном справочнике Nginx.

Основные требования

Для каждого публичного домена должен существовать один однозначный HTTPS-vhost. В нём проверяются:

• server_name без чужих доменов;
• сертификат для этого имени;
• корректный корневой или proxy backend;
• ограничение размера запроса по требованиям загрузок;
• заголовки исходного протокола и адреса;
• WebSocket Upgrade для канала реального времени;
• отдельные журналы доступа и ошибок;
• отсутствие выдачи скрытых файлов и файла окружения.

Размер запроса согласуйте с лимитом загрузок в PHP и в настройках приложения. Увеличение только client_max_body_size не исправит меньший лимит PHP или проверку самой формы.

Порядок изменения маршрута

1. Определите URL и ожидаемый компонент.
2. Найдите активный vhost через nginx -T.
3. Выберите поддерживаемый текущей схемой файл или пользовательский include, который не перезаписывается.
4. Скопируйте изменяемый файл в резервную копию с датой.
5. Внесите минимальное правило.
6. Выполните sudo nginx -t.
7. Выполните sudo systemctl reload nginx.
8. Проверьте точный URL и соседние маршруты.
9. При ошибке верните файл, снова выполните тест и reload.

Reload применяет новую конфигурацию без принудительного обрыва обслуживаемых соединений; модель перечитывания конфигурации описана в руководстве Nginx.