Excalidraw负载均衡配置：Nginx反向代理设置详解

Excalidraw 负载均衡与 Nginx 反向代理实战配置

在现代分布式协作环境中，可视化工具的稳定性直接影响团队效率。当多个工程师同时在一个白板上绘制架构图、梳理业务流程时，任何一次连接中断或延迟飙升都可能打断思路，甚至导致数据不同步。Excalidraw 作为一款轻量但功能强大的开源手绘风格白板工具，正被越来越多技术团队用于日常设计和头脑风暴。然而，其默认的单实例部署模式难以应对高并发访问和生产级可用性要求。

要让 Excalidraw 真正在企业环境中“扛住压力”，关键在于后端架构的合理设计——尤其是如何通过反向代理实现多实例负载均衡。而在这类场景中，Nginx 几乎是不可替代的选择：它不仅性能卓越，还能精准处理 WebSocket 长连接这类复杂协议。更重要的是，一次错误的代理配置可能导致用户反复掉线、协作失败，这种体验上的挫败感远比系统慢一点更致命。

我们不妨从一个真实问题切入：假设你刚为团队搭建了 Excalidraw 服务，同事们开始使用后却发现，每当有超过 10 人同时编辑一张图时，部分用户的画笔就会“卡住”，刷新页面才能恢复。查看日志发现，并非服务器资源耗尽，而是某些请求被错误地转发到了不同的后端实例上，导致状态不一致。这正是典型的会话粘滞性缺失问题——也是本文要解决的核心挑战。

Nginx 的强大之处就在于，它能以极低的资源开销，完成流量调度、SSL 卸载、协议升级识别等一系列关键任务。对于 Excalidraw 这种前后端分离、依赖 WebSocket 实现协同编辑的应用来说，合理的 Nginx 配置不仅是“锦上添花”，更是保障基础可用性的“安全绳”。

来看一组核心配置逻辑。首先，我们需要定义一组后端节点：

upstream excalidraw_backend { ip_hash; server 192.168.1.10:8080; server 192.168.1.11:8080; server 192.168.1.12:8080; # 失败探测机制 fail_timeout=30s; max_fails=3; }

这里的关键是ip_hash指令。它的作用是根据客户端 IP 地址计算哈希值，确保同一个用户的多次请求始终路由到同一台后端服务器。这对于保持 WebSocket 连接的一致性至关重要。如果不启用此策略，默认的轮询方式会让用户的 HTTP 请求和后续的 WebSocket 升级请求落到不同实例上，从而造成“找不到房间”或“无法同步”的问题。

当然，如果你的后端已经实现了状态外置（例如使用 Redis 共享房间数据），那么可以改用least_conn或加权轮询来更均匀地分摊负载。但在大多数自托管场景下，出于部署简便考虑，仍建议优先采用ip_hash来保证会话亲和性。

接下来是 server 块的配置，这也是最容易出错的部分之一：

server { listen 443 ssl http2; server_name whiteboard.example.com; ssl_certificate /etc/nginx/ssl/excalidraw.crt; ssl_certificate_key /etc/nginx/ssl/excalidraw.key; ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; location / { proxy_pass http://excalidraw_backend; 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; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection "upgrade"; proxy_buffering off; proxy_connect_timeout 30s; proxy_send_timeout 60s; proxy_read_timeout 60s; } }

这段配置有几个细节值得深挖。首先是Upgrade和Connection头的设置。HTTP/1.1 中 WebSocket 的建立依赖于协议升级机制。如果 Nginx 不显式传递这些头部，代理层会将其视为普通 HTTP 请求处理，导致升级失败，WebSocket 连接无法建立。这一点看似简单，却是大量线上问题的根源。

其次是proxy_buffering off;。关闭缓冲意味着响应数据一旦从后端返回，就立即转发给客户端，不会暂存于 Nginx 内存中。这对实时性要求高的场景非常有利——比如多人协作画图时的操作同步，哪怕几十毫秒的延迟累积也会让用户感知到“卡顿”。当然，这也意味着你需要确保网络稳定，否则容易出现传输中断。

至于超时设置，则需要结合实际网络环境权衡。proxy_read_timeout设置为 60 秒，表示如果后端在 60 秒内没有发送任何数据，连接将被关闭。这个值不能太短，否则长连接可能被误杀；也不能太长，以免占用过多连接资源。对于 Excalidraw 来说，只要用户还在活跃操作，消息帧就会持续流动，因此 60 秒是一个相对安全的折中选择。

再来看部署层面的实践。使用 Docker Compose 快速搭建一个多实例环境是非常常见的做法：

version: '3' services: excalidraw-1: image: excalidraw/excalidraw:latest container_name: excalidraw_1 ports: - "8080" environment: - ALLOW_LISTEN=true - WS_SERVER_URL=wss://whiteboard.example.com restart: unless-stopped excalidraw-2: image: excalidraw/excalidraw:latest container_name: excalidraw_2 ports: - "8080" environment: - ALLOW_LISTEN=true - WS_SERVER_URL=wss://whiteboard.example.com restart: unless-stopped excalidraw-3: image: excalidraw/excalidraw:latest container_name: excalidraw_3 ports: - "8080" environment: - ALLOW_LISTEN=true - WS_SERVER_URL=wss://whiteboard.example.com restart: unless-stopped nginx: image: nginx:alpine container_name: nginx-proxy ports: - "80:80" - "443:443" volumes: - ./nginx.conf:/etc/nginx/nginx.conf - ./ssl:/etc/nginx/ssl depends_on: - excalidraw-1 - excalidraw-2 - excalidraw-3 restart: unless-stopped

这里的WS_SERVER_URL必须指向外部可访问的 WSS 地址（注意是加密的 wss://），否则浏览器会因协议不匹配拒绝连接。另外，虽然depends_on能控制启动顺序，但它并不等待应用真正就绪。在生产环境中，应结合健康检查脚本或使用 Kubernetes 的 readiness probe 来实现更可靠的依赖管理。

整个系统的典型调用链如下：

[Client Browser] ↓ (HTTPS) [Nginx 反向代理] ↓ (HTTP/WebSocket) [Excalidraw Instance] ←→ [Optional: Redis for state sharing]

Nginx 作为唯一入口，承担了 SSL 终止、请求路由、连接管理等职责。后端实例无需暴露公网，提升了整体安全性。同时，所有访问日志集中在 Nginx 层，便于审计与监控。

在实际运维中，还有一些经验值得分享：

• 日志分析：开启$http_upgrade和$connection_upgrade变量记录，可以帮助快速定位 WebSocket 是否成功升级。
• 证书自动化：建议配合 Certbot 使用 Let’s Encrypt，避免证书过期导致服务中断。
• 监控指标采集：可通过 Nginx Plus 或 OpenResty + Prometheus 导出 QPS、响应时间、活跃连接数等关键指标。
• 故障演练：定期模拟某个后端宕机，观察 Nginx 是否能自动剔除故障节点并恢复服务。

最终你会发现，这套架构的价值远不止于支撑 Excalidraw。任何基于 WebSocket 的实时应用——无论是在线文档编辑器、聊天室，还是远程协作平台——都可以复用相同的模式。Nginx 在其中扮演的角色，就像交通指挥中心，既不让某条道路拥堵，也不让任何一辆车走错方向。

当你的团队能在千人规模的敏捷工作坊中流畅协作，没有人注意到背后的技术栈时，这才是基础设施最理想的状态。而这一切，往往始于几行精心打磨的 Nginx 配置。