- Вопрос или проблема
- Ответ или решение
- Проблема "Слишком много перенаправлений" при использовании обратного прокси Nginx и настройки VPS с WordPress
- 1. Проблемы конфигурации Nginx
- Обратный прокси Nginx
- Защита от перенаправлений
- VPS-сервер с WordPress
- 2. Внутреннее управление HTTPS в WordPress
- 3. Дополнительные заголовки и конфигурации
- 4. Лучшие практики для настройки Nginx обратного прокси с несколькими WordPress
Вопрос или проблема
Я управляю несколькими сайтами WordPress на отдельных VPS-инстансах, управляемых Proxmox. Я использую сервер Nginx в качестве обратного прокси для управления HTTPS и перенаправления трафика на каждый VPS. Эта настройка предназначена для воспроизведения для других сайтов в будущем, поэтому я использую обратный прокси и выделенный VPS для каждого сайта.
В настоящее время, когда я обращаюсь к своему сайту через браузер, я получаю ошибку “Слишком много перенаправлений”. Сайт работает отлично, когда к нему обращаются локально на VPS через HTTP или используя curl с обратного прокси.
Межсетевой экран в моей сети – это устройство Fortinet, настроенное на перенаправление всего трафика на портах 80 и 443 на виртуальную машину обратного прокси. Обратный прокси отвечает за маршрутизацию трафика к соответствующему VPS. Однако, когда я обращаюсь к моему сайту через браузер, я получаю ошибку “Слишком много перенаправлений”. Сайт работает отлично, когда к нему обращаются локально на VPS через HTTP или используя curl с обратного прокси или просто вводя IP-адрес VPS в локальной сети.
Вот моя текущая настройка:
Инфраструктура:
- Гипервизор: Proxmox
- Сервер обратного прокси: Nginx, работающий в качестве шлюза для нескольких сайтов в виде виртуальных машин.
- VPS: У каждого сайта есть свой VPS-инстанс, на котором работают Nginx и WordPress.
Настройка обратного прокси (Nginx):
server {
listen 443 ssl;
server_name mysite.com www.mysite.com;
ssl_certificate /etc/letsencrypt/live/mysite.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mysite.com/privkey.pem;
location / {
proxy_pass http://192.168.1.121; # IP адрес VPS
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_redirect http:// https://;
}
}
Настройка VPS WordPress (Nginx):
server {
listen 80;
server_name mysite.com www.mysite.com;
root /var/www/html/mysite.com;
index index.php index.html index.htm;
location / {
try_files $uri $uri/ /index.php?$args;
}
location ~ \.php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
}
location ~ /\. {
deny all;
}
location = /wp-config.php {
deny all;
}
location = /xmlrpc.php {
deny all;
}
}
ChatGPT также предложил следующее в файле wp-config.php (я не уверен, будет ли это работать):
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');
Текущий статус:
- Запуск curl -IL https://example.com с моего устройства показывает 200 OK.
- Браузер, однако, отображает ошибку “Слишком много перенаправлений”.
- WordPress настроен на использование https://example.com как для siteurl, так и для home.
- Логи не показывают очевидных ошибок, кроме типичных предупреждений WordPress о плагине.
Дополнительная информация:
- Обратный прокси и VPS находятся в одной локальной сети, управляемой Proxmox.
- Я убедился, что DNS-записи указывают на публичный IP-адрес обратного прокси.
Вопросы:
1 Есть ли проблема с моими настройками Nginx для обратного прокси или VPS WordPress?
2 Может ли это быть связано с внутренней обработкой HTTPS или постоянных ссылок WordPress?
3 Есть ли дополнительные заголовки или настройки, которые я должен включить для решения этой проблемы?
4 Есть ли другой подход к настройке обратного прокси Nginx для нескольких сайтов WordPress на отдельных VPS-инстансах, управляемых Proxmox?
Ответ или решение
Проблема "Слишком много перенаправлений" при использовании обратного прокси Nginx и настройки VPS с WordPress
Ваша установка, состоящая из нескольких VPS с WordPress, управляемых через Proxmox, и обратного прокси-сервера на Nginx, на первый взгляд, выглядит неплохо сконфигурированной. Однако ошибка "Слишком много перенаправлений", возникающая при доступе к сайту через браузер, указывает на наличие проблемы в конфигурации или взаимодействии между компонентами. Давайте разберем это подробно.
1. Проблемы конфигурации Nginx
Обратный прокси Nginx
Ваш конфигурационный файл обратного прокси сервера выглядит следующим образом:
server {
listen 443 ssl;
server_name mysite.com www.mysite.com;
ssl_certificate /etc/letsencrypt/live/mysite.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mysite.com/privkey.pem;
location / {
proxy_pass http://192.168.1.121; # IP VPS
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_redirect http:// https://;
}
}
Защита от перенаправлений
Проблема может заключаться в том, что WordPress ожидает HTTPS соединение, так как вы настроили прокси для работы через SSL. Обратите внимание на строку:
proxy_set_header X-Forwarded-Proto $scheme;
Этот заголовок должен передавать схему (http или https) от клиента к серверу назначения. Убедитесь, что заголовок X-Forwarded-Proto
корректно устанавливается в https
на стороне прокси. Это поможет WordPress распознать, что он работает через HTTPS.
VPS-сервер с WordPress
Ваша конфигурация Nginx на VPS должна также учитывать, что она обслуживается через обратный прокси. Однако вы настраиваете сервер для работы на порту 80:
server {
listen 80;
server_name mysite.com www.mysite.com;
Рекомендуется добавить соответствующий конфиг для порта 443 с SSL:
server {
listen 443 ssl;
server_name mysite.com www.mysite.com;
ssl_certificate /etc/letsencrypt/live/mysite.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/mysite.com/privkey.pem;
# Остальные параметры...
}
2. Внутреннее управление HTTPS в WordPress
Ваши установки в файле wp-config.php
также правильные. Однако, если вы видите проблему с перенаправлениями, добавление проверки на HTTP_X_FORWARDED_PROTO
позволит убедиться, что WordPress корректно обрабатывает HTTPS:
if (isset($_SERVER['HTTP_X_FORWARDED_PROTO']) && $_SERVER['HTTP_X_FORWARDED_PROTO'] === 'https') {
$_SERVER['HTTPS'] = 'on';
}
define('WP_HOME', 'https://example.com');
define('WP_SITEURL', 'https://example.com');
3. Дополнительные заголовки и конфигурации
Кроме X-Forwarded-Proto
, могут быть полезны следующие заголовки:
X-Forwarded-Host
: Этот заголовок указывает оригинальный хост заголовок.X-Real-IP
: Устанавливает IP-адрес клиента, который может быть полезен для безопасности и аналитики.
Убедитесь, что все необходимые заголовки передаются правильно.
4. Лучшие практики для настройки Nginx обратного прокси с несколькими WordPress
-
Структурируйте конфигурацию: Убедитесь, что каждый VPS имеет свою собственную конфигурацию для обработки запросов на соответствующие доменные имена. Это обеспечит лучшую читаемость конфигураций и меньше шансов на конфликты.
-
Применяйте SSL на уровне прокси и приложения: Имея SSL как на уровне прокси, так и на VPS (при необходимости), вы создадите дополнительный слой безопасности.
-
Мониторинг и автоматизация: Используйте инструменты мониторинга для отслеживания состояния вашего прокси и приложений. Это позволит вовремя реагировать на возможные сбои.
-
Бэкапы и тестирование: Регулярно создавайте резервные копии конфигурационных файлов и баз данных. Перед изменением конфигураций всегда тестируйте изменения в контролируемой среде.
Исходя из вышеизложенного, проблема "Слишком много перенаправлений" скорее всего связана с неправильной передачей заголовков между Nginx и WordPress. Убедитесь, что ваше приложение получает корректные заголовки, и что конфиг вашего VPS поддерживает HTTPS. Если проблема сохраняется, рассмотрите возможность глубокого анализа HTTP-заголовков с помощью инструментов как curl
или Postman
для детального выявления проблемы.