Возможно что либо превышен предел количества соединений к pgbouncer, либо предел количества соединений к postgres, либо предел выделенных для установки соединения эфемерных портов в ОС с pgbouncer. судя по получаемой циферке у вас есть неплохой шанс, что это проблеме с эфемерными портами. она по идее возникает, если установлению соединения (connect) предшествует привязка (bind) сокета к какому-либо конкретному интерфейсу без использования параметра сокета IP_BIND_ADDRESS_NO_PORT. к сожалению, я не в курсе, действует ли таким образом pgbouncer, но может у вас есть что-то ещё, о чём вы умолчали, например, docker.
dan0sss, с ДДОСом по пропускной способности шейпингом на конечной машине (на той, на которой не хватает пропускной способности) бороться бесполезно. нужно либо расширять канал, либо чтобы шейпинг происходил на одном из предыдущих узлов - на том узле, на котором канал уже достаточно широк.
выглядит как будто вам надо подучить основы докера.
вы говорите "перезапускаю сервер", но по скрину я вижу, что вы не перезапускаете сервер, а делаете новый.
Сергей Кореневский, по моему мнению - да, гавно. даже безотносительно своих прямых характеристик, начиная с того, каким мусорным полумалварьным образом он производит своё продвижение... т. е. он ещё даже не не компе, а уже ведёт себя как гавно.
Во-первых, если у вас на бекенде https, то и в proxy_pass должен быть https, а не http.
Во-вторых, если вы проксируете websocket, то нужно добавить директивы:
Boris009, узнают тестированием, как же ещё.
i3 - это либо i7, который совсем не удался, либо i7, который решили сделать i3, потому что слишком мало i3 и слишком много i7.
Владимир, если нет notify-send и нет прав на его установку, то либо надо получить права у владельца ПК (или администратора ПК), либо ничего не делать, потому что это не ваша машина, а значит и решать, чему там стоять, не вам.