502 bad getaway

Аватар пользователя batulin batulin 28 января в 14:36

Здравствуйте друзья! Сайт расположен на сервере, но без домена (подключаемся по ip через vpn). Сайт предназначен для учета книг в библиотеке. Я создал пользователя Библиотекарь и дал ему права создавать, редактировать и удалять материалы некоторых типов. Несколько дней он (пользователь) работал - создавал и удалял материалы, но сегодня обнаружилось, что при нажатии на кнопку Редактировать в материале определенного типа появляется ошибка 502. Если кто то сталкивался с подобным, подскажите пожалуйста в чем причина и как бороться. Спасибо.

Комментарии

Аватар пользователя ivnish ivnish 28 января в 14:37

С 502 ошибкой сталкивались все. Но причины могут быть абсолютно разные. Смотрите логи друпала и логи вебсервера. Там всё написано

Аватар пользователя batulin batulin 28 января в 14:58

Спасибо за ответ. Ошибка в логах nginx описана так [error] 219#219: *5812 upstream sent too big header while reading response header from upstream, client: 192.168.1.25, server: lib.loc, request: "GET /node/11037/edit HTTP/1.1", upstream: "fastcgi://unix:/var/run/php/php7.4-fpm.sock:", host: "lib.loc", referrer: "http://lib.loc/node/11037"
Но почему то эта ошибка появляется только у пользователя, который не является админом.

Аватар пользователя batulin batulin 28 января в 15:27

В Отчеты->Последние записи журнала нет ничего нового, то есть после того, как я получаю ошибку.

Аватар пользователя batulin batulin 30 января в 13:00

Андрей спасибо, но у меня другая ситуация - у меня это происходит у всех пользователей кроме администратора и именно при редактировании, создании и удалении материала. Вчера выяснилось, что это связано с темой админки. Хотя раньше эти пользователи могли все это делать и без админки, все делалось в основной теме. Но что то произошло и не работает. Когда ставлю возможность для пользователя просматривать тему администратора, тогда нет никакой ошибки.

Аватар пользователя marassa marassa 31 января в 10:51

batulin wrote: что то произошло и не работает

Никто не сможет телепатически определить что именно произошло, не увидев заголовка ответа, который кладёт nginx. Надо либо разбираться с заголовками, которые вызывают ошибку, либо увеличивать ресурсы сервера. Решения из интернета не ограничиваются увеличением fastcgi_buffer_size, но Вы же не хотите их читать, у Вас же

batulin wrote: другая ситуация

...

Аватар пользователя batulin batulin 31 января в 15:12

Сейчас снова просмотрел и перевел все ответы на данной странице google и кроме увеличения размера буфера ничего не нашел. Возможно что то не понимаю, если подскажете, буду благодарен.

Аватар пользователя marassa marassa 31 января в 15:32

batulin wrote: кроме увеличения размера буфера ничего не нашел

Для начала, там наряду с увеличением fastcgi_buffer_size рекомендуют увеличить еще и fastcgi_buffers. Пробовали? Лично я ничего не знаю о nginx, но если бы Вы хотя бы выложили сюда свою конфигурацию nginx, то у того, кто знает, появился бы какой-то шанс помочь. А по той информации, которую Вы выкладываете, невозможно сделать ничего, кроме как согласиться с тем, что

batulin wrote: что то произошло и не работает.

PS В пол-клика находится целая статья на тему: https://medium.com/@richb_/tweaking-nginx-and-php-fpm-configuration-to-fix-502-bad-gateway-errors-and-optimise-performance-on-17465f41fd87 Читали? Пробовали?

Аватар пользователя bsyomov bsyomov 31 января в 17:00

fastcgi_buffers суммарно должны быть больше fastcgi_buffer_size. Но там другая уже ошибка будет, если это не так.

Вот приложить конфиг идея очень хорошая.

Аватар пользователя bsyomov bsyomov 28 января в 18:17
1

Надо увеличить fastcgi_buffer_size в настройках nginx. По умолчанию он равен 4kb, что вообще довольно не мало для того, чтобы вместить заголовки...

Так что стоит после решения задачи посмотреть, что же там за заголовки такие могучие...

Аватар пользователя batulin batulin 31 января в 9:35

Та же ошибка. Для эксперимента до 128, и перезагрузил. Это происходит у всех пользователей кроме администратора и именно при редактировании, создании и удалении материала. Выяснилось, что это связано с темой админки. Хотя раньше эти пользователи могли все это делать и без админки, все делалось в основной теме. Но что то произошло и не работает. Когда ставлю возможность для пользователя просматривать тему администратора, тогда нет никакой ошибки.

Аватар пользователя bsyomov bsyomov 31 января в 12:36

Какое именно значение в nginx 128к или 128? На всякий случай, без суффиксов оно в байтах.

Т.е. редактировалось раньше в основной теме, а после переключения на редактирование в теме админки появилась проблема? Если да, то это не "случилось". Есть такая настройка и её кто-то изменил.

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

Тема административная какая-то стандартная?

Аватар пользователя batulin batulin 31 января в 14:47

Здравствуйте!
"Т.е. редактировалось раньше в основной теме, а после переключения на редактирование в теме админки появилась проблема?" - нет. До определенного момента пользователь, которому даны права создавать, удалять и редактировать материалы, нажимая на кнопку редактировать, не переходил в админку, но форма редактирования открывалась в основной теме. Теперь же, после "случилось", он может работать только с темой административной, т, е. нужно ставить галочку в правах доступа "Просмотр административной темы".

