У меня несколько веб-сайтов (все из которых проходят обратное проксирование через один и тот же сервер), которые не загружаются должным образом на одном из моих компьютеров.
Этот конкретный случай можно воспроизводить каждый раз, когда один файл JS будет оставаться в состоянии «ожидания» в инструменте разработчика Chrome, несмотря на то, что Fiddler показывает, что запрос был выполнен с правильными заголовками и ответом.
Я пробовал следующее:
Когда я пробую другой компьютер, он работает отлично, несмотря на то, что на обоих компьютерах установлены одинаковые расширения браузера и один и тот же антивирус, а также на обоих установлена последняя версия Windows 10.
Если я запускаю Chrome через HTTP Toolkit (программный инструмент для перехвата HTTP-запросов), все работает нормально.
Это заголовки, которыми отвечает сервер (как показано в скрипте):
HTTP/1.1 200 OK
Server: nginx
Date: Sun, 03 May 2020 13:22:52 GMT
Content-Type: application/javascript
Content-Length: 577367
Last-Modified: Wed, 15 Apr 2020 21:18:39 GMT
Connection: keep-alive
ETag: "5e977a2f-8cf57"
Accept-Ranges: bytes
Какие еще шаги я могу попытаться отладить и определить эту проблему?
Этот файл это захват моего ПК, который обменивается данными с моим веб-сервером с помощью wirehark, файл, который не загружается, /js/main.bundle.js?v=2.2.3
Этот файл чистый экспорт хрома
Обобщая результаты обсуждения в виде ответа здесь:
Трассировка Wireshark показывает некоторые повторные передачи на сетевом уровне, но в конечном итоге они успешно передаются по сети. Это не проблема с сетевым подключением.
Копаемся в браузерах Chrome ' chrome://net-export/ logs видно, что браузер даже не считывает заголовки из сети:
t= 69 [st= 7] HTTP_TRANSACTION_SEND_REQUEST_HEADERS --> GET /js/main.bundle.js?v=2.2.3 HTTP/1.1
t= 69 [st= 7] -HTTP_TRANSACTION_SEND_REQUEST
t= 69 [st= 7] +HTTP_TRANSACTION_READ_HEADERS [dt=80452]
t= 69 [st= 7] +HTTP_STREAM_PARSER_READ_HEADERS [dt=80452]
t=80521 [st=80459] CANCELLED
Это означает, что источником проблемы, скорее всего, является перехватывающее (прокси) программное обеспечение в клиентской системе, поскольку сетевой трафик достигает системы, а не приложения. Поскольку OP упоминает Sophos AV, я предположил, что это источник проблемы.
Во время проверки связи процесса с procmon.exe, Sophos может быть идентифицирован как виновник OP.