Постоянные ссылки WordPress возвращают 404 при использовании NGINX в качестве обратного прокси для Apache
Я пытаюсь получить NGINX для обратного прокси & обеспечить SSL-терминацию для сайта WordPress, работающего на Apache, через порт 8086. Я хочу, чтобы NGINX обрабатывал статические файлы и передавал только запросы PHP к Apache.
Мне удалось заставить это работать, используя стандартные ссылки.
(Т.е. https://example.com/?post=274 работает правильно)
Когда я включаю постоянные ссылки любого типа, загружается домашняя страница, как и wp-admin, но https://example.com/what-we-do/ выходит из строя.
Глядя на логи NGINX, я вижу
2018/05/23 09:36:40 [error] 7472#0: *1 "/var/www/example.com/live_site/what-we-do/index.php" is not found (2: No such file or directory), client: xxx.xxx.xxx.xxx, server: example.com, request: "GET /what-we-do/ HTTP/2.0", host: "example.com", referrer: "https://example.com/?post=274"Поэтому NGINX пытается искать /permalink/index.php как статический путь / файл вместо передачи в apache. Есть мысли о том, как заставить это работать?
Мой NGINX Config выглядит так:
upstream example_apache {
ip_hash;
server 127.0.0.1:8086;
}
server {
# HTTP/HTTPS Server Block
# General Config
listen [::]:80;
listen 80;
listen [::]:443 http2 ssl;
listen 443 http2 ssl;
server_name example.com
www.example.com;
root /var/www/example.com/live_site;
access_log /var/log/nginx/access-example.com.log main;
error_log /var/log/nginx/error-example.com.log;
index index.php;
#SSL Cert Configuration
# Check SSL config at https://www.ssllabs.com/ssltest/
ssl_prefer_server_ciphers on;
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers "ECDHE-ECDSA-CHACHA20-POLY1305 ECDHE-RSA-CHACHA20-POLY1305 EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH DHE-RSA-CHACHA20-POLY1305 EDH+aRSA !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4 !SEED !CAMELLIA";
ssl_session_cache shared:SSL:100m;
ssl_session_timeout 180m;
ssl_dhparam /var/www/certs/dh4096.pem;
ssl_certificate /var/www/certs/lets_encrypt/web01.example.com/web01.example.com.fullchain.secp384r1.cer;
ssl_certificate_key /var/www/certs/lets_encrypt/web01.example.com/web01.example.com.secp384r1.key;
ssl_certificate /var/www/certs/lets_encrypt/web01.example.com/web01.example.com.fullchain.rsa4096.cer;
ssl_certificate_key /var/www/certs/lets_encrypt/web01.example.com/web01.example.com.rsa4096.key;
# Enable HSTS #Deploy in stages to prevent extended loss to site.
add_header Strict-Transport-Security "max-age=300; includeSubdomains;"; #300s-5min TTL Testing
#add_header Strict-Transport-Security "max-age=604800; includeSubdomains;"; #1week TTL Testing
#add_header Strict-Transport-Security "max-age=2592000; includeSubdomains;"; #1month TTL Testing
#add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"; #10886400s-126days Min for Preload
#add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload"; #63072000s-2years Production Value
# OCSP Configuration
ssl_trusted_certificate /var/www/certs/lets_encrypt/web01.example.com/web01.example.com.fullchain.secp384r1.cer;
ssl_stapling on;
ssl_stapling_verify on;
resolver 8.8.4.4 8.8.8.8 valid=300s;
resolver_timeout 10s;
# LetEncrypt webroot alias
location /.well-known/acme-challenge/ {
alias /var/www/le_root/.well-known/acme-challenge/;
}
# www to non-www rewrite
# Redirect to the correct place, if needed
set $https_redirect 0;
if ($server_port = 80) { set $https_redirect 1; }
if ($host ~ '^www\.') { set $https_redirect 1; }
if ($https_redirect = 1) {
return 301 https://example.com$request_uri;
}
# WordPress entry point
location / {
#Try file dir index.php else 404
try_files $uri $uri/ /index.php?$args =404;
#All Files except for *.php
location ~ .+(?<!\.php)$ {
location ~ ^[^.]+\.[^.]+$ {
expires max;
add_header Cache-Control public;
break;
}
}
#Only *.php files
location ~ \.php$ {
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass_header Set-Cookie;
proxy_set_header SSL_PROTOCOL $ssl_protocol;
proxy_set_header SSL_CLIENT_CERT $ssl_client_cert;
proxy_set_header SSL_CLIENT_VERIFY $ssl_client_verify;
proxy_set_header SSL_SERVER_S_DN $ssl_client_s_dn;
proxy_pass http://example_apache;
}
}
}
Так как эта проблема даже не касается части прохождения прокси и, похоже, имеет отношение к NGINX (что я могу сказать), следующее не применимо. Но кому-то будет интересно, или это может помочь другим, споткнувшимся в этом вопросе, знать и сторону конфигурации Apache.
В моем apache есть файл .htaccess, содержащий:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
И мой wp-config.php имеет:
// If WordPress is behind reverse proxy
// which proxies https to http
if ( (!empty( $_SERVER['HTTP_X_FORWARDED_HOST'])) ||
(!empty( $_SERVER['HTTP_X_FORWARDED_FOR'])) ) {
$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
$_SERVER['HTTPS'] = 'on';
}
И мой конфиг apache имеет:
<VirtualHost *:8086>
ServerAdmin webmaster@localhost
DocumentRoot /var/www/example.com/live_site
ServerName example.com
ServerAlias www.example.com
ErrorLog ${APACHE_LOG_DIR}/example.com.error.log
CustomLog ${APACHE_LOG_DIR}/example.com.access.log combined
Alias "/.well-known/acme-challenge/" "/var/www/le_root/.well-known/acme-challenge/"
<Directory />
Options FollowSymLinks
AllowOverride None
</Directory>
<Directory /var/www/example.com/live_site>
Options Indexes FollowSymLinks MultiViews
AllowOverride All
Order allow,deny
allow from all
</Directory>
</VirtualHost>
Следует также отметить, что когда я подключаюсь напрямую к Apache, я могу видеть все постоянные ссылки на странице правильно. (Т.е. http://127.0.0.1:8086/what-we-do/ работает правильно)
NGINX версия 1.13.9
Apache 2.4.33 mpm_prefork
PHP версия 7.1
Будем весьма благодарны за любые мысли или помощь в получении NGINX для правильной ссылки на proxy в apache!
Решение
Включите или проверьте, включен ли mod_rewrite с помощью этой команды
sudo a2enmod переписать
Другие решения
Я получил эту же ошибку при переносе своей среды Prod в Docker с использованием NGINX, но я не использовал обратный прокси-сервер для Apache. Моя ошибка была такой же, хотя.
Причина была в том, что я должен был изменить wp_options соответствовать моему новому локальному порту и URL.
SELECT * FROM wp_options WHERE option_name='siteurl' OR option_name='home'; покажет вам текущий URL, к которому пытается перейти ваш WordPress Config. Но поскольку вы создали прокси-сервер и теперь ваш WordPress-сайт находится за другим портом или URL-адресом, вам может потребоваться изменить эти значения.
Когда вы выполните эту команду, вы получите список из двух URL, которые ваш сайт использует в качестве префикса. Если он показывает URL прокси, это, вероятно, не будет работать.
Затем я изменил URL-адреса, чтобы они соответствовали расположению НОВОГО внутреннего URL-адреса + порт. В вашем случае вам, скорее всего, придется изменить его, чтобы он соответствовал порту и URL за прокси, а не по URL самого прокси.
Изменение этих значений внутри моего wp-config.php не работал. например
define('WP_HOME','http://local.www.greenhousetreatment.com:8080');
define('WP_SITEURL','http://local.www.greenhousetreatment.com:8080');
ЭТО НЕ РАБОТАЕТ ДЛЯ МЕНЯ.
Мне пришлось вручную использовать указанную выше команду в SQL, а затем ОБНОВИТЬ эти значения, чтобы они соответствовали как ПОРТУ, так и URL-адресу веб-сайта. Обычно в обратных прокси-серверах вы вводите URL-адрес прокси-сервера, после чего он указывает IP-адрес службы и порт. Ваш сервис IP и PORT делает то, что ему нужно, так как он вообще не заботится о прокси. Он даже не знает о прокси.
Вы уверены, что ваш wp_options соответствует действительный URL службы и PORT, а не URL прокси?
Я надеюсь, что это могло бы пролить свет.