The question seems to be quite straight and easy, however I have not been able to find a proper answer.
In haproxy I have 1 backend, say:
backend-1
and 2 frontends, say:
frontend-1
frontend-2
In the backend stanza I want to set a "timeout server" parameter, but, only if the connection comes from frontend-1.
As I didn't find anything I tried to figure it out myself:
backend backend-1
bind *:80
option <blahblah_option>
timeout server 1d if frontend frontend-1
This syntax does not work, and I am mentioning it to let understand what I am trying to achieve.
This is not doable yet in HAProxy.
Later, you will be able to set timeouts using tcp-request and http-request rules.
What we usually do to workaround this for now, is that we setup 2 backends using the same parameters, but different timeout servers.
This is useful when a few urls only deserve a long server timeout.
Edit followup your comment about multiple health checks:
Well, that's why the server's 'track' directive exists:
backend my_app
server srv1 10.0.0.1:80 check
backend my_app_longtime
server srv1 10.0.0.1:80 track my_app/srv1
In the conf above, the server in my_app_longtime backend won't be checked. That said, it will follow up the same state than srv1 in the backend my_app.
Baptiste
Baptiste
I did it like this and it worked. It made it possible to extend timeout on specific app urls, which are more time consuming. Used that trace health check - thanks Babtiste.
frontend www-http
bind 10.0.0.1:80
default_backend app
acl long_url path_beg -i /long_url
use_backend app-extended if long_url
backend app
server web-1 10.0.0.2:80 check
backend app-extended
server web-1 10.0.0.2:80 trace app/web-1
timeout server 10m
Related
I’m quite new to HAProxy and have what I believe to be a simple use-case:
I want to redirect requests made into my KVM host --> URL of the guest VMs.
In my case the redirects are for several VMs that run HTTPS content.
Example:
-- HAProxy is running on the KVM host (10.10.10.5 - ansout.mine.local)
-- HTTPS guest VM running on KVM (172.10.10.5 - ans.lab.local)
How can I make a request from a client (on the KVM network) to ‘http://ansout.mine.local’ and redirect it into, 'https://ans.lab.local'
It would seem I need to use the ‘http-request redirect’ function in HAProxy but I still can’t wrap my head around it.
Could anyone one kindly provide some pointers on how to achieve the example above?
Many thanks in advance.
I assume that the client then should connect directly to ans.lab.local.
listen http-in
bind :80
log stdout format raw daemon
mode http
option httplog
tcp-request inspect-delay 5s
tcp-request content accept if HTTP
timeout client 5s
timeout connect 30s
timeout server 30s
http-request redirect code 301 location https://ans.lab.local if { hdr(host) -i ansout.mine.local }
If you have several hosts which you want to redirect please take a look into HAProxy Maps.
Re-asking the question from HA-Proxy discourse site here in the hopes of getting more eyes on it.
I am using HA-Proxy version 1.9.4 2019/02/06 for proxying HTTP traffic to a h2c backend. I am however seeing HA-Proxy set the :scheme to https (and from as far as I can tell uses SSL in the request) when proxying the request. When I hit the backend directly, the :scheme is set to http and the request is non-SSL as expected. I have verified this HA-Proxy behavior using wireshark.
Any suggestions on what I should change in my configuration so that I can set to make sure that the :scheme gets set to http while proxying the request to the backend?
I am using curl 7.54.0 to make requests:
$ curl http://localhost:9090
where HA-Proxy is listening on port 9090.
My HA-Proxy config file:
global
maxconn 4096
daemon
defaults
log global
option http-use-htx
timeout connect 60s
timeout client 60s
timeout server 60s
frontend waiter
mode http
bind *:9090
default_backend local_node
backend local_node
mode http
server localhost localhost:8080 proto h2
It's not supported yet. The client=>haproxy connection can be HTTP/2, the haproxy=>server connection cannot.
https://cbonte.github.io/haproxy-dconv/1.9/configuration.html#1.1
HTTP/2 is only supported for incoming connections, not on connections
going to servers.
Just add proto h2 to the server definition.
Cite from example:
server server1 192.168.1.13:80 proto h2
It's an experimental feature of haproxy-1.9, you must enable option http-use-htx to use it.
option http-use-htx is enabled by default since haproxy-2.0-dev3.
This was reported as an issue in haproxy github and has been fixed in version 2.0.
I am trying to setup haproxy on EC2 instance but facing below error:
503 Service Unavailable. No server is available to handle this
request.
Any help is highly appreciated. I tried many ways but all in vain.
My haproxy version is 1.5 and this is haproxy.cfg file :
frontend main
bind *:80
default_backend server
backend server
balance roundrobin
server node1 xx.xx.xx.xx:80 check maxconn 32
server node2 xx.xx.xx.xx:80 check maxconn 32
Probably the config file you shared is not complete. It should contain mode http in frontend and backend server if not mentioned in global settings.
Also check if you can access the webserver, it is up and running.
Allow the connection on webserver through firewall.
You can also share full config file so exact issue can be identified.
Hope this helps!
I've been trying, and failing so far, to run Transmission behind HAProxy.
If I just add a new backend and route traffic as follows:
frontend http-in
bind *:80
reqadd X-Forwarded-Proto:\ http
acl host1 hdr_end(host) -i web.host1.host
use_backend apache_backend if host1
acl transmission_host hdr_end(host) -i transmission.host1.host
use_backend transmission_backend if transmission_host
Then I get a 409 conflict error stating I have an invalid session-id header. That's pretty obvious and expected since there's a proxy in the middle.
I thought of recompiling transmission to get rid of the check, but decided in the end to face the challenge of learning a bit more of HAProxy. What did I have in mind?
Client reaches HAProxy
HAProxy connects to transmission-daemon
Daemon replies with X-Transmission-Session-Id
HAProxy stores the Session-Id somehow and replaces Session-Id sent by the client with the one captured by HAProxy.
After a lot of Googling and playing with the settings, I got an almost working configuration:
frontend http-in
bind *:80
reqadd X-Forwarded-Proto:\ http
capture response header X-Transmission-Session-Id len 48
acl host1 hdr_end(host) -i web.host1.host
use_backend apache_backend if host1
acl transmission_host hdr_end(host) -i transmission.host1.host
use_backend transmission_backend if transmission_host
backend transmission_backend
mode http
http-request set-header X-Transmission-Session-Id %hs
server transmission-daemon transmission.intranet:9091
My configuration examples are summarized.
It works, sort of. I get a login prompt for transmission, but the page loads incredibly slow. I'm more than 10 minutes in and still don't have it fully loaded.
More pages go through this proxy: HTTP, HTTPS, TCP, some load balanced, some set as fail-overs. They all load normally and fast. If I connect directly to the transmission-daemon server, it loads fast as well.
I'll keep looking around.
Any ideas?
Thanks in advance!
3 years later,
from what I've seen in https://gist.github.com/yuezhu/93184b8d8d9f7d0ada0a186cbcda9273
you should capture request and response in frontend http-in,
I didn't dug much more, but the backend seems to need
stick-table type binary len 48 size 30k expire 30m
stick store-response hdr(X-Transmission-Session-Id)
stick on hdr(X-Transmission-Session-Id)
to work
We've setup 3 servers:
Server A with Nginx + HAproxy to perform load balancing
backend server B
backend server C
Here is our /etc/haproxy/haproxy.cfg:
global
log /dev/log local0
log 127.0.0.1 local1 notice
maxconn 40096
user haproxy
group haproxy
daemon
defaults
log global
mode http
option httplog
option dontlognull
retries 3
option redispatch
maxconn 2000
contimeout 50000
clitimeout 50000
srvtimeout 50000
stats enable
stats uri /lb?stats
stats realm Haproxy\ Statistics
stats auth admin:admin
listen statslb :5054 # choose different names for the 2 nodes
mode http
stats enable
stats hide-version
stats realm Haproxy\ Statistics
stats uri /
stats auth admin:admin
listen Server-A 0.0.0.0:80
mode http
balance roundrobin
cookie JSESSIONID prefix
option httpchk HEAD /check.txt HTTP/1.0
server Server-B <server.ip>:80 cookie app1inst2 check inter 1000 rise 2 fall 2
server Server-C <server.ip>:80 cookie app1inst2 check inter 1000 rise 2 fall 3
All of the three servers have a good amount of RAM and CPU cores to handle requests
Random HTTP 503 errors are shown when browsing: 503 Service Unavailable - No server is available to handle this request.
And also on server's console:
Message from syslogd#server-a at Dec 21 18:27:20 ...
haproxy[1650]: proxy Server-A has no server available!
Note that 90% times of the time there is no errors. These errors happens randomly.
I had the same issue. After days of pulling my hair out I found the issue.
I had two HAProxy instances running. One was a zombie that somehow never got killed during maybe an update or a haproxy restart. I noticed this when refreshing the /haproxy stats page and the PID would change between two different numbers. The page with one of the numbers had absurd connection stats. To confirm I did
netstat -tulpn | grep 80
Or
sudo lsof -i:80
and saw two haproxy processes listening to port 80.
To fix the issue I did a "kill xxxx" where xxxx is the pid with the suspicious statistics.
Adding my answer here for anyone else who encounters this exact same problem but none of the listed solutions above are applicable. Please note that my answer does not apply to the original code listed above.
For anyone else who may have this problem, check your config and see if you might have mistakenly put the same "bind" line in multiple sections of your config. Haproxy does not check this during startup, and I plan to submit this as a recommended validation check to the developers. In my case, I have 3 different sections of the config, and I mistakenly put the same IP binding in two different places. It was about a 50/50 shot on whether or not the correct section would be used or the incorrect section was used. Even when the correct section was used, about half of the requests still got a 503.
It is possible your servers share, perhaps, a common resource that is timing out at certain times, and that your health check requests are being made at the same time (and thus pulling the backend servers out at the same time).
You can try using the HAProxy option spread-checks to randomize health checks.
I had the same issue, due to 2 HAProxy services running in the linux box, but with different name/pid/resources. Unless i stop the unwanted one, the required instances throws 503 error randomly, say 1 in 5 times.
Was trying to use single linux box for multiple URL routing but looks a limitation in haproxy or the config file of haproxy i have defined.
Hard to say without more details, but is it possible you are exceeding the configured maxconn for each backend? The Stats UI shows these stats on both the frontend and on individual backends.
I resolved my intermittent 503s with HAProxy by adding option http-server-close to backend. Looks like uWSGI (which is upstream) is not doing well with keep-alive. Not sure what's really behind the problem, but after adding this option, haven't seen single 503 since.
don't use the "bind" line in multiple sections of your haproxy.cfg
for example, this would be wrong
frontend stats
bind *:443 ssl crt /etc/ssl/certs/your.pem
frontend Main
bind *:443 ssl crt /etc/ssl/certs/your.pem
fix like this
frontend stats
bind *:8443 ssl crt /etc/ssl/certs/your.pem
frontend Main
bind *:443 ssl crt /etc/ssl/certs/your.pem