> Hi Baptiste,
>
> I'll try your suggestiion, but I'd like to understand why if I enable
> tcp_timestamp I have no problems and if I disable it, after few
> minutes on the live system I get the problem.
Clearly this is a kernel issue. Check your kernel logs/dmesg.
Lukas
> On Wed, Oct 21, 2015 at 7:14 PM, SL wrote:
>> I'll be doing an upgrade from 1.4 to 1.6 tomorrow. Just wondering if there
>> are any changed defaults, breaking changes, anything like that? Or should
>> my config work as before?
>
> Haproxy 1.5 changed the default connection
Hi Robin,
> Hey guys,
>
> Actually when you get an NXDOMAIN reply you can just stop resolving that
> domain. Basically there are 2 types of "negative" replies in DNS:
>
> NODATA: basically this is when you don't get an error (NOERROR in dig),
> but not the actual data you are looking for. You
> Dear Willy,
>
> Thank you for your insights. As you advised, below is the output of
> haproxy -f …cfg -db -V.
Can you run this through strace (strace haproxy -f …cfg -db -V) and
provide the output.
Also, if you have the strace output of a successful startup of 1.5.14 for
comparison, that would
> Hi Andrew,
>
> On Mon, Oct 19, 2015 at 05:39:58PM -0500, Andrew Hayworth wrote:
>> The ANY query type is weird, and some resolvers don't 'do the legwork'
>> of resolving useful things like CNAMEs. Given that upstream resolver
>> behavior is not always under the control of the HAProxy
> I don't know. I'm always only focused on the combination of user-visible
> changes and risks of bugs (which are user-visible changes btw). So if we
> can do it without breaking too much code, then it can be backported. What
> we have now is something which is apparently insufficient to some
Hi,
>> A simple option in the resolvers section to instruct HAPoxy to not
>> forgive on NX and failover to next family:
>> option on-nx-try-next-family
>
> I personally find this confusing from the user's point of view.
Agreed, we should have good and safe defaults, and address corner
cases
> when using ipsec on the backend side, this error pops up in the haproxy
> log from time to time:
>
> Layer4 connection problem, info: "General socket error (No buffer space
> available)
>
>
> we have tried both strongswan and libreswan, error is still the same.
> there is nothing strange
> So you may be right on the two certs on the same line bug. Just removed
> one of the certs and so far, so good. Can you verify?
Are both or one of them (first or second one) wildcard certificates?
Thanks,
Lukas
Hi folks,
> Hey guys,
>
> by default, HAProxy tries to resolve server IPs using an ANY query
> type, then fails over to resolve-prefer type, then to "remaining"
> type.
> So ANY -> A -> or ANY -> -> A.
We can't really rely on ANY queries, no. Also see [1], [2].
> Today, 0yvind
> Jan, a fellow HAProxy user, already reported me that ANY query types
> are less and less fashion (for many reasons I'm not going to develop
> here).
>
> Amongs the many way to fix this issue, the one below has my preference:
> A new resolvers section directive (flag in that case) which prevent
>
Hi Øyvind,
> Hi,
>
> When testing the 1.6.0 release we encountered a segfault bug on the
> server when trying to run the https://www.ssllabs.com/ssltest/ test on
> our two sites running with two different SSL certs. The test runs fine
> when its run against one of the sites / certificates, but
Hi,
>> If the session is transferring HTTP body between client and backend server,
>> we
>> can't insert HTTP headers either. If you are waiting for the next request
>> in that particular session, why wouldn't we just close it after the HTTP body
>> has been transfered?
>
> That would be fine,
Hi David,
> I just want to say first of all that haproxy is incredibly useful and
> I've enjoyed working with it tremendously. Thank you!
>
> My question is if a server is disabled because of a failed http health
> check and there are requests in flight, will the requests from the
> disabled app
> From my reading of the code SIGUSR1 does not send a "Connection: close" to the
> client or server. This means it is not possible to safely close a keep-alive
> session, before terminating HAProxy.
>
> Would there be interest in a patch to send "Connection: close" on both the
> request and the
> I second this opinion. Removing ANY altogether would be the best case.
>
> In reality, I think it should use the OS's resolver libraries which
> in turn will honor whatever the admin has configured for preference
> order at the base OS level.
>
>
> As a sysadmin, one should reasonably expect
> On Thu, Oct 15, 2015 at 12:26 PM, Lukas Tribus <luky...@hotmail.com> wrote:
>> What request/response, aren't we talking about an idle session here?
>
> No, I am concerned with a non idle persistent session.
When specifically would you intervene? Could you elaborate
Hi Julien,
> Still, I would like to take a look at the patch and get it fixed properly.
Your patch works for me if I only apply the one-line change at
"version = (data[9] << 16) + data[10];"
Can you confirm that this works for you as well and resubmit it
for inclusion?
Thanks,
Lukas
>> jve.linuxwall.info as SNI value? I suggest to remove the
>> SNI if statement while testing the TLS ACL.
>
> Argh... I can't count the number of times forgetting -servername in
> openssl s_client got me looking for a bug. This one included.
>
> "acl tls12 req.payload(9,2) -m bin 0303" works as
> acl allowed_clients hdr_sub(X-Real-IP) 10.10.200.0/24 [...]
This is a *string* comparison. You will have to use "req.hdr_ip" [1]:
acl allowed_clients req.hdr_ip(X-Real-IP,-1) 10.10.200.0/24 [...]
Regards,
Lukas
[1]
> Attached is a patch that should work but doesn't. (bare with me, I'm in
> unknown codebase territory here).
>
> I also tried to match directly using req.payload, and I can't get the
> ACL to match:
> acl tls12 req.payload(9,2) -m bin 0303
"req.payload(9,2) -m bin 0303" is imho correct, this
> frontend https-in
> bind 0.0.0.0:443
> mode tcp
> tcp-request inspect-delay 5s
> tcp-request content accept if { req_ssl_hello_type 1 }
>
> acl sni_jve req.ssl_sni -i jve.linuxwall.info
> acl tls12 req.payload(9,2) -m bin 0303
> acl sslv3 req_ssl_ver 3.0
>
> use_backend jve_https if sni_jve
> Hi!
>
> I'd like to report a bug I do experience,
> maybe I'm not the first one to report it:
> it's about IP network ranges and acl in haproxy (1.5.8).
> It's working… sometimes.
> I have no issue with ranges like /24 (like 10.10.200.0/24)
> But it is not working with a range like /22 ; /28 ;
Hi Diana,
> Hello,
>
> I have two hosts, one has haproxy 1.4.22 installed and the other has
> haproxy 1.5.14 installed.
> The following rewrite config works as expected in 1.5.14, but not in v1.4.22:
You probably want to check whether both 1.4.22 and 1.5.14 executables
have been build
Hi Mildis,
>> And regarding "2001:db8::1234", you can't forbit it simply because you
>> don't know if 1234 is a port or not in this context, as you have
>> reported.
>
> Sure. In this very specific case 1234 can’t be a port as 2001:db8:: is
> then a subnet.
For the record: you can't know that,
Hi Julien,
>> Maybe you can also try with "curl --tlsv1.2" which should use a 3.3
>> version.
>
> That's a very interesting details. Indeed curl sets the HELLO version to
> 0x0303
> whereas OpenSSL uses 0x0301. Interestingly, both Firefox and Chrome also
> use 0x0301
> in the version of the
Hello,
The flag TCP_NODELAY is unconditionally set on each TCP (ipv4/ipv6)
connections between haproxy and the server, and beetwen the client and
haproxy.
That may be true, however HAProxy uses MSG_MORE to disable and
enable Nagle based on the individual situation.
Use option http-no-delay
Use option http-no-delay [1] to disable Nagle unconditionally.
This option requires HTTP mode, but I must use TCP mode because our
protocol is not HTTP (some custom protocol over TCP)
Ok, you may be hitting a bug. Can you provide haproxy -vv output?
Thanks,
Lukas
Ok, you may be hitting a bug. Can you provide haproxy -vv output?
What do you mean? I get the following warning when trying to use this
option in tcp backend/frontend:
Yes I know (I didn't realize you are using tcp mode). I don't mean the
warning is the bug, I mean the tcp mode is supposed
ilan@ilan-laptop$echo show errors | sudo socat
/run/haproxy/admin.sock stdio
Total events captured on [19/Aug/2015:15:36:43.378] : 3
[19/Aug/2015:15:36:18.452] backend nodes (#4): invalid response
frontend localnodes (#2), server web01 (#1), event #2
src
yes. Sorry about that. I was changing my configuration and forgot to
rollback some of the changes. But even after removing, ssl verify
none, the problem is still there.
You will have to look at those specific request that don't work. (like
a CSS file), try what happens when you request them
Hi Roman,
I am publishing horde webmail application. The horde itself is served
internally via http protocol on apache.
I suspect the error is that you are enabling SSL on the backend servers
towards port 80? Remove ssl verify none from the backend
server configurations.
Lukas
Hi Baptiste,
Thank you very much for the response.That was quick.
I tired enabling but got following error,
Looks like you're on haproxy 1.4. In your current configuration you are
now using tunnel-mode.
If this is a new deployment, I would recommend upgrading to haproxy
1.5.
Regards,
Hi,
I spent more time debugging the problem.
Here¹s the source snippet from 1.5.2 version of haproxy
(I believe the latest 1.5.14 has the same issue).
This is fixed by commit 8068b03467 (BUG/MINOR: ssl: correctly
initialize ssl ctx for invalid certificates) [1], which is in
Haproxy 1.5.7 and
Hi Lukas,
I made a mistake in my previous email : it works locally AND remotely !
What fixed the problem? This may be useful for others as well.
Lukas
Hi Lukas,
frontend cluster:443
bind 1.2.3.4:443 ssl strict-sni crt /home/provisionning/0.pem crt
/home/provisionning/cluster.d
default_backend cluster
capture request header Host len 255
Can you confirm there is no SSL intercepting device in front of the webserver,
like
hardware
Hi Marc,
Hi Lukas,
great intuition :)
---
CONNECTED(0003)
TLS server extension server name (id=0), len=0
TLS server extension renegotiation info (id=65281), len=1
0001 - SPACES/NULS
TLS server extension EC point formats (id=11), len=4
- 03 00 01 02
TLS server extension
Hi Marc,
Hi all,
I have some problem making ocsp stapling working. here is what i did :
I have 8150.pem with chain, cert and key in it.
I have 8150.pem.ocsp that seems ok :
# openssl ocsp -respin 8150.pem.ocsp -text -CAfile alphassl256.chain
OCSP Response Data:
OCSP Response Status:
Hey guys,
I haven’t gotten any feedback for this feature. Unless there’s severe
objections, I’ll go ahead and push this to up to master.
Emeric responded here:
http://marc.info/?l=haproxym=143643724320705w=2
Not sure what you mean by pushing this to master...?
Lukas
Hi Lukas,
the output of haproxy -c is not helpful.
Configuration file is valid“
I though thats what you want.
I need a more verbose output with a complete overview of the configuration.
I want to check if options configured in the default or global sections
works for all the
Hi Erik,
Hi,
is it possible to show and test the configuration of haproxy
like apache2ctl -S?
I want to check with which configuration options haproxy starts.
Thanks for help.
Yes, see haproxy -h (haproxy -c).
Lukas
Hi Tomas,
Hello,
we have a server with some config running an old version (1.4.25-1) of
haproxy under Debian wheezy. The reason we've not updated it is that any
new versions we had access to would crash.
Today I was able to pinpoint where the problem lies:
Thanks for the detailed repro.
The deprecated req_ssl_* keywords were for compatibility with historic
versions
and should not be introduced right now, so I'd rather not add it now to
remove
it in next version. If you're OK with me removing it by hand I can fix it
myself, but if you prefer to resubmit that's fine as
Hi Alexander,
Hello!
My name is Alexander and I am writing on behalf of OWOX company, that
supports the most visited Ecommerce website in Ukraine
(rozetka.com.uahttp://rozetka.com.ua).
We are using haproxy as a well-performance server to balance load
between our database servers.
Hi,
Hi there,
I'm running haproxy 1.5.12 and I have set 'ssl-default-bind-options
no-sslv3 no-tlsv10' (without the quotes of course) under the global
section as I want all my front-ends not to support SSLv3 or TLS1.0.
However I do have a client that still requires SSLv3 support (for
Hi, just to let you know changelog is missing 1.5.14 infos ;)
Its there, its probably just cached in your browser (try ctrl+shift+R).
Lukas
Thanks Lukas,
So its either SSLv3 is enable for all, or its disable for all?
No, you can disable it per bind line, only that you need to
do it the other way around, specifying no-sslv3 on all other
bind lines, not the one where you need sslv3 (and not in the
defaults).
Lukas
That should have read:
The capture shows that there is *no* SNI emitted by the client. I think your
node.js SNI tests was bogus, and that curl doesn't properly support SNI
*if* the crypto library is SecureTransport instead of openssl, gnutls or
cyassl.
Yep, it's OS X curl.
curl 7.37.1 (x86_64-apple-darwin14.0) libcurl/7.37.1
SecureTransport zlib/1.2.5
Protocols: dict file ftp ftps gopher http https imap imaps ldap
ldaps pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS GSS-Negotiate IPv6 Largefile NTLM NTLM_WB SSL libz
sudo tcpdump -ps0 -i eth0 -w eth0.64443.cap tcp port 64443
And then this on my Yosemite Mac
curl
--insecure https://baz.example.com:64443https://baz.example.com:64443/
And here's the result
The capture shows that there is now SNI emitted by the client. I think your
oops, I still had the link to the pastebinit, which doesn't work on
binary files.
https://dropsha.re/files/orange-hound-85/64443-traffic.default.cap
https://dropsha.re/files/angry-dragon-19/64443-traffic.baz.cap
Looks alright. Can you configure logging and check the result:
global
But when I use curl bundled with Yosemite (or from Brew) on my macbook,
it's not switching.
curl --insecure https://bar.example.com:64443
Default on 1443
These are the versions I'm testing with:
curl --version
curl 7.37.1 (x86_64-apple-darwin14.0) libcurl/7.37.1
To limit verbosity I just captured one full request where it succeeded
and then another when it didn't
# this is the one that worked as expected
pastebinit dump.1.tls.bin
http://paste.ubuntu.com/11811750/
# this is the one that went to default anyway
sudo haproxy -db -f /etc/haproxy/haproxy.cfg
Backend IPs are 0.0.0.0. Thats probably not what you want.
Should be 127.0.0.1 if I understand correctly.
I've edited /etc/hosts so that baz.example.comhttp://baz.example.com
points to 127.0.0.1
I've created a few bogus servers
Thank you for pointing this out, I missed it in my brief look of the code.
To me, this is reason enough to move to 1.0.2 (in addition to all the
other reasons given by you and Nenad).
I¹ll start prototyping the code using 1.0.2.
Agreed.
What I would also urge is to not use any openssl
This line in the userlist will cause the segfault when you try to view
stats as the user test:
user test password =testing
The segfault error from messages is:
Jun 25 21:33:41 dev-tsl-haproxy-001 kernel: [ 4147.107578]
haproxy[6780]: segfault at 0 ip 7f6ae5fcfef6
Hi Vinod,
First, good luck in your PhD.
For load-balancing algorithm, you want to read this part of the doc:
http://cbonte.github.io/haproxy-dconv/snapshot/configuration-1.6.html#balance
about the source code, it's available here:
http://git.haproxy.org/?p=haproxy.git
Also checkout
Currently, I?ve coded it so that this only happens when the client does not
specify an SNI, but I?m looking for guidance on what you would consider to be
the best solution. This approach can certainly be taken to be compatible with
SNI.
Is this something that you would be interested in
Hey Willy,
Lukas explained it pretty well, but I can expound on it some more.
You can imagine a situation where HAProxy has 2 certificates of different
key types; one ECDSA and one RSA. In the current codebase, if no SNI is
used, the certificate that is used will be whichever certificate is
Hi Phil,
Hello all:
we are rolling out a new system and are testing the SSL performance with
some strange results. This is all being performed on a cloud hypervisor
instance with the following:
You are saying nginx listens on 443 (SSL) and 80, and you connect to those
ports directly from
Hi Brendan,
Hi I am having an issue with HAProxy in http-server-close mode, when more
then one request is sent in a stream and one timeouts after a success it
re-sends that request. On the second request HAProxy send the 504 and the
request is not resent again.
I'm sorry, I don't really get
Hi Brian,
Thanks for your suggestion. Unfortunately it's not clear how I would
use this command and format it when doing a redirect. I read the
HAProxy 1.5 documentation, but it wasn't detailed enough.
You don't want a redirect, you explicitly asked for a rewrite:
retaining original domain
Subject: Does haproxy use lt or et mode of epoll ?
thanks
Level-triggered, if I understand the following commit correctly:
http://www.haproxy.org/git?p=haproxy.git;a=commit;h=6c11bd2f89eb043fd493d77b784198e90e0a01b2
Lukas
Hi Atul,
Hi,
using a browser to query the stats from haproxy, I'm facing a non
consistent behavior where about One time every 2 attempts I get a 503
error.
Can you please let me know how to correct this.
Can you provide configuration and logs of the failed request?
Lukas
Hi!
Hello,
I’m trying to determine how to redirect from an incoming domain
(alias.com) to another domain (domain.com), yet retain the original
incoming domain (alias.com) in the user’s browser URL address bar. I
believe I need to use “http-request replace-header”, but not sure how
Hi,
Hi Lukas
We are getting following warning while running haproxy after migration
from
[WARNING] 163/012854 (8453) : Setting tune.ssl.default-dh-param to 1024
by default, if your workload permits it you should set it to at least
2048. Please set a value= 1024 to make this warning
Hi Jeff,
504's are killing us and we have no clue why we get them
Here's a sample log entry:
Jun 10 17:27:33 localhost haproxy[23508]: 10.126.160.11:37139
[10/Jun/2015:17:26:03.027] http-in resub-bb-default/njorch0pe16
30935/0/1/-1/90937 504 194 - - sH-- 16/14/0/0/0 0/0
Hi!
Hi everyone,
It seems that since some times haproxy 1.6 segfault on freebsd
Eg: at commit 80b59eb0d20245b4040f8ee0baae0d36b6c446b5
I can't find that commit? Where are you pulling/cloning from?
Lukas
Hi Devendra,
Hi Lukas,
Thanks For your valuable reply.
Please find attach config file of current HAProxy server.
Please let me know , whether i should upgrade my server with latest
stable version of HA Proxy.
Need your suggestion.
Hi Lukas,
This is the last commit available on github for haproxy/haproxy
https://github.com/haproxy/haproxy/commit/80b59eb0d20245b4040f8ee0baae0d36b6c446b5
That is a unofficial mirror, updated manually and often
outdated (like right now).
Please clone from the official mirror at:
Bump. Turns out a bunch of scripts/programs hit my sites that don't do
SNI. Any ideas?
Virtual HTTPS hosting needs SNI. If your clients/script doesn't support SNI,
you cannot host more than one certificate with one IP.
Doesn't have anything todo with SPDY or Haproxy, its just how things are.
HI team,
I need your help in upgrading my HA-Proxy version from
haproxy-1.5-dev21 to latest Stable version.
Can i upgrade directly or i have to change any settings..
That depends on your configuration and on what you
expect from HAProxy.
Without any further informations I would say
A stupid question:
Does SPDY require to use SNI on client side?
SPDY requires NPN or ALPN. I'm not sure if the SPDY specification
insist on SNI, but basically all SPDY clients also support SNI.
This is imo a non-problem.
If not, what does it happen if the client doesn't send any SNI
Also more importantly, can I use proxy protocol with TCP backends? I
need TCP backends to support SPDY.
Yes, thats exactly the point of the proxy protocol.
Lukas
Hi Viranch,
tcp-request inspect-delay 5s
tcp-request content accept if HTTP
Whats that configuration supposed to do? It doesn't
make any sense.
acl spdy ssl_fc_npn -i spdy/3.1
acl site1 req.hdr(Host) -i site1.foo.com
acl site2 req.hdr(Host) -i site2.foo.com
use_backend site1_spdy if
Hi Lukas, thank you for the time !
I compiled haproxy with DEFINE=-DREQURI_LEN=8192 and everything
seems to be fine now, recompiling is not a problem.
Tomorrow I'll deploy the changes from staging to production and let
you know, we have around 1200 queries per second and the process takes
Hi Damiano,
Dear all, an update: logging using sockets doesn't change anything.
After some grepping the code and tinkering I found that changing REQURI_LEN
in include/common/defaults.h does the job
Thanks for your analysis.
the strange thing is that there's also #define MAX_SYSLOG_LEN
Hi Lukas, my mtu is set to 1500 and the message looks truncated.
I am able to ping the server using that mtu
root@lbha01:~# ping -s 1500 syslog
-s 1472 -M do is what you would use for this test. Instead, you are sending
ICMP requests at 1528 Bytes MTU without DF bit, so it will get
Hi Damiano,
Even if I set 8192 as length the message gets truncated after 1024
chars, we use syslog-ng and configured it to accept a ridiculously huge
length (log_msg_size(262144) defined in /etc/syslog-ng.conf), I also
tried using the logger utility to check if the message gets delivered
Hi Shawn,
I've done a Qualys Labs SSL test against my setup fronted with haproxy,
using this URL:
https://www.ssllabs.com/ssltest/index.html
I thought I had OCSP stapling correctly configured, but Qualys says it's
not there. I ave a cronjob that uses openssl to retrieve the .ocsp file
Hi Willy,
Thank you, that was pretty clear and easy. I checked that I was running
with about 2 kb of entropy before the tests and that I was alone on the
machine, so I'm confident that what I did wasn't skewed.
I pushed this into 1.6. I'd rather issue -dev2 with it, wait a little bit
then
On Tuesday, May 26, 2015 5:12 PM Remi Gacogne wrote:
On 05/23/2015 08:47 AM, Willy Tarreau wrote:
Do you have any idea about the ratio of clients (on the net) which don't
support ECDHE right now but support DHE ?
Basically, by totally removing DHE, we would be losing forward secrecy for:
-
If your refer to long EOL'ed system, then they probably don't support DHE at
all.
Alas EOL'ed systems doesn't hinder its use - even if it unwise..
Thats not what I'm saying. What I'm saying is that since they are so old they
don't
even support DHE, therefor the dh group doesn't matter.
Hi the list
In my backend I've many servers, and I'd like to add some that receive
a copy of all the requests arriving to the backend. Of course haproxy
won't reply to them after sending the request.
I don't find any option for 'server' in section 5 of the docs, that
will allow me to
Honestly, I'm opting for removing the DH fallback in haproxy altogether and
simple always warn when the certificate (or a dedicated DH file parameter
like
nginx does, which was requested earlier this week and makes sense) does not
have the DH parameters.
I'm having a mixed opinion here.
OK so now we need to find what to do in the end. From what I understood,
just removing the lines was a test and is not viable because we'll always
emit the warning, right ?
Honestly, I'm opting for removing the DH fallback in haproxy altogether and
simple always warn when the certificate (or a
Hi,
my current traffic flow with source 0.0.0.0 usesrc clientip and with
source publichaproxyip usesrc clientip:
haproxy receives a SYN from the client and does a normal tcp handshake
which works fine. Additionally haproxy forwards the SYN to the backend
with the client ip as source ip,
So think that somehow, 1.5 was creating or keeping a lot more open
connections at a time, and depriving the kernel, or its own limits of
available connections?
Not necessarly the kernel itself. Some stateful inspection firewall between
the proxy and the backend, this includes conntrack on
yes i figured since it is a ubuntu 10.04 machine it has old version of
openssl
so i looked around for upgrading the openssl and found this link
https://sandilands.info/sgordon/upgrade-latest-version-openssl-on-ubuntu
so can i just upgrade to openssl 1.0.1 and add it to the correct
so it is not possible to let haproxy answer backend packets to client ips?
I don't know what this question is supposed to mean, I don't get it.
You can use the source ip of your syslog clients to connect to your backend
by using plain old tproxy, this has been done for years and works fine.
hi all,
I'm working on standing up a new haproxy instance to manage redis
directly on our redis hosts since our main load-balancer does periodic
reloads and restarts for things like OCSP stapling that good ol'
amnesiac HTTP handles just fine, but longer-lived TCP connections like
listen logstash01
bind 10.111.2.249:514 ssl ca-file /etc/haproxy/ca.pem crt
/etc/haproxy/logstash.pem verify required crl-file /etc/haproxy/crl.pem
ciphers
in my opinion I do not need a transparent proxy. my rsyslog nodes
directly connect to an ip address which is configured on the haproxy
server. So I don't need non_local_bind and no tproxy?
Mmh, I'm not sure. Try:
source usesrc clientip
Where is the real IP from HAproxy. That way tproxy4 is
in my opinion I do not need a transparent proxy. my rsyslog nodes
directly connect to an ip address which is configured on the haproxy
server. So I don't need non_local_bind and no tproxy?
(previous mail got messed up, sorry about that)
Mmh, I'm not sure. Try:
source usesrc clientip Where is
Mmh, I'm not sure. Try:
source usesrc clientip Where is the real IP from HAproxy.
Just realized that the config is still messed up.
This should have been:
source haproxyip usesrc clientip
where haproxyip is the real IP from HAproxy.
Hi David,
Hi!
HAProxy 1.6-dev1, CentOS6
Getting a segfault when trying connect to port 3389.
segfault at 0 ip (null) sp 7fff18a41268 error 14 in haproxy[40+a4000]
You are using the development tree, please upgrade
latest git first, there are 233 commits since 1.6-dev1.
Thanks. tried this version, it works fine..
Ok, thanks for confirming.
Please help us. This is impacting our production
Please refrain from pushing your threads like this (after only 1 hour),
and CC'ing unrelated people only because they helped you in the past.
This doesn't get you the answers you are looking for any faster, quite
the opposite in fact.
If you
Hi,
I'm experiencing a problem with backend TCP connections being reset
[RST+ACK] by HAProxy after serving one HTTP request and receiving the
[ACK] for the HTTP response. Delay between backend's [ACK] and
haproxy's [RST+ACK] seems random, ranging from single seconds to
several minutes.
On Mon, Apr 13, 2015 at 4:58 PM, Lukas Tribus
luky...@hotmail.commailto:luky...@hotmail.com wrote:
Hi,
I'm experiencing latency problems while running HAProxy 1.4.18.
Our backend servers reply to HAProxy almost instantly (~4ms), but some
of those replies are sent to the clients more
801 - 900 of 1576 matches
Mail list logo