случайные ошибки SSL на nginx 1.13.8 с сертификатом Let's encrypt

Я использую самкомпилированный nginx / 1.13.8 с дополнительными модулями brotli и headers-more-nginx-module, но моя ошибка возникает независимо от активации brotli или нет. На сервере работает Debian 9. В большинстве случаев все работает, но иногда один или несколько запросов (например, к ресурсам css / js) приводят к следующим ошибкам. Все запросы обслуживаются через http / 2:

chrome : ERR_SPDY_PROTOCOL_ERROR

firefox : загрузка не удалась

safari : kCFErrorDomainCFNetwork-Fehler 303

edge : (то же ошибка, не могу проверить это прямо сейчас; собираюсь обновить это позже)

Моя конфигурация SSL nginx (кажется, нормальная (A +) согласно ssllabs):

ssl_certificate      "/etc/letsencrypt/live/***/fullchain.pem";
ssl_certificate_key  "/etc/letsencrypt/live/***/privkey.pem";
ssl_protocols TLSv1.2;
ssl_dhparam /etc/ssl/dhparam.pem;

ssl_session_cache    shared:SSL:10m;
    ssl_session_timeout  10m;

    #raymii.org/s/tutorials/Strong_SSL_Secruity_On_nginx.html
ssl_ciphers  'EECDH-AESGCM:EDH+ESGCM:AES256+EECDH:AES256+EDH';
    ssl_prefer_server_ciphers  on;

Из-за того, что я новичок в серверах и серверах -management Я понятия не имею, как я могу отладить эту проблему. Все, что я знаю, это то, что ошибка, скорее всего, произошла не с nginx из репозитория debian, но я не уверен.

Я предполагаю, что это как-то связано с шифрами, потому что, поскольку я изменил их с их последнее значение ошибка возникает реже. Server-Log кажется нормальным: например:

**MY-IP** - - [23/Jan/2018:10:33:06 +0100] TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 "GET /portal HTTP/2.0" 200 383 "-" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
**MY-IP** - - [23/Jan/2018:10:33:06 +0100] TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 "GET /styles.a01bb74b47d88d296c44.bundle.css HTTP/2.0" 200 24238 "***" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
**MY-IP** - - [23/Jan/2018:10:33:06 +0100] TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 "GET /inline.bfe190f13378e2257d4e.bundle.js HTTP/2.0" 200 731 "***" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
**MY-IP** - - [23/Jan/2018:10:33:06 +0100] TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 "GET /polyfills.74b809925dee18bd9f89.bundle.js HTTP/2.0" 200 19182 "***" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
**MY-IP** - - [23/Jan/2018:10:33:06 +0100] TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 "GET /scripts.1cd17589767e3c3fbdfe.bundle.js HTTP/2.0" 200 40807 "***" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"

**MY-IP** - - [23/Jan/2018:10:33:06 +0100] TLSv1.2/ECDHE-RSA-AES256-GCM-SHA384 "GET /main.c0a6975cd3e3b14f7b2a.bundle.js HTTP/2.0" 200 0 "***" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.132 Safari/537.36"
--> The one that failed in this case! - looks fine?

Кстати, это происходит на разных устройствах с разными операционными системами.

1
задан 23 January 2018 в 11:52
2 ответа

Думаю, я нашел решение (но я не уверен на 100%!). Как говорится в журнале ошибок (см. Мой комментарий под вопросом), существуют проблемы с отказом в разрешении в / var / lib / nginx / proxy / ** . все каталоги и файлы там принадлежали "none", пока nginx работал как "nginx". Я сменил владельца nginx-процесса на «none», теперь он работает.

В любом случае, как он мог работать в 90% случаев и в 10% случаев падал? На мой взгляд, в разрешении отказано либо постоянно, либо никогда ... но иногда?

0
ответ дан 4 December 2019 в 04:15

Afhangend van die grootte van die lêer wat gevoer word, kan nginx na die skyf gebuffer word.

My raaiskoot is dat die lêers wat misluk groter is as dié wat slaag. Dus, slegs in daardie gevalle, probeer dit om dit te buffer en slaag nie daarin nie.

Wat u kry, is nie SSL-foute nie, maar http / spdy-protokolfoute. Heel waarskynlik omdat die grootte wat in die inhoudsopgawe van inhoud is, nie die bedrag wat oorgedra word, ooreenstem nie. Ek hoop dit beantwoord u vraag waarom dit misluk.

0
ответ дан 4 December 2019 в 04:15

Теги

Похожие вопросы