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.
| Parameter | HAProxy | nginx upstream |
|---|---|---|
| Performance | up to 100k req/s | up to 50k req/s |
| Health checks | HTTP, TCP, script | only HTTP |
| Statistics | detailed (statuses, queues) | basic (up/down) |
| Configuration complexity | medium | low |
Comparison of Load Balancing Algorithms for Bitrix
| Algorithm | Description | Bitrix-specific Considerations |
|---|---|---|
| roundrobin | Requests round-robin | Evenly distributes requests of varying duration — best choice |
| leastconn | To server with fewest connections | Poor for varying execution times: one node may become loaded with a heavy import |
| first | To first available server | Used for dedicated backends (push, admin) |
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.
Typical Cluster Diagram
- Frontend HAProxy (2 instances with keepalived)
- 2–5 web nodes with mod_xsendfile
- 1 dedicated node for push server
- 1 master node for admin panel and agent tasks
- 1 DB server (or MySQL cluster)
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.