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.