Load Balancing 1C-Bitrix: HAProxy, nginx, Cases

Two Bitrix Servers Without a Load Balancer

Five Bitrix servers are running, but the site slows down during peaks — one server handles 80% of requests while the rest sit idle. Without a single front-end, load distribution is uneven, and a single server failure takes down the entire site. We configure load balancing turnkey: selecting the algorithm, configuring health checks, integrating with the push server and the admin panel. The result is stable operation under peak loads and infrastructure cost savings of up to 30%.

For example, for an online store with a catalog of 500,000 products, we configured HAProxy — response time dropped by 40%, and the number of lost orders fell to zero. For a news portal with 10,000 concurrent users, we used nginx upstream and tripled throughput.

Why Load Balancing Is Critical for Bitrix

Without load balancing, one server gets overloaded while another sits idle. During peaks (sales, promotions), this causes timeouts and lost orders. A load balancer evenly distributes requests, increases throughput by 2–3 times, and ensures fault tolerance: if one node fails, the rest continue working. Additionally, balancing reduces database load by caching on each node.

Which Load Balancer to Choose: HAProxy or nginx?

HAProxy is a specialized L4/L7 load balancer. It handles up to 100,000 requests per second — twice as many as nginx upstream. HAProxy provides detailed statistics (statuses, queues) and custom HTTP checks. nginx upstream is part of the web server, simpler in configuration but less flexible. According to official HAProxy documentation, for clusters of 3 or more nodes, HAProxy is recommended. For 2–3 servers and simple tasks, nginx is sufficient.

Comparison of Load Balancing Algorithms for Bitrix

HAProxy Configuration for Bitrix

# /etc/haproxy/haproxy.cfg global maxconn 50000 log /dev/log local0 tune.ssl.default-dh-param 2048 defaults mode http timeout connect 5s timeout client 60s timeout server 60s option http-server-close option forwardfor log global # Frontend: accept HTTPS frontend bitrix_https bind *:443 ssl crt /etc/ssl/site.pem http-request set-header X-Forwarded-Proto https http-request set-header X-Real-IP %[src] # Admin section — dedicated backend acl is_admin path_beg /bitrix/admin use_backend bitrix_admin if is_admin # Push server — separate backend with long connections acl is_push path_beg /bitrix/pub use_backend bitrix_push if is_push default_backend bitrix_web # Main backend — web nodes backend bitrix_web balance leastconn option httpchk GET /bitrix/admin/cluster_check.php http-check expect status 200 server web-01 10.0.0.11:80 check inter 5s rise 2 fall 3 weight 100 server web-02 10.0.0.12:80 check inter 5s rise 2 fall 3 weight 100 server web-03 10.0.0.13:80 check inter 5s rise 2 fall 3 weight 100 # Admin panel — only master node backend bitrix_admin server web-01 10.0.0.11:80 check # Push server backend bitrix_push timeout server 3600s server push-01 10.0.0.14:8893 check 

balance roundrobin — requests are sent round-robin. For Bitrix with varying response times, this is preferable to leastconn. Parameters rise 2 fall 3 — a node is considered alive after two successful checks, dead after three failures.

nginx upstream as an Alternative

upstream bitrix_backends { round_robin; server 10.0.0.11:80 weight=1 max_fails=3 fail_timeout=30s; server 10.0.0.12:80 weight=1 max_fails=3 fail_timeout=30s; keepalive 32; } server { listen 443 ssl; location / { proxy_pass http://bitrix_backends; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; client_max_body_size 256m; proxy_read_timeout 120s; } } 

keepalive 32 — persistent connections between nginx and backends. Without keepalive, each request opens a new TCP connection to PHP-FPM — unnecessary overhead.

How to Configure Health Checks for Bitrix?

A health check is an HTTP request verifying that a backend is alive. For Bitrix we use the script /bitrix/admin/cluster_check.php, which returns 200. HAProxy is configured as:

option httpchk GET /bitrix/admin/cluster_check.php http-check expect status 200 

Check interval — every 5 seconds. After two successful checks the node recovers, after three failures it goes DOWN. We also recommend checking PHP-FPM and MySQL ports for full monitoring.

Proxying File Uploads

Uploading large files (prices 100+ MB, videos) through the balancer requires configuration:

proxy_request_buffering off; proxy_max_temp_file_size 0; client_max_body_size 512m; proxy_read_timeout 600s; 

Without proxy_request_buffering off, nginx buffers the entire uploaded file in memory — for a 512 MB file and 10 concurrent uploads, that's 5 GB of RAM just for buffers.

Forwarding the Real IP to Bitrix

Bitrix uses the user's IP for sessions and restrictions. Without configuration, it sees the balancer's IP. In /bitrix/php_interface/init.php add:

if (!empty($_SERVER['HTTP_X_REAL_IP'])) { $_SERVER['REMOTE_ADDR'] = $_SERVER['HTTP_X_REAL_IP']; } 

HAProxy forwards the real IP via X-Forwarded-For, nginx via X-Real-IP. We synchronize the balancer settings and init.php.

What's Included in the Load Balancing Setup

• Audit of current architecture and load
• Selection of balancer and algorithm based on tasks
• Server configuration (HAProxy/nginx, health checks, keepalived)
• Configuration of real IP forwarding and sessions
• Optimization of file uploads and buffering
• Integration with push server and admin panel
• Testing under peak load
• Documentation of scheme and parameters
• Training of the administration team
• 30 days of support after launch

Our Experience and Guarantees

Over a decade of configuring 1C-Bitrix clusters. More than 500 implemented projects — from small stores to large catalogs with millions of products. We guarantee stable cluster operation and provide post-implementation support. Get an engineer consultation and a detailed audit of your current architecture. Place your order — and your site will handle any traffic spikes.