Possible unintended behaviour when multiple front-ends use same address:port combination
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 45/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- c
- Bereich
- networking
Rechercherichtung
Start by reading the existing bind-conflict handling in src/cfgparse.c, where listener addresses are parsed and registered, and check whether an address:port comparison already exists for the -dM / zero-warning paths. Confirm the intended behaviour with the maintainers first, since the thread debates warning versus refusing to start; the wording in doc/configuration.txt about each address:port being used once should be updated alongside. Done looks like a startup warning (or error) for duplicate address:port across frontends, covered by a reg-test.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Detailed Description of the Problem
I am fairly new to HAProxy, so you might have to bear with me here. The docs include the following:
"Also, each address:port couple must be used only once among all instances running on a same system."
Unaware of the above and misunderstanding the config examples, I initially configured a HAProxy instance with multiple front-ends using the same address:port combination - thinking that the SNI selection would take care of magically routing the traffic. This has actually worked for months now - but with intermittent SSL problems for the client end. After spending days trying to narrow down the cause of the SSL errors, I finally realised that HAProxy was intermittently sending connections to the wrong back-end (because connections were hitting the wrong front-end in the first place) - which was serving up the wrong / unexpected SSL certificate.
The above would have been avoided if I read and better understood the HAProxy documentation. But I feel that it would be really helpful if HAProxy would either refuse to start if the same address:port combo is used multiple times - or at least issue a warning along the lines of dire and unintended consequences might follow if one continues.
I am on HAProxy 3.4.3
Expected Behavior
Issue warning or refuse to start if same address:IP combination is used multiple times in config file
Steps to Reproduce the Behavior
Configure multiple front-ends (linked to different back-ends) using the same address:port
Do you have any idea what may have caused this?
No response
Do you have an idea how to solve the issue?
No response
What is your configuration?
global
default-path config
zero-warning
chroot /var/lib/haproxy
user haproxy
group haproxy
daemon
pidfile /var/run/haproxy.pid
hard-stop-after 10m
defaults http
timeout client 30m
timeout server 30m
timeout tunnel 1h
timeout connect 15s
timeout queue 1m
frontend fe_https_dom1.mydomain.com
bind 0.0.0.0:443
mode tcp
tcp-request inspect-delay 10s
tcp-request content accept if { req_ssl_hello_type 1 }
use_backend be_https_dom1.mydomain.com if { req.ssl_sni -i dom1.mydomain.com }
frontend fe_https_dom2.mydomain.com
bind 0.0.0.0:443
mode tcp
tcp-request inspect-delay 10s
tcp-request content accept if { req_ssl_hello_type 1 }
use_backend be_https_dom2.mydomain.com if { req.ssl_sni -i dom2.mydomain.com }
backend be_https_dom1.mydomain.com
mode tcp
server s1 192.168.15.61:443 check
backend be_https_dom2.mydomain.com
mode tcp
server s1 192.168.15.62:443 check
Output of haproxy -vv
haproxy -vv
HAProxy version 3.4.3-80ea565fd 2026/07/29 - https://haproxy.org/
Status: long-term supported branch - will stop receiving fixes around Q2 2031.
Known bugs: http://www.haproxy.org/bugs/bugs-3.4.3.html
Running on: Linux 6.12.29 #1 SMP PREEMPT_DYNAMIC Sun May 18 15:34:31 CDT 2025 x86_64
Build options :
TARGET = linux-glibc
CC = cc
CFLAGS = -O2 -g -fwrapv -fvect-cost-model=very-cheap
OPTIONS = USE_ENGINE=1 USE_OPENSSL=1 USE_LUA= USE_ZLIB=1 USE_NS=1 USE_QUIC= USE_PROMEX=1 USE_PCRE2=1
DEBUG =
Feature list : -51DEGREES +ACCEPT4 +ACME +BACKTRACE -CLOSEFROM +CPU_AFFINITY +CRYPT_H -DEVICEATLAS +DL -ECH +ENGINE +EPOLL -EVPORTS +GETADDRINFO +HAVE_TCP_MD5SIG -KQUEUE +KTLS -LIBATOMIC +LIBCRYPT +LINUX_CAP +LINUX_SPLICE +LINUX_TPROXY -LUA -MATH -MEMORY_PROFILING +NETFILTER +NS -OBSOLETE_LINKER +OPENSSL -OPENSSL_AWSLC -OPENSSL_WOLFSSL -OT -PCRE +PCRE2 -PCRE2_JIT -PCRE_JIT +POLL +PRCTL -PROCCTL +PROMEX -PTHREAD_EMULATION -QUIC -QUIC_OPENSSL_COMPAT +RT +SHM_OPEN -SLZ +SSL -STATIC_PCRE -STATIC_PCRE2 +TFO +THREAD +THREAD_DUMP +TPROXY +TRACE -WURFL +ZLIB
Detected feature list : +HAVE_WORKING_TCP_MD5SIG
Default settings :
bufsize = 16384, maxrewrite = 1024, maxpollevents = 200
Built with multi-threading support (MAX_TGROUPS=32, MAX_THREADS=1024, default=16).
Built with SSL library version : OpenSSL 3.5.0 8 Apr 2025
Running on SSL library version : OpenSSL 3.5.0 8 Apr 2025
SSL library supports TLS extensions : yes
SSL library supports SNI : yes
SSL library default verify directory : /etc/ssl/certs
SSL library supports : SSLv3 TLSv1.0 TLSv1.1 TLSv1.2 TLSv1.3
OpenSSL providers loaded : default
Built with the Prometheus exporter as a service
Built with network namespace support.
Built with zlib version : 1.3.1
Running on zlib version : 1.3.1
Compression algorithms supported : identity("identity"), deflate("deflate"), raw-deflate("deflate"), gzip("gzip")
Built with transparent proxy support using: IP_TRANSPARENT IPV6_TRANSPARENT IP_FREEBIND
Built with PCRE2 version : 10.45 2025-02-05
PCRE2 library supports JIT : no (USE_PCRE2_JIT not set)
Encrypted password support via crypt(3): yes
Built with gcc compiler version 14.2.0
Available polling systems :
epoll : pref=300, test result OK
poll : pref=200, test result OK
select : pref=150, test result OK
Total: 3 (3 usable), will use epoll.
Available multiplexer protocols :
(protocols marked as <default> cannot be specified using 'proto' keyword)
h2 : mode=HTTP side=FE|BE mux=H2 flags=HTX|HOL_RISK|NO_UPG
<default> : mode=HTTP side=FE|BE mux=H1 flags=HTX
h1 : mode=HTTP side=FE|BE mux=H1 flags=HTX|NO_UPG
fcgi : mode=HTTP side=BE mux=FCGI flags=HTX|HOL_RISK|NO_UPG
<default> : mode=SPOP side=BE mux=SPOP flags=HOL_RISK|NO_UPG
spop : mode=SPOP side=BE mux=SPOP flags=HOL_RISK|NO_UPG
<default> : mode=TCP side=FE|BE mux=PASS flags=
none : mode=TCP side=FE|BE mux=PASS flags=NO_UPG
Available services : prometheus-exporter
Available filters :
[BWLIM] bwlim-in
[BWLIM] bwlim-out
[CACHE] cache
[COMP] comp-req
[COMP] comp-res
[COMP] compression
[FCGI] fcgi-app
[SPOE] spoe
[TRACE] trace
Last Outputs and Backtraces
Additional Information
No response
- Vorherrschende Sprache
- C
- Sterne
- 6.9k
- Forks
- 976
- PR-Merge-Kennzahlen
- Keine gemergten PRs in 30 T.
Entwicklungsumgebung
Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus haproxy/haproxy
-
type: feature
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 77/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
-
type: code-report
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 74/100
-
type: code-report
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 82/100
Alle Issues in haproxy/haproxy
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
DaveGamble/cJSON#1100 ·
-
UB: (int) cast of a user double outside int range in dispatch / vm_index_is_int / flat_index_atOffenarea:runtime-vm
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
InauguralSystems/EigenScript#1748 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
leanprover/lean4#15677 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 2 Tagen
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
wasm-micro-runtime/wasm-micro-runtime#5159 ·
Maintainer antworten meist innerhalb von 7 Tagen