Аватар пользователя bsyomov bsyomov 31 января в 15:08

Ещё раз. Выбор "редактирование в основной теме" или "редактирование в теме админки" это настройка её можно поменять. Сама по себе она не меняется. Находится тут: /admin/appearance внизу.

Если же смысл сообщения был в том, что "для того чтобы обойти проблему, пришлось переключить редактирование в тему админки", наверное надо было так и написать. Если так, наверняка вносились изменения какие-нибудь в основную тему?

Аватар пользователя batulin batulin 31 января в 15:16

Если же смысл сообщения был в том, что "для того чтобы обойти проблему, пришлось переключить редактирование в тему админки" - Именно так.

Аватар пользователя batulin batulin 31 января в 17:45

/etc/nginx/sites-available/lib.loc

server {

proxy_busy_buffers_size 512k;
proxy_buffers 4 512k;
proxy_buffer_size 256k;

server_name lib.loc;
root /var/www/lib.loc/web;

location = /favicon.ico {
log_not_found off;
access_log off;
}

location = /robots.txt {
allow all;
log_not_found off;
access_log off;
}

# Very rarely should these ever be accessed outside of your lan
location ~* \.(txt|log)$ {
allow 192.168.0.0/16;
deny all;
}

location ~ \..*/.*\.php$ {
return 403;
}

location ~ ^/sites/.*/private/ {
return 403;
}

# Block access to scripts in site files directory
location ~ ^/sites/[^/]+/files/.*\.php$ {
deny all;
}

# Allow "Well-Known URIs" as per RFC 5785
location ~* ^/.well-known/ {
allow all;
}

# Block access to "hidden" files and directories whose names begin with a
# period. This includes directories used by version control systems such
# as Subversion or Git to store control files.
location ~ (^|/)\. {
return 403;
}

location / {
# try_files $uri @rewrite; # For Drupal <= 6
try_files $uri /index.php?$query_string; # For Drupal >= 7
}

location @rewrite {
#rewrite ^/(.*)$ /index.php?q=$1; # For Drupal <= 6
rewrite ^ /index.php; # For Drupal >= 7
}

# Don't allow direct access to PHP files in the vendor directory.
location ~ /vendor/.*\.php$ {
deny all;
return 404;
}

# Protect files and directories from prying eyes.
location ~* \.(engine|inc|install|make|module|profile|po|sh|.*sql|theme|twig|tpl(\.php)?|xtmpl|yml)(~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\.(?!well-known).*|Entries.*|Repository|Root|Tag|Template|composer\.(json|lock)|web\.config)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig|\.save)$ {
deny all;
return 404;
}

# In Drupal 8, we must also match new paths where the '.php' appears in
# the middle, such as update.php/selection. The rule we use is strict,
# and only allows this pattern with the update.php front controller.
# This allows legacy path aliases in the form of
# blog/index.php/legacy-path to continue to route to Drupal nodes. If
# you do not have any paths like that, then you might prefer to use a
# laxer rule, such as:
# location ~ \.php(/|$) {
# The laxer rule will continue to work if Drupal uses this new URL
# pattern with front controllers other than update.php in a future
# release.
location ~ '\.php$|^/update.php' {
fastcgi_split_path_info ^(.+?\.php)(|/.*)$;
# Ensure the php file exists. Mitigates CVE-2019-11043
try_files $fastcgi_script_name =404;
# Security note: If you're running a version of PHP older than the
# latest 5.3, you should have "cgi.fix_pathinfo = 0;" in php.ini.
# See http://serverfault.com/q/627903/94922 for details.
include fastcgi_params;
# Block httpoxy attacks. See https://httpoxy.org/.
fastcgi_param HTTP_PROXY "";
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
fastcgi_param PATH_INFO $fastcgi_path_info;
fastcgi_param QUERY_STRING $query_string;
fastcgi_intercept_errors on;
# PHP 5 socket location.
#fastcgi_pass unix:/var/run/php5-fpm.sock;
# PHP 7 socket location.
fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;
send_timeout 600;
}

location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg)$ {
try_files $uri @rewrite;
expires max;
log_not_found off;
}

# Fighting with Styles? This little gem is amazing.
# location ~ ^/sites/.*/files/imagecache/ { # For Drupal <= 6
location ~ ^/sites/.*/files/styles/ { # For Drupal >= 7
try_files $uri @rewrite;
}

# Handle private files through Drupal. Private file's path can come
# with a language prefix.
location ~ ^(/[a-z\-]+)?/system/files/ { # For Drupal >= 7
try_files $uri /index.php?$query_string;
}

# Enforce clean URLs
# Removes index.php from urls like www.example.com/index.php/my-page --> www.example.com/my-page
# Could be done with 301 for permanent or other redirect codes.
if ($request_uri ~* "^(.*/)index\.php/(.*)") {
return 307 $1$2;
}

}

Аватар пользователя bsyomov bsyomov 31 января в 18:02
1

batulin wrote: proxy_busy_buffers_size 512k;
proxy_buffers 4 512k;
proxy_buffer_size 256k;

Это не те буферы, которые вам нужны. Ну и слишком много.

batulin wrote: proxy_connect_timeout 600;
proxy_send_timeout 600;
proxy_read_timeout 600;

И это не те таймауты, кстати, которые нужно тут использовать. Ну и в целом это очень большие значения, так делать не стоит.

У вас используется fast cgi, а не reverse proxy. Соответственно нужны fastcgi_buffer_size, fastcgi_buffes и.т.п.