Configure HAProxy by defining a client-facing frontend, one or more destination backend pools, a matching mode (HTTP or TCP), a balancing algorithm, and health checks. Add TLS deliberately on the client side, the backend side, or both. Validate the file and reload HAProxy using the procedure supported by your installed version and service manager.
Understand the HAProxy configuration model
The standard configuration file is commonly /etc/haproxy/haproxy.cfg, although packages and operating systems can use different paths. Most configurations contain these sections:
| Section | Purpose |
|---|---|
global |
Process-wide settings such as logging, connection limits, user/group, and chroot behavior. |
defaults |
Settings inherited by subsequent proxy sections, including mode and timeouts. |
frontend |
The IP address and port clients connect to, plus request routing rules. |
backend |
A pool of destination servers and the policy used to distribute traffic. |
listen |
A combined frontend/backend section that can simplify a single service. |
Separate frontends and backends are generally easier to maintain when several hostnames or application pools share one HAProxy instance.
Choose HTTP or TCP mode
| Mode | Use it when | What HAProxy can do |
|---|---|---|
http |
The service speaks HTTP and you need HTTP-aware routing. | Inspect HTTP messages and route by metadata such as the Host header. |
tcp |
The service is non-HTTP TCP, or you need stream proxying without HTTP inspection. | Proxy TCP connections without HTTP-layer routing. |
Keep the frontend and backend modes aligned. TCP mode is appropriate for services such as database connections; HTTP mode is required for rules that inspect HTTP requests.
Quick wins for a faster PC:
Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Repair Windows errors before they cause bigger problemsFix Now →#1 Best Overall
- 【Five Gigabit Ports】1 Gigabit WAN Port plus 2 Gigabit WAN/LAN Ports plus 2 Gigabit LAN Port. Up to 3 WAN ports optimize bandwidth usage through one device.
- 【One USB WAN Port】Mobile broadband via 4G/3G modem is supported for WAN backup by connecting to the USB port. For complete list of compatible 4G/3G modems, please visit TP-Link website.
- 【Abundant Security Features】Advanced firewall policies, DoS defense, IP/MAC/URL filtering, speed test and more security functions protect your network and data.
- 【Highly Secure VPN】Supports up to 20× LAN-to-LAN IPsec, 16× OpenVPN, 16× L2TP, and 16× PPTP VPN connections.
- Security - SPI Firewall, VPN Pass through, FTP/H.323/PPTP/SIP/IPsec ALG, DoS Defence, Ping of Death and Local Management. Standards and Protocols IEEE 802.3, 802.3u, 802.3ab, IEEE 802.3x, IEEE 802.1q
Build a basic HTTP reverse proxy and load balancer
The following is an illustrative starting point. Replace the addresses, ports, health path, and limits with values appropriate for your system; the timeout and connection values are not universal defaults.
global
log 127.0.0.1 local0
maxconn 60000
defaults
mode http
timeout connect 5s
timeout client 30s
timeout server 30s
frontend public_http
bind :80
default_backend app_servers
backend app_servers
balance roundrobin
option httpchk GET /health
server app1 192.0.2.10:8080 check
server app2 192.0.2.11:8080 checkWhat each part does
bind :80accepts client connections on port 80 on the local addresses selected by the operating system.default_backend app_serverssends requests that have no more specific rule to the named pool.balance roundrobinselects the documented round-robin policy.option httpchk GET /healthasks each HTTP server to expose a meaningful readiness endpoint.checkenables active checking on each server line.
Route multiple applications with ACLs
For several sites or services, keep one frontend and choose a backend with request conditions. A Host-header example is:
frontend public_http
bind :80
acl host_api hdr(host) -i api.example.com
acl host_web hdr(host) -i www.example.com
use_backend api_servers if host_api
use_backend web_servers if host_web
default_backend web_servers
backend api_servers
balance leastconn
server api1 192.0.2.20:8080 check
server api2 192.0.2.21:8080 check
backend web_servers
balance roundrobin
server web1 192.0.2.30:8080 check
server web2 192.0.2.31:8080 checkUse a dedicated default_backend so requests that match no ACL have an intentional destination rather than an accidental one.
Rank #2
- 【Flexible Port Configuration】1 2.5Gigabit WAN Port + 1 2.5Gigabit WAN/LAN Ports + 4 Gigabit WAN/LAN Port + 1 Gigabit SFP WAN/LAN Port + 1 USB 2.0 Port (Supports USB storage and LTE backup with LTE dongle) provide high-bandwidth aggregation connectivity.
- 【High-Performace Network Capacity】Maximum number of concurrent sessions – 500,000. Maximum number of clients – 1000+.
- 【Cloud Access】Remote Cloud access and Omada app brings centralized cloud management of the whole network from different sites—all controlled from a single interface anywhere, anytime.
- 【Highly Secure VPN】Supports up to 100× LAN-to-LAN IPsec, 66× OpenVPN, 60× L2TP, and 60× PPTP VPN connections.
- 【5 Years Warranty】Backed by our 5-years warranty and free technical support from 6am to 6pm PST Monday to Fridays
Choose a balancing algorithm
The balance directive controls how HAProxy selects a server. Available documented choices include:
Free tools Windows power users keep installed
One-click scans. No signup required.
| Algorithm | Use as a decision guide |
|---|---|
roundrobin |
Cycle through servers for an even distribution when servers and requests are broadly similar. |
leastconn |
Prefer the server with the fewest active connections, which can suit long-lived or uneven-duration connections. |
random |
Distribute selections randomly when that behavior fits the workload. |
first |
Prefer earlier servers in the configured order, subject to capacity and availability. |
hash |
Use a hash-based policy when repeatable selection or a form of affinity is required. |
There is no universally best algorithm. Base the choice on connection duration, request distribution, server capacity, and whether the application requires persistence. The available documentation does not establish performance measurements for a particular workload.
Add health checks that reflect application readiness
Health checks keep failed servers out of rotation and allow recovered servers to return after successful checks. A check on a server line can test basic TCP reachability:
Rank #3
- 【Flexible Port Configuration】1 Gigabit SFP WAN Port + 1 Gigabit WAN Port + 2 Gigabit WAN/LAN Ports plus1 Gigabit LAN Port. Up to four WAN ports optimize bandwidth usage through one device.
- 【Increased Network Capacity】Maximum number of associated client devices – 150,000. Maximum number of clients – Up to 700.
- 【Integrated into Omada SDN】Omada’s Software Defined Networking (SDN) platform integrates network devices including gateways, access points & switches with multiple control options offered – Omada Hardware controller, Omada Software Controller or Omada cloud-based controller(Contact TP-Link for Cloud-Based Controller Plan Details). Standalone mode also applies.
- 【Cloud Access】Remote Cloud access and Omada app brings centralized cloud management of the whole network from different sites—all controlled from a single interface anywhere, anytime.
- 【SDN Compatibility】For SDN usage, make sure your devices/controllers are either equipped with or can be upgraded to SDN version. SDN controllers work only with SDN Gateways, Access Points & Switches. Non-SDN controllers work only with non-SDN APs. For devices that are compatible with SDN firmware, please visit TP-Link website.
server app1 192.0.2.10:8080 checkFor HTTP, check an endpoint that represents real readiness rather than merely an open port:
backend app_servers
option httpchk GET /health
server app1 192.0.2.10:8080 check
server app2 192.0.2.11:8080 check- A TCP check confirms that a connection can be made.
- An HTTP check can exercise an endpoint and evaluate the response status or content according to the health-check settings you configure.
- HAProxy removes a server after the configured failure threshold and restores it after the configured success threshold.
- Choose a health endpoint that fails when the application cannot safely serve user traffic, not only when the process is listening.
Configure HTTPS at the edge
To terminate client TLS at HAProxy, attach a certificate bundle to a TLS bind:
Recommended Free Tools
frontend public_https
bind :443 ssl crt /path/to/site.pem
default_backend app_serversYou can keep a separate port-80 frontend that redirects HTTP clients to HTTPS. The certificate path and bundle format must match your installation and certificate-management process.
Encrypt and verify HAProxy-to-backend traffic
Client-side TLS termination and upstream TLS are separate decisions. To make HAProxy connect to an HTTPS backend and validate its certificate, configure the server line with TLS verification and a trusted CA:
backend secure_app_servers
server app1 app1.internal.example:8443 ssl verify required ca-file /path/to/ca.pem checkverify required checks the upstream certificate against the configured trust root. verify none disables that trust check and may be useful for narrowly controlled self-signed deployments, but it removes an important protection and should not be the routine production choice where a suitable CA can be configured.
Backend SNI considerations
HAProxy 3.3 and newer, along with the specifically documented newer product editions, set backend SNI from the Host header automatically. Confirm your installed version before relying on that behavior. Use explicit SNI settings, or disable automatic behavior, when your backend naming and certificate design require it.
Best Value
- Multi-WAN Business Continuity: Connect up to 5 ISPs with automatic failover and load balancing — if one connection drops, traffic instantly reroutes to keep your business, remote office, or home lab online
- OpenWRT-Ready Enterprise Control: Full OpenWRT support unlocks VLAN segmentation, advanced firewall rules, custom QoS policies, and community-developed packages for professional-grade network management
- Complete VPN Gateway Suite: WireGuard, OpenVPN, IPsec, PPTP, and L2TP server and client built in; create site-to-site tunnels, host remote access, or route specific VLANs through encrypted VPN connections
- Professional Security Stack: SPI firewall, DoS attack prevention, IP/MAC binding, domain filtering, and DMZ hosting protect your network perimeter while keeping critical services accessible
- Flexible Deployment & Monitoring: Web GUI or Cudy App cloud management with TR-069 support; built-in diagnostic tools (Ping, Traceroute, NSLookup, system logs) for rapid troubleshooting anytime
Validate, stage, and reload safely
- Check the installed HAProxy version and identify the configuration path and service manager used by your package.
- Save a known-good configuration and edit a staged copy.
- Validate the staged file with the HAProxy executable and configuration-path option supplied by your local package or service documentation.
- Apply the file with the service manager’s supported reload operation; the exact command is platform- and package-specific.
- Inspect HAProxy and application logs, backend health state, request routing, and TLS verification after the reload.
- Temporarily stop or isolate one backend and confirm that health checks remove it from rotation, then verify that it returns after recovery.
The documented no-impact master-worker reload behavior applies to HAProxy 3.1 and newer and named newer product editions. Earlier releases may drop connections during reloads, so confirm the behavior of your installed version before changing production configuration.
Troubleshoot common configuration failures
HAProxy will not start or reload
- Run the version-appropriate configuration validation command and read the reported file and line number.
- Check section names, indentation, certificate paths, address/port syntax, and duplicate server names.
- Confirm that the bind address and port are available and that the HAProxy process has permission to read certificate and CA files.
All servers are marked down
- Test reachability from the HAProxy host to each address and port.
- Verify that the health-check path, protocol, expected status, and any Host/SNI requirements match the application.
- Check firewall rules and whether the service is listening on the address HAProxy uses.
Traffic reaches the wrong pool
- Inspect Host-header ACL spelling and case-insensitive matching.
- Ensure
use_backendrules appear before the intended fallback and that a deliberatedefault_backendexists. - Confirm that the frontend is running in HTTP mode; TCP mode cannot inspect HTTP headers.
Upstream HTTPS fails
- Verify the CA file contains the issuing trust root and that the backend certificate name matches the name used for verification.
- Check whether the backend requires SNI and whether your HAProxy version supplies it automatically or needs explicit configuration.
- Do not switch to
verify nonemerely to hide a trust or naming error without assessing the security impact.
Version and deployment cautions
HAProxy community, Enterprise, and ALOHA editions can differ in paths, controls, supported features, and operational procedures. Directives outside this minimal proxy/load-balancer path should be checked against the manual for the exact release and edition you run. The examples assume an HTTP application pool; adapt the mode, checks, TLS settings, and timeouts to your actual protocol and failure model.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
