Re: fastcgi keep conn on и fastcgi finish request() в PHP
Подтверждаю проблему в последних версиях 2019 года присутствует. При включенных fastcgi_keep_conn и keepalive, если скрипт завершился через fastcgi_finish_request() и продолжает выполнять работу в фоне, то следующий запрос другого клиента к php-fpm может получить 502 ошибку, придя по тому же коннекту, уже судя по всему не сможет подключиться к php-fpm, тк тот все еще выполняет прошлую задачу. Вопрос, почему запрос пихается на не завершенный процесс. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,247596,282747#msg-282747 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Битые файлы в кеше при gzip ответах
Максим, прокси версии 1.1 итак установлен, битые файлы на нем и получаются. Клаудфлер тоже использует 1.1 у них так же битые файлы часто лежат в кеше, проверял лично. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285267#msg-285267 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Битые файлы в кеше при gzip ответах
Бэкэенд это nginx который шлет обычные файлы js сжатые с помощью встроенного gzip Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285269#msg-285269 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Битые файлы в кеше при gzip ответах
Ничего не генерится, файлы лежат на диске, созданы один раз и записаны на диск. Nginx должен сжать его на лету и отдать, вот, что от него требуется, он это выполняет, но иногда в кэше браузера/клаудфлера лежит обрезанный файл, например половина его (уже разжатый, тупо не весь, не хватает куска кода в конце файла) возникает ли ошибка при разжатии я не знаю, видно только, что файл читаемый, но код не полный, чаще только половина его) я так понял, что в процессе передачи или упаковки возникает какая-то проблема и nginx принимает файл от другого nginx/браузера без проверки его на целостность...Размеры файлов не более 20кб. Вопрос такой: возможно ли распаковать архив, если он получен не полностью? (Тк тест в js файла читаемый, но файл состоит только из половины того, что должно быть) Если gzip архив можно распаковать, получив только половину файла, то может быть проблема в передаче и не удостоверении, что файл передан полностью. Если архив невозможно распаковать, не получив полностью, значит проблема в упаковщике. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285271#msg-285271 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Битые файлы в кеше при gzip ответах
когда битый файл в кэше лежит, в заголовках в файле кэша указан его не полный размер, а так же сам файл обрезан L]]O?Y]WY]zŘy"5d593f4f-da4"Accept-Encoding¶,܋° OW6ì KEY: server.com/js/1.js?44 HTTP/1.1 200 OK Server: nginx Date: Sun, 18 Aug 2019 13:50:05 GMT Content-Type: application/javascript; charset=UTF-8 Content-Length: 3492 Last-Modified: Sun, 18 Aug 2019 12:06:39 GMT Connection: keep-alive Vary: Accept-Encoding ETag: "5d593f4f-da4" Cache-Control: public, max-age=31536000, stale-while-revalidate=31536000, stale-if-error=31536000 Pragma: cache Accept-Ranges: bytes когда файл целый, в кэше лежит уже полный файл, в заголовках в файле кэша указан полный размер S]]yWY]_Y]õyy"5d595779-dbe"Accept-EncodingѦ@6¡S q5¿N KEY: server.com/js/1.js?45 HTTP/1.1 200 OK Server: nginx Date: Sun, 18 Aug 2019 14:22:02 GMT Content-Type: application/javascript; charset=UTF-8 Content-Length: 3518 Last-Modified: Sun, 18 Aug 2019 13:49:45 GMT Connection: keep-alive Vary: Accept-Encoding ETag: "5d595779-dbe" Cache-Control: public, max-age=31536000, stale-while-revalidate=31536000, stale-if-error=31536000 Pragma: cache Accept-Ranges: bytes Файл без упаковки так и весит, 3518 Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285334#msg-285334 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Битые файлы в кеше при gzip ответах
этот запрос был без gzip, файл каким-то образом nginx был отдан не полностью, с указанием размера 3492 вместо 3518, как это может быть? Файл лежит на диске, Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285335#msg-285335 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Битые файлы в кеше при gzip ответах
chunked_transfer_encoding on; Не может быть причиной? Файл никто не переписывает, лежит и никак не меняется не обновляется, а nginx порой отдает его обрезанным... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285342#msg-285342 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: Битые файлы в кеше при gzip ответах
В общем, более менее разобрался, виноват был open_file_cache, интересная ситуация с ним выходит: у нас есть файл 10 кбайт, мы его запросили единожды и он попал в этот кэш. (если срок жизни кэша большой) Далее файл изменился, стал 15 кбайт и nginx при запросе файла отдает с диска уже измененный файл, НО обрезает его до длины, данные о которой все еще лежат в open_file_cache (10 кбайт) в итоге мы получаем обрезанный / не полный файл на выходе. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,285250,285346#msg-285346 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Nginx reload + Websockets
Добрый день, есть 200k websocket соединений на проксируемый сервер, после изменения в конфиге и попытке reload nginx появляются новые процессы nginx и зависают прошлые в статусе "nginx shutting down", которые так и не завершаются, тк клиенты могут висеть онлайн долго, эти старые процессы можно убить kill -9 pid каждый, но в этом случае nginx продолжает в /nginx_status показывать счетчик коннектов с учетом старых соединений из убитых процессов плюс заново переподключившиеся (количество коннектов после каждого reload растет в геометрической прогрессии), хотя в работе после kill старых nginx процессов остаются только новые процессы. Полностью сбросить счетчик коннектов получается только через restart nginx, но в этом случае все websocket клиенты одновременно начинают заново стучаться на сервер, чего тоже не хотелось бы, вопрос: как мягко применять новый конфиг nginx и переподключать websocket соединения хотя бы пачками, а не все одним моментом? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,291167,291167#msg-291167 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
gunzip для brotli
Добрый день, может быть у кого-нибудь есть модуль, подобный ngx_http_gunzip_module, что бы в proxy_cache хранить полученные с upstream сжатые c brotli ответы и отдавать клиентам без поддержки brotli разархивированные данные? Если кто хочет заняться разработкой подобного - готов стать спонсором для данной разработки. На гитхаб есть начало разработки, но модуль не работает как должен. https://github.com/splitice/ngx_brunzip_module Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293090,293090#msg-293090 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
ipv6=off в upstream
Добрый день, подскажите, почему когда в resolver стоит ipv6=off и в upstream доменное имя с ipv6 и ipv4 то nginx присваивает ему и ipv6 и ipv4 ip адреса, почему ipv6=off в resolver не работает в этом случае? Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293160,293160#msg-293160 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
nginx proxy cache битые файлы
Добрый день, nginx проксирует запросы к удаленному бэкэнду. Удаленный nginx бэкэнд сжимает динамические ответы brotli и отдает через HTTP1.1 chunked_transfer_encoding. Иногда в кэше появляются не полные части файлов. Вопрос: nginx при наступлении proxy_cache_min_uses должен сохранить ответ, НО если ответ был не полным то nginx его все равно сохранит или перезапросит или отложит сохранение до следующего запроса? При разборе кэш файла из proxy_cache директории видно, что он был сжат и отправлялся по chunked_transfer_encoding без указания Content-Lenght. Nginx же по идее должен перед сохранением в кэш удостовериться, что файл получен полностью, с случае если Content-Lenght указан смотреть на полученный размер, если не указан, то ожидать чанка с содержимым "0" Posted at Nginx Forum: https://forum.nginx.org/read.php?21,293246,293246#msg-293246 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: 500-я ошибка при использовании кеша
Полностью согласен с топикстартером, вчера весь день нервы истрепал с поддержкой sucuri, они мне говорят ищи 500 ошибку у себя, я им говорю, что это у вас касячное ПО, пока они не нашли что переполнился keys_zone. И смысл отдавать 500, если кэш не получилось сохранить... только день убитый и куча нервов... Posted at Nginx Forum: https://forum.nginx.org/read.php?21,267328,274422#msg-274422 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru
Re: nginx cache manager process не соблюдает max size размера кеша
Была проблема с включенным http2, после того как выключили, вроде стал держать размер строго. Posted at Nginx Forum: https://forum.nginx.org/read.php?21,274159,274423#msg-274423 ___ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru