所需并发的VPN连接数并非由单一指标决定，而是取决于访问策略是应用到单一用户还是多用户。若使用L2TP或PPTP等传统协议，通常每个远端访问者建立一个独立隧道，连接数等于活跃用户数；若使用WireGuard或OpenVPN的UDP模式，底层是共享的UDP多路复用流，但每个远端仍分配独立的会话密钥，因此需为每个远程用户分配唯一的Peer Key或证书。核心差异在于：前者连接数直接映射用户数，后者连接数受限于UDP端口监听数，通常只需一个即可支持多并发。
基于用户数的传统协议连接模型
以L2TP/IPSec为例，当10名员工同时远程访问公司网络时，服务器端需维持10条独立的L2TP隧道。每条隧道对应一个IPsec SA（安全关联），其并发数直接等于活跃会话数。这种模型简单直观，管理边界清晰：断开某用户连接仅终止其对应SA，不影响其他用户。若需预估容量，应统计最大同时在线用户数，而非总注册账号数，clash因为空闲账号不占用连接资源。
服务器端的多条独立隧道与远端共享连接在视觉上的密度对比。
UDP多路复用下的会话并发限制
WireGuard基于UDP，其“并发”指同时活跃的Peer数量，而非底层传输层连接数。一个UDP监听端口可服务任意数量对端，只要每个对端拥有唯一密钥对。例如，服务器端配置一个UDP端口，可支持数百个并发Peer，但每个Peer必须独立握手生成临时密钥。因此，评估此类场景时需关注的是并发会话数（Concurrent Peers），而非TCP连接数。若配置中限制每个IP地址的并发Peer数，则实际并发受此策略约束，clash需查阅软件文档中的per-IP限制参数。
企业级负载均衡下的并发分布
在大型部署中，VPN服务器常置于负载均衡器之后。此时“并发连接数”需区分两层：负载均衡器到后端的TCP/UDP会话数，以及后端服务器上的用户会话数。若负载均衡器采用会话保持，同一用户始终路由至同一后端，其并发数即为该后端的活跃用户数；若采用轮询，单后端并发数降低，但总集群并发不变。评估时应监控各后端的活跃会话指标，而非仅看负载均衡器入口流量，因为入口并发是聚合值，无法反映单点瓶颈。
并发超限的实际表现与边界
当并发数超过许可时，新连接通常被拒绝或排队，而非影响已有连接。在L2TP中，clash verge表现为新的RADIUS认证失败或隧道建立超时；在WireGuard中，表现为新Peer握手无响应或连接卡在Pending状态。已有连接因密钥独立，一般不受影响，但服务器CPU或内存耗尽时可能引发全局延迟。排查时应区分是授权策略限制（如每用户最大会话数）还是系统资源限制，前者查访问控制列表，后者查服务器负载指标。
