mastodon.world is one of the many independent Mastodon servers you can use to participate in the fediverse.
Generic Mastodon server for anyone to use.

Server stats:

8.1K
active users

#haproxy

2 posts1 participant2 posts today

HAProxy в 2025: от TCP до L7 — балансировка без боли

Привет, Habr. Сегодня снова поговорим о прокси — это, пожалуй, моя любимая тема, и я рад вернуться к ней. На этот раз речь пойдёт об универсальном солдате в мире балансировки — HAProxy . Этот инструмент уже много лет остаётся стандартом в высоконагруженных системах, но за последние релизы он стал ещё мощнее и гибче. Напомню, HAProxy ( High Availability Proxy ) — это высокопроизводительный, отказоустойчивый прокси-сервер и балансировщик нагрузки, способный работать как с HTTP(S), так и с TCP-трафиком. Это делает его идеальным решением не только для веб-приложений, но и для баз данных, почтовых систем, брокеров сообщений и других сервисов. В этой статье я разберу последнюю доступную версию — 3.2.3 , расскажу о ключевых изменениях, особенностях конфигурации и поделюсь приёмами, которые помогают выжать из HAProxy максимум. Итак, чем же хорош HAProxy как балансировщик и что интересного появилось в новых версиях?

habr.com/ru/companies/gnivc/ar

ХабрHAProxy в 2025: от TCP до L7 — балансировка без болиПривет, Habr. Сегодня снова поговорим о прокси — это, пожалуй, моя любимая тема, и я рад вернуться к ней. На этот раз речь пойдёт об универсальном солдате в мире балансировки — HAProxy . Этот...

Реализация QUIC протокола через HAProxy

В статье покажу как собрать HAProxy 3.2+ для поддержки полного QUIC не в режиме совместимости, со сборкой OpenSSL 3.5+ с поддержкой QUIC и защитой 0-RTT от replay-атак

habr.com/ru/articles/935888/

ХабрРеализация QUIC протокола через HAProxyВ данной статье покажу как собрать HAProxy для поддержки "правильного" QUIC не в режиме совместимости, со сборкой OpenSSL 3.5 с поддержкой QUIC в дистрибутивах с системным OpenSSL 3.0, с выходом...

Балансировка Exchange Server 2019 и корпоративного портала на одном внешнем IP

Привет, Хабр! На связи Алексей Ежков из из Cloud4Y. Один внешний IPv4, десятки пользователей Exchange и растущий трафик портала — звучит как головоломка? В этой статье я покажу, как мы решили её, заведя всё хозяйство за единственным IP и обеспечив максимальную защиту.

habr.com/ru/companies/cloud4y/

ХабрБалансировка Exchange Server 2019 и корпоративного портала на одном внешнем IPПривет, Хабр! На связи Алексей Ежков из из Cloud4Y. Один внешний IPv4, десятки пользователей Exchange и растущий трафик портала — звучит как головоломка? В этой статье я покажу, как мы решили её,...

Bon, ça fait plusieurs jours que j'essaie de faire marcher let's encrypt avec haproxy et j'y arrive pas
Je suis le tuto dédié : haproxy.com/blog/haproxy-and-l
J'ai donc la config attachée au post (qui ne fait rien d'autre que renvoyer mon thumbprint acme si le chemin demandé contient '/.well-known/acme-challenge')
En http classique ça fonctionne nickel : si je curl sur http://domaine/.well-known/acme-challenge/aeiou il me renvoie aeiou.thumbprint ce qui est ce qu'il faut
Par contre dès que je curl en https j'ai droit à OpenSSL/3.0.13: error:0A000458:SSL routines::tlsv1 unrecognized name
Aidez moi s'il vous plait il fait trop chaud :wtf:
#haproxy #LetsEncrypt

Replied in thread

@dalohuer2004 @lzambrana Muy bueno! No estoy muy al tanto de docker compose, pero se ve bien.

No conocía #traefik, es un load balancer / reverse proxy? Algo similar a #haproxy ?

También veo a #passbolt más para entornos colaborativos, en lo personal sigo con #keepass, que además lo tengo como proveedor de 2FA.

Igual, algunas passwords de mi DB las he tenido que compartir usando keepass (copy paste), pero son poquitas, ya si fueran más algo como passbolt vendría muy bien.

Replied in thread

