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;
}

Этот пример неполон и может быть небезопасным; это только демонстрирует, как ваша проблема может быть решена. Убедитесь, что ваш веб-сервер надежно защищен.

Другие вопросы по тегам