Связка Nginx и Apache решает конкретную задачу: быстрая отдача статики и стабильная обработка динамики на одном сервере. Nginx принимает все входящие соединения, мгновенно отдает файлы CSS, JS, изображения, а запросы к PHP, Python или 1С:Предприятие проксирует на Apache. Это снижает нагрузку на процессор, ускоряет ответ сайта в 2-3 раза и упрощает внедрение SSL и балансировки.
Руководство содержит готовые конфигурации для Windows Server 2022/2025 и Ubuntu Server 24.04 LTS. Каждый блок можно скопировать, адаптировать под свой проект и запустить в production. Все примеры проверены на версиях ПО 2026 года.
Зачем нужна связка Nginx + Apache: решаем реальные задачи бизнеса
Apache обрабатывает динамический контент через модули mod_php, mod_perl, mod_wsgi. Он совместим с устаревшими проектами, где используется .htaccess, и с платформой 1С:Предприятие, требующей специфических заголовков и WebSocket-соединений. Проблема Apache - высокая стоимость удержания keep-alive соединений: на каждый клиент создается отдельный процесс или поток, что при 1000 одновременных посетителей съедает гигабайты оперативной памяти.
Nginx работает по событийной модели. Один рабочий процесс обслуживает тысячи соединений, потребляя минимум ресурсов. Он мгновенно отдает статические файлы напрямую с диска, сжимает ответы gzip и держит медленных клиентов, не нагружая бэкенд.
Три сценария, когда связка оправдана:
- Интернет-магазин на PHP с каталогом из 50 000 товаров. Nginx кэширует картинки и страницы каталога, Apache генерирует корзину и личный кабинет.
- Корпоративный портал с 1С:Документооборот и внешним сайтом на Bitrix. Nginx маршрутизирует запросы: статика уходит напрямую, динамика - на Apache с настроенной публикацией баз 1С.
- Высоконагруженный SaaS-сервис. Nginx балансирует запросы между тремя серверами Apache, кэширует ответы API и держит пиковые нагрузки в 5000 RPS без увеличения парка серверов.
Схема работы проста: интернет-пользователь подключается к Nginx на портах 80 и 443. Nginx проверяет URL. Если запрошен файл с расширением .jpg, .css, .js - отдает сам. Если .php, .aspx или путь начинается с /1c/ - проксирует запрос на Apache, слушающий порт 8080 на локальном интерфейсе 127.0.0.1. Apache обрабатывает скрипт и возвращает ответ Nginx, который передает его клиенту.
Подготовка сервера: установка и базовые проверки
Перед настройкой связки оба веб-сервера должны быть установлены и запущены. Конфликт портов неизбежен: оба по умолчанию слушают порт 80. Решение - перевести Apache на порт 8080 до начала конфигурации.
Установка на Windows Server 2022/2025
Скачайте актуальные дистрибутивы Nginx (nginx.org) и Apache (Apache Lounge или ApacheHaus). Распакуйте архивы в C:\nginx и C:\Apache24. Запустите командную строку от имени администратора и выполните установку служб:
C:\nginx\nginx.exe -s stop
C:\nginx\nginx.exe -s start
C:\Apache24\bin\httpd.exe -k install
C:\Apache24\bin\httpd.exe -k startПроверьте работу через браузер: http://localhost для Nginx и http://localhost:8080 для Apache после смены порта. Если страницы не открываются, проверьте правила брандмауэра - добавьте разрешающие правила для портов 80 и 8080 через wf.msc. Особенность Windows: службы работают от имени Local System, но доступ к папкам сайтов может потребовать явного добавления прав для пользователя NETWORK SERVICE.
Установка на Ubuntu Server 24.04 LTS и CentOS Stream 10
На Ubuntu выполните:
sudo apt update
sudo apt install nginx apache2 -y
sudo systemctl enable nginx apache2
sudo systemctl start nginx apache2На CentOS Stream 10 команды аналогичны, но используется dnf:
sudo dnf install nginx httpd -y
sudo systemctl enable nginx httpd
sudo systemctl start nginx httpdСразу разрешите конфликт портов. Откройте файл /etc/apache2/ports.conf (Ubuntu) или /etc/httpd/conf/httpd.conf (CentOS), найдите директиву Listen 80 и замените на Listen 127.0.0.1:8080. Перезапустите Apache: sudo systemctl restart apache2 (или httpd). Теперь Nginx слушает порт 80, Apache - порт 8080 только на локальном интерфейсе. Это базовая настройка безопасности: Apache недоступен напрямую из интернета.
Архитектура связки: как Nginx и Apache будут работать вместе
Поток запроса выглядит так: клиент отправляет GET /catalog/product.php?id=15 на ваш сервер. Пакет попадает на Nginx, который анализирует location-блоки. Правило для \.php$ срабатывает, и Nginx формирует новый HTTP-запрос к Apache на 127.0.0.1:8080. Важно: Nginx добавляет заголовки X-Real-IP, X-Forwarded-For и X-Forwarded-Proto, чтобы Apache и приложение знали реальный IP клиента и факт использования HTTPS.
Apache принимает запрос, обрабатывает PHP-скрипт через модуль mod_php или PHP-FPM и возвращает HTML. Nginx получает ответ и отправляет его клиенту. Если ответ содержит заголовок Cache-Control, Nginx может сохранить его в кэш и при следующем таком же запросе отдать мгновенно, не обращаясь к Apache.
Для 1С схема немного сложнее. Тонкий клиент и веб-клиент используют WebSocket-соединения для постоянной связи с сервером приложений. Nginx должен корректно проксировать WebSocket через директивы proxy_http_version 1.1 и заголовки Upgrade и Connection. Без этого тонкий клиент будет падать с ошибкой «Connection reset».
Пошаговая настройка виртуальных хостов: от простого сайта до сложной конфигурации
Базовый виртуальный хост Apache для PHP-сайта
Создайте файл конфигурации виртуального хоста. На Ubuntu: /etc/apache2/sites-available/mysite.conf, на Windows: C:/Apache24/conf/extra/httpd-vhosts.conf. Пример для PHP 8.3 с PHP-FPM на Ubuntu:
<VirtualHost 127.0.0.1:8080>
ServerName mysite.ru
DocumentRoot /var/www/mysite
<Directory /var/www/mysite>
AllowOverride All
Require all granted
</Directory>
<FilesMatch \.php$>
SetHandler "proxy:unix:/run/php/php8.3-fpm.sock|fcgi://localhost"
</FilesMatch>
ErrorLog ${APACHE_LOG_DIR}/mysite_error.log
CustomLog ${APACHE_LOG_DIR}/mysite_access.log combined
</VirtualHost>На Windows путь к DocumentRoot указывается с прямыми слешами: C:/www/mysite. Обработчик PHP на Windows обычно настраивается через mod_php, а не PHP-FPM. Включите виртуальный хост командой sudo a2ensite mysite.conf на Linux или раскомментируйте Include conf/extra/httpd-vhosts.conf в httpd.conf на Windows. Перезапустите Apache.
Настройка Nginx в качестве фронтенда: проксирование и отдача статики
Создайте server block для Nginx. На Ubuntu: /etc/nginx/sites-available/mysite, на Windows: C:/nginx/conf/conf.d/mysite.conf. Базовая конфигурация:
server {
listen 80;
server_name mysite.ru www.mysite.ru;
root /var/www/mysite;
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;
}
location ~* \.(jpg|jpeg|png|gif|ico|css|js|svg|woff|woff2|ttf|eot)$ {
expires 30d;
add_header Cache-Control "public, immutable";
try_files $uri =404;
}
location ~ /\. {
deny all;
}
}Этот блок решает три задачи. Первый location / проксирует все запросы на Apache, передавая реальные заголовки. Второй location перехватывает запросы к статическим файлам и отдает их напрямую с диска с заголовком кэширования на 30 дней. Третий блок запрещает доступ к скрытым файлам вроде .htaccess. Активируйте конфигурацию: sudo ln -s /etc/nginx/sites-available/mysite /etc/nginx/sites-enabled/ на Linux или перезапустите Nginx на Windows.
Особенности для Windows: пути, права и службы
В Windows пути к файлам в конфигурациях Nginx и Apache записываются через прямой слеш: C:/www/mysite. Обратный слеш вызывает ошибки парсинга. Службы Apache и Nginx работают от имени Local System, но если сайт расположен на другом диске или в пользовательской папке, добавьте права для пользователя NETWORK SERVICE через вкладку «Безопасность» в свойствах папки. Управление службами выполняется через PowerShell:
Restart-Service nginx
Restart-Service apache2.4Для отладки на Windows используйте просмотр событий (eventvwr.msc) и логи в C:/nginx/logs/error.log и C:/Apache24/logs/error.log.
Публикация базы 1С через веб-сервер: проверенная конфигурация
Публикация базы 1С через связку Nginx+Apache требует точной настройки. Ошибки на этом этапе приводят к неработающему веб-клиенту, обрывам тонкого клиента и проблемам с лицензиями. Инструкция проверена на платформе 1С:Предприятие 8.3.25.
Автоматическая публикация из 1С и доработка конфигурации Apache
Запустите конфигуратор базы данных 1С. Перейдите в Администрирование - Публикация на веб-сервере. Выберите веб-сервер Apache 2.4, укажите каталог публикации (например, C:/www/1cbase на Windows или /var/www/1cbase на Linux) и имя публикации (например, «erp»). Снимите флажок «Публиковать тонкий клиент», если доступ нужен только через браузер. Нажмите «Опубликовать».
1С создаст файл default.vrd и конфигурацию Apache. Откройте сгенерированный файл httpd.conf для этой публикации. Добавьте обязательные модули и настройки в начало файла или в основной httpd.conf Apache:
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule headers_module modules/mod_headers.so
<Directory "C:/www/1cbase">
AllowOverride All
Options FollowSymLinks
Require all granted
AddHandler 1c-application .1c
</Directory>Модуль mod_rewrite обязателен для маршрутизации запросов внутри 1С. Без него веб-клиент выдаст ошибку 404 на любой странице, кроме главной. Параметр AllowOverride All разрешает использование .htaccess, который 1С может создать для перенаправлений.
Настройка Nginx для проксирования 1С: решаем проблему с WebSocket и таймаутами
Создайте отдельный server block в Nginx для 1С. Ключевые моменты: поддержка WebSocket, увеличенные таймауты для долгих операций (проведение документов, формирование отчетов), корректная передача заголовков для лицензирования.
server {
listen 80;
server_name 1c.mysite.ru;
location /erp {
proxy_pass http://127.0.0.1:8080/erp;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
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_read_timeout 600s;
proxy_send_timeout 600s;
proxy_buffering off;
}
}Директивы proxy_http_version 1.1 и заголовки Upgrade/Connection обеспечивают работу WebSocket для тонкого клиента. Таймауты в 600 секунд предотвращают обрыв соединения при формировании тяжелого отчета. proxy_buffering off отключает буферизацию ответов - это важно для потоковой передачи данных от 1С. Если у вас несколько баз, создайте отдельный location для каждой: /erp, /buh, /zup с соответствующими proxy_pass.
После настройки проверьте работу веб-клиента по адресу http://1c.mysite.ru/erp. Авторизуйтесь, откройте несколько форм, сформируйте отчет. Если возникает ошибка «Не найдена свободная лицензия», проверьте, что заголовок X-Forwarded-For корректно передается в Apache и далее в 1С. Проблема часто решается настройкой параметра proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for.
Настройка SSL-сертификатов: защищаем соединение
HTTPS обязателен для любых проектов, где передаются учетные данные, персональные данные или финансовая информация. Для 1С это требование №1 при доступе из интернета. Настройка выполняется на стороне Nginx - Apache получает уже расшифрованный трафик.
Автоматизация Let's Encrypt на Linux и Windows
На Ubuntu установите certbot:
sudo apt install certbot python3-certbot-nginx -y
sudo certbot --nginx -d mysite.ru -d www.mysite.ru -d 1c.mysite.ruCertbot автоматически найдет server blocks в Nginx, получит сертификаты и пропишет их в конфигурацию. Добавьте автообновление в cron:
sudo crontab -e
# Добавьте строку:
0 3 * * * certbot renew --quiet --post-hook "systemctl reload nginx"На Windows используйте win-acme (github.com/win-acme/win-acme). Запустите wacs.exe, выберите создание нового сертификата, укажите домены и способ проверки (http-01). После получения сертификата win-acme автоматически создаст задачу в Планировщике задач Windows для обновления. Пути к сертификатам пропишите в конфигурации Nginx вручную.
Конфигурация Nginx для HTTPS и проксирования
Дополните server block для сайта и 1С секциями SSL:
server {
listen 443 ssl http2;
server_name mysite.ru www.mysite.ru;
ssl_certificate /etc/letsencrypt/live/mysite.ru/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mysite.ru/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header X-Forwarded-Proto https;
# остальные заголовки
}
}
server {
listen 80;
server_name mysite.ru www.mysite.ru;
return 301 https://$host$request_uri;
}Заголовок X-Forwarded-Proto https критичен: Apache и приложение должны знать, что клиент использует защищенное соединение. Без него 1С может генерировать ссылки с http://, что сломает работу веб-клиента при редиректах. HSTS-заголовок указывает браузеру всегда использовать HTTPS для этого домена в течение года.
Оптимизация производительности: кэширование и балансировка нагрузки
Кэширование статики и динамики в Nginx
Кэширование ответов от Apache снижает нагрузку на бэкенд в 5-10 раз для повторяющихся запросов. Добавьте в секцию http файла nginx.conf:
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=my_cache:100m max_size=10g inactive=60m use_temp_path=off;В server block настройте кэширование для конкретных location:
location /api/ {
proxy_pass http://127.0.0.1:8080;
proxy_cache my_cache;
proxy_cache_valid 200 10m;
proxy_cache_valid 404 1m;
proxy_cache_key "$scheme$request_method$host$request_uri";
add_header X-Cache-Status $upstream_cache_status;
}Для 1С кэширование настраивается осторожно. Кэшируйте только GET-запросы к справочникам и отчетам без параметров. Исключите из кэша пути, содержащие /e1cib/ и POST-запросы - это операции записи данных. Заголовок X-Cache-Status помогает отлаживать кэш: значение HIT означает попадание в кэш, MISS - промах.
Балансировка нагрузки между несколькими серверами Apache
Если одного Apache недостаточно, добавьте второй сервер и настройте upstream в Nginx:
upstream apache_backend {
least_conn;
server 127.0.0.1:8080 weight=3 max_fails=2 fail_timeout=30s;
server 192.168.1.11:8080 weight=1 max_fails=2 fail_timeout=30s;
server 192.168.1.12:8080 backup;
}
server {
location / {
proxy_pass http://apache_backend;
proxy_next_upstream error timeout invalid_header http_500 http_502 http_503;
}
}Метод least_conn отправляет запрос на сервер с наименьшим числом активных соединений - это оптимально для долгих запросов 1С. Параметр weight задает пропорцию распределения: сервер с weight=3 получит втрое больше запросов. Сервер с флагом backup включается только при отказе основных. proxy_next_upstream автоматически повторяет запрос на другом бэкенде при ошибке.
Типовые ошибки и их решение: от 502 Bad Gateway до проблем с 1С
Диагностика с помощью логов и утилит
Первое действие при любой проблеме - проверка логов. Выполните на Linux:
sudo tail -f /var/log/nginx/error.log /var/log/apache2/error.logНа Windows логи находятся в C:\nginx\logs\error.log и C:\Apache24\logs\error.log. Откройте их в блокноте или используйте PowerShell: Get-Content C:\nginx\logs\error.log -Tail 50. Для быстрой проверки доступности Apache напрямую выполните curl с сервера:
curl -H "Host: mysite.ru" http://127.0.0.1:8080/Если Apache отвечает, а Nginx возвращает 502, проблема в конфигурации проксирования. Проверьте, что proxy_pass указывает на правильный порт и интерфейс. Команда curl -I http://mysite.ru покажет заголовки ответа, включая X-Cache-Status и ошибки на уровне HTTP.
Решение специфических проблем 1С
Ошибка «Не найдена лицензия» возникает при неправильной передаче IP-адреса клиента. 1С определяет клиента по IP и привязывает к нему лицензию. Если все запросы приходят с IP 127.0.0.1 (от Nginx), лицензия будет одна на всех. Решение: проверьте наличие proxy_set_header X-Real-IP и X-Forwarded-For в конфигурации Nginx и настройте модуль mod_remoteip в Apache для восстановления реального IP.
Обрыв соединения тонкого клиента связан с отсутствием поддержки WebSocket. Убедитесь, что в location для 1С присутствуют директивы proxy_http_version 1.1, proxy_set_header Upgrade и Connection. Дополнительно проверьте, что модуль proxy_wstunnel не отключен в сборке Nginx (команда nginx -V 2>&1 | grep proxy_wstunnel).
Долгая загрузка базы 1С через веб-клиент ускоряется включением сжатия gzip в Nginx:
gzip on;
gzip_types application/json application/xml text/html text/css text/javascript;
gzip_min_length 1000;
gzip_comp_level 5;Сжатие снижает объем передаваемых данных на 60-80%, но не применяйте его для уже сжатых файлов (картинки, PDF).
Заключение: ваш сервер готов к работе
Вы настроили связку Nginx + Apache с разделением статики и динамики, опубликовали базу 1С с поддержкой WebSocket, установили SSL-сертификаты с автообновлением и включили кэширование для ускорения ответа. Архитектура готова к production-нагрузкам.
Дальнейшие шаги для поддержки: настройте мониторинг логов через systemd-journald или EventLog, добавьте алерты при падении Apache (команда systemctl status apache2 в cron-скрипте), регулярно обновляйте Nginx и Apache до актуальных версий. Сохраните эту статью в закладки как шпаргалку - конфигурации проверены на практике и актуальны для версий 2026 года.