Laravel прерывистая ошибка Bad Gateway 502 и страницы теряют CSS-стилизацию

Некоторые страницы при попытке загрузить я получаю ошибку Bad Gateway Ngnix 502, однако при обновлении страницы это разрешит загрузку страницы. Не уверен, что это связано, однако для одной страницы требуется большой запрос mssql, и страница будет загружена с результатом, но не будет продолжать загружать CSS, связанный с этой страницей.

Файл master.blade.php содержит загрузочный css и стиль темы, extention.blade.php расширяет мастер (как и многие другие страницы в моем проекте), однако он включает в себя запрос к БД, который успешно возвращается, когда dd() не загружается CSS Другие страницы иногда имеют эту проблему, и многократное обновление исправит загрузку страницы.

Надеюсь, кто-то может помочь моей ситуации. Похоже, проблема конфигурации? Просто не уверен..

ОБНОВИТЬ

На всех страницах сначала появляется Bad Gateway 502, за которым следует обновление потери CSS (в основном, при начальной загрузке). Плохой шлюз появится после 2 или 3 обновлений браузера на статических страницах без связи с запросами БД.

Моя настройка:

  • Mac OS X Sierra 10.12.6
  • PHP 7.1
  • Nginx и Laravel 5.6

Настройка www.conf:

  • pm = динамический
  • pm.max_children = 10
  • pm.start_servers = 10
  • pm.min_spare_servers = 10
  • pm.max_spare_servers = 10

~ /.valet/ Nginx / Sites.dev-env (каталог моих проектов, в котором припаркован Valet) имеет следующие строки (добавленные мной, чтобы попытаться решить эту проблему):

`fastcgi_split_path_info ^(.+\.php)(/.+)$;
fastcgi_pass unix:/Users/myusername/.valet/valet.sock;
fastcgi_index 
/Users/myusername/.composer/vendor/laravel/valet/server.php;
include fastcgi_params;
fastcgi_param SCRIPT_FILENAME 
/Users/myusername/.composer/vendor/laravel/valet/server.php;
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;`

Настройка php-fpm.conf:

  • По умолчанию с include=/usr/local/etc/php/7.1/php-fpm.d/*.conf

Laravel Storage имеет набор разрешений 777 (просто чтобы определить, является ли проблема с правами доступа к файлам, это будет возвращено обратно к 755 фтм)

Теперь ключом к решению этой проблемы являются журналы ошибок, которые обеспечивают следующее:

журнал ошибок php:

`[22-Feb-2018 10:29:06 Australia/Sydney] PHP Fatal error:  Uncaught 
PDOException: SQLSTATE[25000]: [FreeTDS][SQL Server]The ROLLBACK 
TRANSACTION request has no corresp$
Stack trace:
0 {main}
  thrown in [no active file] on line 0`

Тем не менее, единственный SQL-запрос, который я связал с этим, - это запрос select, но я не верю, что это является основной причиной плохого шлюза.

~ /.Valet/ Журнал / Nginx-error.log:

`2018/02/22 10:24:23 [error] 62179#0: *9 upstream prematurely closed 
connection while reading response header from upstream, client: 
127.0.0.1, server: sites.dev-env`

Это я считаю главной проблемой. Это происходит в каждой точке ошибки Bad Gateway, и я застреваю, пытаясь понять, что именно это означает. Этот файл журнала имеет массу этих ошибок, очевидно, я пытаюсь выяснить, что. происходит.

Как я могу решить проблему временно, делая перезагрузку камердинера. Перезапуск Brew из nginx или php не решает проблему, поэтому изолируя это для камердинера.

Источник

1 ответ

Я знаю только одну причину, по которой страница может загружаться не с первого места, а с другой. Это о Redirect::back()->withInput(Input::all());

При первой загрузке могут быть некоторые входные данные, при обновлении - никаких входных данных не останется.

Источник

Просто комментируя здесь, как я столкнулся с другим сценарием, который может вызвать это. Обратите внимание, что ответ Евгения также верен, вызывая 502, если нет информации заголовка реферера.

Под нагрузкой я смог определить, что эта база данных особенно сильно пострадала от некоторых плохо выполняющихся запросов. Эти запросы, по-видимому, удерживали нашу базу данных и заставляли веб-сервер работать несколько раз в минуту. Казалось, что PHP-FPM постоянно открывает / закрывает соединения с базой данных - возможно, в результате остановки открытых соединений из-за нагрузки.

В любом случае - как общий ответ на это, борьба за базу данных может привести к тому, что ваш веб-уровень заблокируется и получит ошибку 502. Laravel не дает вам необходимой информации в этом случае, но вы можете проверить свою базу данных, если вы начнете получать периодически возникающие ошибки, подобные этой.

Источник
Другие вопросы по тегам