nginx: контроль доступа к журналу при сохранении внутреннего перенаправления в WordPress
Я создал страницу WordPress с постоянной ссылкой http://domain.tld/health_status
для мониторинга здоровья WordPress. К нему часто обращаются, поэтому я не хочу, чтобы эти запросы появлялись в моем журнале доступа.
Основное "правило перезаписи" для всех страниц WordPress:
location / {
try_files $uri $uri/ /index.php?q=$args;
}
Теперь на том же уровне, я пытался
location /health_status {
access_log off;
#try_files $uri $uri/ /index.php?q=$args;
}
Из документации по расположению nginx:
Литеральные строки соответствуют начальной части запроса - будет использовано наиболее точное соответствие
/health_status
более конкретно, чем /
поэтому этот блок выполняет действие, когда я запрашиваю http://domain.tld/health_status
,
С try_files
строка закомментирована (как указано выше), запрос не отображается в журнале доступа, ура, но, очевидно, я просто получаю ошибку 404, потому что nginx не перенаправляет этот запрос в WordPress.
С try_files
линия активна, внутренний редирект на WordPress index.php
имеет место и /health_status
Страница WordPress отображается в браузере. Однако после внутреннего перенаправления location /health_status
Блок больше не работает, и запрос заканчивается в журнале доступа.
Как решить эту проблему чисто? Теперь я должен добавить еще один блок, соответствующий фактическому /index.php?q=healthstatuswhatever
запрос, который происходит после внутреннего перенаправления?
Спасибо!
1 ответ
Вы должны использовать именованное местоположение для запросов, предназначенных для WordPress. Пример этого:
location ~ \.php$ {
try_files $uri =404;
fastcgi_ ### fastcgi params and other config for PHP go here
}
location @wordpress {
try_files $uri /index.php;
fastcgi_ ### fastcgi params and other config for WP go here
}
location / {
try_files $uri $uri/ @wordpress;
}
location /health_status {
access_log off;
try_files $uri $uri/ @wordpress;
}
Этот пример неполон и может быть небезопасным; это только демонстрирует, как ваша проблема может быть решена. Убедитесь, что ваш веб-сервер надежно защищен.