When To Run HAProxy in HTTP or TCP Modes

Overview:

This guide shows how to configure HAProxy to run in HTTP mode (Layer 7 proxy mode) or TCP mode (Layer 4 proxy mode) in Linux.

What you need to know

HAProxy supports two load balancing modes: TCP or Layer 4 proxy mode and HTTP mode or Layer 7 proxy mode. The mode parameter is used to define whether HAProxy operates as a simple TCP proxy or if it can inspect incoming traffic’s higher-level HTTP messages. The mode setting can be added in the default, frontend, or backend sections.

Note: If all or most of your frontend and backend sections use the same mode, you should consider specifying the mode setting in the defaults section to avoid repetition.

This guide assumes that you:

• understand the OSI (Open Systems Interconnection) model,
• already have HAProxy installed on your Linux server, and
• have root access or can run commands using the sudo command.

Run HAProxy in HTTP Mode (Layer 7 Proxy Mode)

When HAProxy is configured to run in the HTTP mode, it has access to several HTTP-specific options in relation to a request and response. This enables you to configure HAProxy to process a request as required; it can perform routing based on any information discovered in the HTTP request, including URL path, query string, and HTTP headers. For example, you can configure it to choose different backends based on the domain or URL in the HTTP request.

You can use this mode to deploy HAProxy as a gateway to the Internet for your web applications. For example, you can deploy HAProxy in front of other web servers or reverse proxies such as NGINX or Apache.

Sample Configuration

In this sample configuration, the mode setting is defined in the defaults section:

global
	maxconn 50000
	log	127.0.0.1 local2
	chroot /var/lib/haproxy
	stats socket /run/haproxy/admin.sock user haproxy group haproxy mode 660 level admin expose-fd listeners
	stats timeout 30s
	user haproxy
	group haproxy
	daemon
    	ssl-default-bind-ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384
    	ssl-default-bind-options ssl-min-ver TLSv1.2
    	ssl-dh-param-file /etc/ssl/terp/dhparam

defaults
	log  global
   	mode http
	option	httplog
	option	dontlognull
    	timeout http-request 10s
    	timeout connect 10s
    	timeout client  30s
    	timeout server  30s
	errorfile 400 /etc/haproxy/errors/400.http
	errorfile 403 /etc/haproxy/errors/403.http
	errorfile 408 /etc/haproxy/errors/408.http
	errorfile 500 /etc/haproxy/errors/500.http
	errorfile 502 /etc/haproxy/errors/502.http
	errorfile 503 /etc/haproxy/errors/503.http
	errorfile 504 /etc/haproxy/errors/504.http

listen stats
      	bind *:8500
      	stats enable
      	stats hide-version
      	stats uri /monitor
      	stats realm Haproxy\ Statistics
      	stats refresh 5s

frontend  backend_svrs
      	http-response del-header Proxy
      	mode http
      	bind *:80
      	bind *:443 ssl crt /etc/ssl/example.com.pem alpn h2,http/1.1
      	redirect scheme https code 301 if !{ ssl_fc }
      	option     forwardfor
      	http-response set-header Strict-Transport-Security max-age=63072000
      	default_backend nginx_svrs

backend  nginx_svrs
      	mode http
      	option httpchk HEAD /
	default-server check maxconn 50000
      	server nginx_svr1 10.1.1.10:80
        server nginx_svr2 10.1.1.15:80
 

Run HAProxy in TCP Mode (Layer 4 Proxy Mode)

In this mode, HAProxy does not inspect the HTTP headers in the packet; it simply allows a request to be forwarded directly to backend servers. It just serves as a messenger, passing messages back, and Because it is just concerned with transit, proxying in this mode lightweight and fast.

This mode is best suited for load-balancing services that communicate over TCP such as database traffic to PostgreSQL, MySQL, Redis servers, and more.

Sample Configuration

The following is a sample configuration for deploying HAProxy as a PostgreSQL database cluster load balancer. The cluster is created and managed using Patroni which has API endpoints for monitoring cluster status and performing health checks via HTTP.

Here, the mode configuration parameter is defined in the defaults section:

global
    maxconn 5000

defaults
    log global
    mode tcp
    retries 2
    timeout client 30m
    timeout connect 4s
    timeout server 30m
    timeout check 5s

listen stats
    mode http
    bind *:6050
    stats enable
    stats uri /

listen primary_dbsvr
    bind *:5432
    option httpchk OPTIONS  /master
    http-check expect status 200
    default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
    server dbsvr1 10.1.1.51:5430 check port 8008
    server dbsvr2 10.1.1.52:5430 check port 8008
    server dbsvr3 10.1.1.53:5430 check port 8008   

listen standbys_dbsvrs
    balance roundrobin
    bind *:5433
    option httpchk OPTIONS /replica
    http-check expect status 200
    default-server inter 3s fall 3 rise 2 on-marked-down shutdown-sessions
    server dbsvr1 10.1.1.51:5430 check port 8008
    server dbsvr2 10.1.1.52:5430 check port 8008
    server dbsvr3 10.1.1.53:5430 check port 8008

Whenever you make changes to your HAProxy configuration, ensure that the configuration is valid by running this command:

#haproxy -c -f /etc/haproxy/haproxy.cfg
OR
$sudo haproxy -c -f /etc/haproxy/haproxy.cfg

Then restart the HAProxy service and ensure that it is running fine by checking the service status, as follows:

#systemctl restart haproxy
#systemctl status haproxy

Conclusion

That’s all I prepared for you concerning this topic. You can share your thoughts or questions about this guide via the comment form below.

Reference: https://www.haproxy.com/blog/layer-4-and-layer-7-proxy-mode