WebSocket for 1C-Bitrix: Setup and Latency Reduction

Imagine: a corporate portal with 500 employees, chat as the primary communication channel. Every 20 seconds, each employee's browser sends a "any new messages?" request — that's Long Polling. The server gets overwhelmed, and messages arrive with delay. We've encountered this dozens of times. Setting up WebSocket in Bitrix solves the problem radically: the server pushes data as it appears, channel load drops by 70%, latency — milliseconds. With our experience (10+ years with Bitrix, 50+ WebSocket projects) you get a guarantee of stable operation.

How WebSocket Accelerates Bitrix24

WebSocket is a persistent bidirectional connection between browser and server. In Bitrix, the pull module (Push and Pull) handles it. When a NodeJS push-server is present, it automatically switches from Long Polling to WebSocket. The client side is the JS library BX.PullClient, which tries WebSocket first, falls back to SSE, then to Long Polling.

WebSocket outperforms Long Polling by up to 20x in latency and reduces server load by up to 70%.

Transport is determined in bitrix/js/pull/pull.js via the variable BX.Pull.config. To force transport for debugging:

BX.Pull.connect({ serverEnabled: true, serverUrl: 'https://example.ru/bitrix/subws/', guestMode: false, userId: USER_ID, userHash: USER_HASH, transport: 'websocket' // force WebSocket }); 

Compare Long Polling vs WebSocket:

Why Standard Long Polling Is Not Suitable for High-Load Projects

With 2000 online users, Long Polling generates 2000 requests every 20 seconds — 100 requests per second. This creates a huge load on Nginx and PHP-FPM. WebSocket holds one persistent connection per user, reducing HTTP requests to zero. Resource savings allow serving more clients on the same hardware. In one project, we cut server CPU load from 85% to 25% and reduced message delivery latency from 15 seconds to under 100ms.

Step-by-Step WebSocket Setup in Bitrix

Environment Check

Ensure the server meets requirements: PHP 7.4+, Node.js 12+, the proc_open module enabled (for NodeJS push-server). Our experience shows 80% of issues are due to missing execution rights for the NodeJS process.

Nginx Configuration

WebSocket requires special handling in Nginx. Key are Upgrade and Connection headers:

map $http_upgrade $connection_upgrade { default upgrade; '' close; } server { listen 443 ssl http2; server_name example.ru; # ... SSL settings ... # WebSocket endpoint for push-server location /bitrix/subws/ { proxy_pass http://127.0.0.1:9011; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; # Critical: without this Nginx breaks connection after 60 sec proxy_read_timeout 3600s; proxy_send_timeout 3600s; # No buffering — data must flow in real time proxy_buffering off; } } 

map $http_upgrade $connection_upgrade — correctly handles both WebSocket (Upgrade: websocket) and regular HTTP requests through one location.

NodeJS Push-Server Clustering

A single NodeJS process uses one CPU core. Under high load (1000+ connections), you need cluster mode — several worker processes behind a load balancer:

In config.json of push-server:

{ "cluster": { "workers": 4, "sticky": true } } 

sticky: true means sticky sessions: one client always hits the same worker. Without this, WebSocket connections may break when switching between workers.

For load balancing multiple NodeJS instances in Nginx:

upstream push_backend { ip_hash; # sticky sessions by IP server 127.0.0.1:9011; server 127.0.0.1:9012; server 127.0.0.1:9013; server 127.0.0.1:9014; } location /bitrix/subws/ { proxy_pass http://push_backend; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection $connection_upgrade; proxy_read_timeout 3600s; proxy_buffering off; } 

Debugging and Diagnostics

In Chrome DevTools → Network → filter WS — shows all WebSocket connections with data frames. Via curl (handshake only):

curl -v \ -H "Upgrade: websocket" \ -H "Connection: Upgrade" \ -H "Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==" \ -H "Sec-WebSocket-Version: 13" \ https://example.ru/bitrix/subws/ # Expected response: HTTP/1.1 101 Switching Protocols 

More about the protocol on Wikipedia.

Typical Errors and Solutions

Let's look at a few common problems when setting up WebSocket. First, the connection drops every 60 seconds. Cause: proxy_read_timeout in Nginx is not set or defaults to 60s. Solution — increase timeout to 3600s. Second, WebSocket doesn't work behind Cloudflare. Cloudflare proxies WebSocket only on paid plans (Pro+). On the free plan — use long polling or take the WebSocket domain out of Cloudflare (DNS-only). Third, error 400 Bad Request during handshake. Nginx doesn't pass the Upgrade header to the backend — check for proxy_http_version 1.1 and proxy_set_header Upgrade. HTTP/2 does not support WebSocket upgrade — use HTTP/1.1 only for the WebSocket endpoint.

What's Included in WebSocket Setup

• Audit of current server and Bitrix configuration (check pull module, PHP version, NodeJS).
• Nginx configuration: WebSocket proxy, SSL, connection limits.
• Installation and configuration of NodeJS push-server: clustering, sticky sessions.
• Integration with Bitrix24: force WebSocket, test fallback to SSE/Long Polling.
• Optimization of system limits: ulimit, worker_connections, LimitNOFILE.
• Documentation for support and monitoring.
• Administrator training (1 hour).

We guarantee stable operation: after setup, we handle loads up to 10,000 concurrent connections (confirmed by case studies). Contact us for a free consultation on your project. We will evaluate your current infrastructure and propose the optimal solution.