@jorijn @monospace i did also use nginx and have no hard arguments against it besides "project governance" maybe. but a relevant benefit of using #haproxy in tcp mode is to avoid any double processing of http, which otherwise is prone to desync bugs. tcp mode simply adds/removes the tls pipe, nothing more, nothing less. all the http processing remains in #varnishcache only.

Replied in thread

@jorijn yes, as of today, the recommended way is to use #haproxy as a combined tls onloader/offloader with the PROXY2 protocol such that haproxy has "zero" configuration: see varnish-cache.org/docs/trunk/u and .via in varnish-cache.org/docs/trunk/r
this also works with dns: github.com/nigoroll/libvmod-dy

that said, we will do something about this eventually #varnishcache

varnish-cache.orgBackend servers — Varnish version trunk documentation
Replied in thread
Thank you for all the effort you are putting into this awesome software.

I ran into some weird behaviour of the combination #snac with the official Mastodon app on #iPhone. See attached pic.

The log of my #HAproxy shows

May 12 09:50:20 localhost haproxy[56626]: 46.23.94.142:65241 [12/May/2025:09:50:20.039] FE-https~ BE-social.freebsd.amsterdam/social.freebsd.amsterdam 0/0/0/366/367 200 658007 - - ---- 2/2/0/0/0 0/0 "GET https://social.freebsd.amsterdam/api/v1/timelines/home?limit=100 HTTP/2.0"


CC: @stefano@bsd.cafe @cheeaun@mastodon.social

Neskutečná haluz: Na ssl terminaci používám #haproxy s konfigurací:

frontend https
bind *:443 ssl crt /etc/haproxy/ssl/__fallback.pem crt /etc/haproxy/ssl

kam prostřednictvím skriptu github.com/VitexSoftware/certb

hrnu výslednou kombinaci privkey + fullchain .pem

A co se nestalo, jedna doména jako na potvoru ať jsem dělal co jsem dělal měla sice na disku čerstvý certifikát, ale v #https byl expirovaný ....

Po X hodinách zoufalého laborování, reloadování a restartování a vzniku skriptu github.com/VitexSoftware/certb jsem se nasral a celé to rebootnul ...

A server nejenže potom nabootoval, ale dokonce začal posílat správný certifikát ...

Kde to sakra mohlo být zastydlé, že nepomohl ani stop a start haproxy démona ? To mi hlava nebere :(

filesystém je normální /dev/sda2 on / type ext4 (rw,noatime) - m2 terová karta přes JMS583Gen 2 to PCIe Gen3x2 Bridge do USB a zbytek HW je #RPi5 s 8Gb ram

před rebootem jsem koukal i na výpis dmesg a žádné problémy s filesystémem nebo usb jsem tam neviděl

Dans ce (long et très détaillé) article sur l’état des stacks SSL, l’équipe de #haproxy (confirmée par d’autres équipes telles que Curl, Akamai, Microsoft…) tacle lourdement #OpenSSL sur la qualité du code et surtout sur la gouvernance du projet. Ça pique.
haproxy.com/blog/state-of-ssl-

HAProxy TechnologiesThe State of SSL StacksThe SSL landscape has shifted dramatically. In this paper, we examine OpenSSL 3.x, BoringSSL, LibreSSL, WolfSSL, and AWS-LC with HAProxy.

Long, but great read from #HAProxy on the state of #TLS libraries. Includes some scathing remarks about the #OpenSSL project.

“The development team has degraded their project’s quality, failed to address ongoing issues, and consistently dismissed widespread community requests for even minor improvements.”

“This unfortunate situation considerably hurts QUIC protocol adoption. It even makes it difficult to develop or build test tools to monitor a QUIC server.”

“When some of the project members considered a 32% performance regression ‘pretty near’ the original performance, it signaled to our development team that any meaningful improvement was unlikely.”

“In blunt terms: running OpenSSL 3.0.2 as shipped with Ubuntu 22.04 results in 1/100 of #WolfSSL’s performance on identical hardware! To put this into perspective, you would have to deploy 100 times the number of machines to handle the same traffic, solely because of the underlying SSL library.”

infosec.exchange/@0xabad1dea/1

Infosec Exchangeabadidea (@0xabad1dea@infosec.exchange)After heartbleed in 2014, there were a lot of calls to abandon OpenSSL and support alternative libraries because it had written itself into a corner full of holes. I didn’t anticipate that 11 years later, there’d be a call to abandon OpenSSL because it’s written itself into a corner of running at 1% the performance of those very same alternative libraries https://www.haproxy.com/blog/state-of-ssl-stacks