Я настроил nginx для разрыва SSL-соединения и пересылки запросов на http-сервер. Клиент делает несколько фоновых запросов, один из которых завершается с ошибкой 400 неверный запрос
всякий раз, когда он пытается согласовать соединение SSL. Если ему не нужно согласовывать соединение - например. если другой фоновый запрос только что успешно отправлен, запрос выполняется успешно. Изучение вкладки сети Chrome не показывает существенной разницы между успешным запросом и неудачным запросом. Мое путешествие опубликовано здесь в этот отчет об ошибке, но вот что я смог перегонять до сих пор:
SSL-соединение
Когда запрос о проблеме выполняется успешно, я могу сказать, что ему не нужно согласовывать SSL-соединение, просмотрев вкладку «Время» сетевого запроса (в Chrome): Время - успешный запрос
С другой стороны, всякий раз, когда запрос терпит неудачу, я вижу, что он пытался согласовать SSL-соединение, как показано на этом изображении: Время — неудавшийся запрос
Обработка Nginx
Проверив журналы доступа к приложениям, я определил, что именно nginx возвращает ошибка 400, неверный запрос
ошибка, а не приложение HTTP.Когда запрос завершается неудачно, все журналы nginx являются телом POST. скорее, чем метод HTTP и URL как обычно (я не настраивал формат журнала nginx).
Я включил отладку в журнале ошибок nginx (со строкой error_log /var/log/nginx/error.log отладка;
). Это позволяет мне видеть, что происходит во время согласования SSL (хотя я этого не понимаю).
Как я кратко упомянул выше, есть и другие фоновые запросы, которые выполняются успешно, хотя и выполняются реже. После успешного выполнения любого запроса все запросы будут выполняться в течение определенного периода времени (пока им не потребуется согласовать SSL-соединение).
Кроме того, если я использую Скопировать как cURL
функциональность из Chrome и запустить запрос как запрос cURL, он всегда завершается успешно. Единственный раз, когда я заметил, что это не удается, - это когда браузер делает запрос.
Журналы отладки Nginx
Вот соответствующий бит из успешного запроса SSL в журналах:
22.10.2021 20:37:59 [отладка] 1858722#1858722: *441 бесплатно: 0000562A9F69F340
22.10.2021, 20:37:59 [отладка] 1858722#1858722: *438 http восходящий запрос: "/api/method/frappe.core.doctype.log_settings.log_settings.has_unseen_error_log?"
22.10.2021, 20:37:59 [отладка] 1858722#1858722: *438 HTTP заголовок восходящего процесса
22.10.2021 20:37:59 [отладка] 1858722#1858722: *438 malloc: 0000562A9F712CB0:131072
22.10.2021, 20:37:59 [отладка] 1858722#1858722: *438 recv: eof:0, avail:-1
22.10.2021, 20:37:59 [отладка] 1858722#1858722: *438 recv: fd:9 678 из 131072
22.10.2021, 20:37:59 [отладка] 1858722#1858722: *438 статус HTTP-прокси 200 «200 OK»
22.10.2021, 20:37:59 [отладка] 1858722#1858722: *438 заголовок http-прокси: «Сервер: gunicorn»
... больше заголовков http-прокси ...
22.10.2021, 20:37:59 [отладка] 1858722#1858722: *438 HTTP-заголовок прокси выполнен
22.10.2021, 20:37:59 [отладка] 1858722#1858722: *438 заголовок фильтра xslt
22.10.2021 20:37:59 [отладка] 1858722#1858722: *438 HTTP/1.1 200 ОК
Сервер: nginx/1.18.0 (Ubuntu)
... HTTP-ответ
Вот неудачные переговоры:
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 бесплатно: 0000562A9F69F340
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 обработчик запроса ожидания HTTP
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 malloc: 0000562A9F69F340:1024
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 SSL_read: 812
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 SSL_read: -1
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 SSL_get_error: 2
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 многоразовое соединение: 0
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 posix_memalign: 0000562A9F70CEB0:4096 @16
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 строка запроса процесса http
22.10.2021, 20:39:00 [информация] 1858722#1858722: *446 клиент отправил неверный метод при чтении строки запроса клиента, клиент: 107.185.20.83, сервер: atlas-dev.ebs.llc, запрос: "doctype= Error+Log&fields=%5B%22%60tabError+Log%60.%60name%60%22%2C%22%60tabError+Log%60.%60owner%60%22%2C%22%60tabError+Log%60.% 60creation%60%22%2C%22%60tabError+Log%60.%60modified%60%22%2C%22%60tabError+Log%60.%60modified_by%60%22%2C%22%60tabError+Log%60. %60_user_tags%60%22%2C%22%60tabError+Log%60.%60_comments%60%22%2C%22%60tabError+Log%60.%60_assign%60%22%2C%22%60tabError+Log%60 .%60_liked_by%60%22%2C%22%60tabError+Log%60.%60docstatus%60%22%2C%22%60tabError+Log%60.%60parent%60%22%2C%22%60tabError+Log% 60.%60parenttype%60%22%2C%22%60tabError+Log%60.%60parentfield%60%22%2C%22%60tabError+Log%60.%60idx%60%22%2C%22%60tabError+Log %60.%60method%60%22%2C%22%60tabError+Log%60.%60seen%60%22%5D&filters=%5B%5D&order_by=%60tabError+Log%60.%60modified%60+desc&start=0&page_length= 20&view=Список&with_comment_count=true"
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 http finalize request: 400, "?" а:1, в:1
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 таймер событий del: 9: 337737968
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 специальный ответ http: 400, "?"
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 http set discard body
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 заголовок фильтра xslt
22.10.2021, 20:39:00 [отладка] 1858722#1858722: *446 HTTP/1.1 400 Неверный запрос
Сервер: nginx/1.18.0 (Ubuntu)
Дата: пятница, 22 октября 2021 г., 20:39:00 по Гринвичу
Тип содержимого: текст/html
Длина контента: 166
Подключение: близко
Основываясь на том немногом, что я знаю о журнале отладки nginx (то есть ничего), мне кажется, что nginx меняет HTTP-метод и URL-адрес тела во время согласования. Когда он ищет метод HTTP, его больше нет, и он задыхается.
Конфигурация Nginx SSL
Информация о версии: nginx/1.18.0 (Убунту)
, Убунту 20.04 ЛТС
я использую по умолчанию nginx.conf
. SSL-часть конфигурации сервера выглядит следующим образом:
слушать 443 ssl;
имя_сервера [ХОСТ];
корень /opt/erpnext/bench/sites;
proxy_buffer_size 128k;
proxy_buffers 4 256 КБ;
proxy_busy_buffers_size 256 КБ;
ssl_certificate /etc/letsencrypt/live/[HOST]/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/[HOST]/privkey.pem;
ssl_session_timeout 5 м;
ssl_session_cache общий: SSL: 10 м;
ssl_session_tickets выключен;
ssl_stapling включен;
ssl_stapling_verify включен;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_ecdh_curve secp384r1;
ssl_prefer_server_ciphers включен;
В нижней части файла есть перенаправление SSL, и nginx настроен для сервера веб-сервера HTTP на основе плоского файла на порту 8080 из другой конфигурации.
Как я могу определить, что вызывает проблему? Я знаю, что запрос сформирован правильно, потому что идентичные запросы выполняются... до тех пор, пока не потребуется согласовать SSL-соединение. Помощь?