LINUX.ORG.RU

Соединение сброшено при POST запросе

 ,


0

2

Проблема в следующем, у некоторых пользователей нашего сервиса при сохранении записи на добавление/редактирование (по факту это POST запрос), сбрасывается соединение (В браузере ошибка Соединение сброшено).

На сервере используется Nginx, а за ним Apache.

В логах ошибка следующего вида (400):

185.67.94.* - - [06/Nov/2018:12:07:24 +0300] POST /activities/add HTTP/1.1 «400» 0 "https://secure.*******.ru/activities/add" «Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36» "-" 185.67.94.* - - [06/Nov/2018:12:08:05 +0300] POST /activities/add HTTP/1.1 «400» 0 "https://secure.*******.ru/activities/add" «Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36» "-"

Пробовали различные вариации буферов и конфигов, ситуация не меняется.

Прошу помочь, проблему не может решить уже несколько месяцев

cat /etc/nginx/nginx.conf
# Server globals
user                    www-data;
worker_processes        auto;
worker_rlimit_nofile    65535;
error_log               /var/log/nginx/error.log debug;
pid                     /var/run/nginx.pid;


# Worker config
events {
        worker_connections  20000;
        use                 epoll;
        multi_accept        on;
}


http {
    # Main settings
    sendfile on;
    tcp_nopush on;
    tcp_nodelay on;
    client_header_timeout 1m;
    client_body_timeout 1m;
    client_header_buffer_size 2k;
    client_body_buffer_size 256k;
    client_max_body_size 256m;
    large_client_header_buffers 4 256k;
    send_timeout 30;
    keepalive_timeout 1m;
    server_tokens off;
    server_name_in_redirect off;
    server_names_hash_max_size 512;
    server_names_hash_bucket_size 512;

    # Log format
    log_format  main    '$remote_addr - $remote_user [$time_local] $request '
                        '"$status" $body_bytes_sent "$http_referer" '
                        '"$http_user_agent" "$http_x_forwarded_for"';
    log_format  bytes   '$body_bytes_sent';
    access_log          /var/log/nginx/access.log main;


    # Mime settings
    include             /etc/nginx/mime.types;
    default_type        application/octet-stream;

    # Proxy settings
    proxy_redirect      off;
    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_pass_header   Set-Cookie;
    proxy_connect_timeout   90;
    proxy_send_timeout  90;
    proxy_read_timeout  90;
    proxy_buffers       32 4k;

    # Error pages
    error_page          403          /error/403.html;
    error_page          404          /error/404.html;
    error_page          502 503 504  /error/50x.html;


    # Cache settings
    proxy_cache_path /var/cache/nginx levels=2 keys_zone=cache:10m inactive=60m max_size=1024m;
    proxy_cache_key "$host$request_uri $cookie_user";
    proxy_temp_path  /var/cache/nginx/temp;
    proxy_ignore_headers Expires Cache-Control;
    proxy_cache_use_stale error timeout invalid_header http_502;
    proxy_cache_valid any 1d;


    # Cache bypass
    map $http_cookie $no_cache {
        default 0;
        ~SESS 1;
        ~wordpress_logged_in 1;
    }


    # File cache settings
    open_file_cache          max=10000 inactive=30s;
    open_file_cache_valid    60s;
    open_file_cache_min_uses 2;
    open_file_cache_errors   off;


    # Wildcard include
    include             /etc/nginx/conf.d/*.conf;
Ответ на: комментарий от zolden

Это глобальные настройки

proxy_pass в location и мне кажется это никак не может быть связано с проблемой, сервис прекрасно работает, просто изредка в случайном порядке возникают эти ошибки у некоторых пользователей

Parkwestil ()

Клиент передаёт данные, которые приложение не понимает и говорит 400 bad request. Надо включать отладку в самом приложении и смотреть уже его логи.

Dimez ★★★★★ ()

400 Bad Request — сервер обнаружил в запросе клиента синтаксическую ошибку.

В /var/log/nginx/error.log заглядывыли? И в соответствующий Apache-вский error-log?

Далее по списку - прикладной лог-журнал, куда должна сыпаться диагностика отказов и всяких ошибок, выявляемых уже на уровне прикладного обработчика HTTP-запросов. Если, конечно, у ваших программистов руки и мозги из правильного места растут )

vinvlad ()

... еще можно грешить, конечно, на ненадежную среду передачи данных, когда данные запроса искажаются или как-то рубятся. Но это маловероятно. И такие ситуации, по идее, должны отражаться в error-логах веб серверов.

vinvlad ()
Ответ на: комментарий от vinvlad

Ошибка не доходит до приложения, ее отдает Nginx

185.67.94.* - - [06/Nov/2018:12:07:24 +0300] POST /activities/add HTTP/1.1 «400» 0 "https://secure.*******.ru/activities/add" «Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36» "-" 185.67.94.* - - [06/Nov/2018:12:08:05 +0300] POST /activities/add HTTP/1.1 «400» 0 "https://secure.*******.ru/activities/add" «Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36» "-"

Parkwestil ()
Ответ на: комментарий от Parkwestil

Ошибка не доходит до приложения, ее отдает Nginx

На основании чего вы так решили?
Фрагмент access-лога, который вы приводите, абсолютно не о чем не говорит. Таким же образом, к примеру, Nginx будет возвращать 400-й код, полученный от Apache. Кстати, именно на это очень и похоже, поскольку типичный случай 400-го кода - это слишком длинный HTTP-шный куки-заголовок.

Вы анализировали содержимое access-лога Apache, относящееся к тому же времени?

vinvlad ()

Приведи полный конфиг включая location. То что там нет ничего интересного для твоей проблемы - ошибка, а не аксиома. Как минимум, рядом с proxy_pass есть fcgi параметры и именно по ним может быть отсечка.

BaBL ★★★★★ ()