WordPress + php-fpm + NGINX не находит API только в продакшене

Вопрос или проблема

Я запускаю docker-приложение на wordpress

образы: nginx:latest, wordpress:6.5.4-fpm, mysql:8.0

Я использую плагин Contact Form 7

адрес api:
http://localhost:8888/wp-json/contact-form-7/v1/contact-forms/82/feedback

при нажатии кнопки отправки в тестовой среде всё работает, и я получаю корректно отформатированный JSON-ответ, как этот:

{
    "contact_form_id": 82,
    "status": "validation_failed",
    "message": "Одно или несколько полей содержат ошибку. Пожалуйста, проверьте и попробуйте снова.",
    "invalid_fields": [
        {
            "field": "birth",
            "message": "Пожалуйста, заполните это поле.",
            "idref": null,
            "error_id": "wpcf7-f82-p13-o1-ve-birth"
        },

но в продакшене я получаю 404 Not found перед JSON-ответом, и браузер говорит, что JSON-ответ неверен. Форма отправляется, но я просто не получаю ответа после отправки.

404: Not Found{"contact_form_id":82...

Я пытался удалить .htaccess и восстановить постоянные ссылки, но это не сработало. Сайт работает нормально, за исключением этого.

все плагины обновлены.

единственное отличие в продакшене – это letsencrypt для HTTPS и nginx, настроенный для него. В тестовой среде я использую HTTP

nginx конфигурация для тестовой среды

server {
        listen 80;
        listen [::]:80;

        server_name localhost 127.0.0.1;

        index index.php index.html index.htm;

        root /var/www/html;

        client_max_body_size 200M;

        location / {
                try_files $uri $uri/ /index.php$is_args$args;
        }

        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass wordpress:9000;
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
        }

        location ~ /\.ht {
                deny all;
        }

        location = /favicon.ico {
                log_not_found off; access_log off;
        }
        location = /robots.txt {
                log_not_found off; access_log off; allow all;
        }
        location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ {
                expires max;
                log_not_found off;
        }
}

nginx конфигурация для продакшена

server {
        listen 80;
        listen [::]:80;

        server_name mywebstite.com www.mywebstite.com;

        index index.php index.html index.htm;

        root /var/www/html;

        location ~ /.well-known/acme-challenge {
                allow all;
                root /var/www/html;
        }

        location / {
                try_files $uri $uri/ /index.php$is_args$args;
        }

        location ~ \.php$ {
                try_files $uri =404;
                fastcgi_split_path_info ^(.+\.php)(/.+)$;
                fastcgi_pass wordpress:9000;
                fastcgi_index index.php;
                include fastcgi_params;
                fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
                fastcgi_param PATH_INFO $fastcgi_path_info;
        }

        location ~ /\.ht {
                deny all;
        }

        location = /favicon.ico {
                log_not_found off; access_log off;
        }
        location = /robots.txt {
                log_not_found off; access_log off; allow all;
        }
        location ~* \.(css|gif|ico|jpeg|jpg|js|png)$ {
                expires max;
                log_not_found off;
        }
}

.

Ответ или решение

Проблема, с которой вы столкнулись, связана с тем, что при использовании API Contact Form 7 в производственной среде NGINX не может корректно обработать ваш запрос, что приводит к ошибке 404. Давайте разберем возможные причины и пути их устранения.

1. Анализ конфигурации NGINX

Основной конфигурационный файл NGINX для вашей производственной среды может не обрабатывать запросы к API, поэтому ссылка на wp-json возвращает 404. Важно обратить внимание на следующие моменты:

  • URL-адрес сайта: Убедитесь, что вы используете правильный адрес сайта mywebsite.com в качестве базового пути. Если вы тестируете через локальный сервер, пути различаются.

  • Права доступа: Проверьте, что сервер имеет разрешение на доступ к необходимым путям. Ваша конфигурация location / корректна, однако стоит обратить внимание на специфические запросы к API и возможно добавить явные маршруты.

2. Убедитесь в корректности SSL и HTTPS

Ваша производственная среда использует Let’s Encrypt для HTTPS. Проверьте, правильно ли настроены все правила перенаправления с HTTP на HTTPS. Например вы можете добавить следующие строки в конфигурацию:

server {
    listen 80;
    listen [::]:80;
    server_name mywebsite.com www.mywebsite.com;

    return 301 https://$server_name$request_uri; # перенаправление на HTTPS
}

3. Проверьте настройки пермалинков WordPress

Поскольку вы уже пробовали удалить .htaccess (хотя в NGINX этот файл не нужен), убедитесь, что в админке WordPress вы до этого меняли настройки пермалинков. Перейдите в Настройки -> Постоянные ссылки и просто нажмите Сохранить изменения, чтобы перезаписать настройки.

4. Отладка API

Попробуйте проверить запросы к API с помощью инструментов разработчика в вашем браузере. Откройте вкладку Сеть (Network) и отследите, какие именно запросы отправляются и какой ответ возвращается. Это может предоставить дополнительную информацию о том, что идет не так.

5. Логи NGINX

Проверьте логи ошибок NGINX, которые можно найти по привычному пути /var/log/nginx/error.log. Это даст представление о том, какие ошибки были зарегистрированы во время обработки запросов. Возможно, там будет указана причина ошибки 404.

6. Заключение

Сравнив конфигурации вашего окружения разработки и продакшена, а также проверив настройки SSL и API, вы сможете установить источник проблемы. Ключевыми моментами являются правильная настройка маршрутов для API и корректная обработка запросов к ним. После внесения изменений не забудьте перезапустить NGINX для применения новых настроек:

sudo service nginx restart

Если после этих действий проблема останется, может потребоваться более детальное изучение конфигураций и логов.

Оцените материал
Добавить комментарий

Капча загружается...