服务器HTTPS默认连接数没有固定数值，通常由Nginx/Apache进程模型与系统文件句柄限制共同决定，常见配置下约在1024到65535之间，实际需通过压测确认。
为什么HTTPS连接数比HTTP更值得关注
大部分业务系统上线时，默认走的都是HTTPS协议，比起明文HTTP，HTTPS多了一次TLS握手，加解密过程占用CPU资源，也延长了每个请求的占用时长，换句话说，同样一台服务器，跑HTTPS能支撑的并发连接数，往往只有HTTP的60%到70%，具体表现取决于证书算法、会话复用开关和硬件配置，这也是很多运维同事一压测就发现“连接数上不去”的常见原因。
先弄清楚连接数到底受谁限制
连接数不是单个配置项决定的,它是四层因素叠加之后的结果。
内核文件句柄限制
Linux系统中一切皆文件，每个TCP连接都要占用一个文件描述符，系统级限制通过fs.file-max控制，用户级限制通过ulimit -n控制，很多默认安装的CentOS或Ubuntu系统，用户级限制是1024，这意味着单个进程最多只能同时打开1024个文件描述符算上标准输入输出和监听套接字,实际可用的并发连接只剩1020个左右。
查看当前值：
ulimit -n cat /proc/sys/fs/file-max
Nginx/Apache进程模型
Nginx采用master-worker多进程模型，每个worker进程独立处理连接。worker_connections是每个worker进程的最大连接数，这个数值乘以worker进程数,就是Nginx理论上能承载的连接上限。
查看当前Nginx配置：
nginx -T | grep worker_connections
Apache的MaxRequestWorkers指令则是直接限制同时处理的请求数量，超过之后，多余请求会排队等待,表现为响应变慢而非直接报错。
HTTPS协议本身的额外开销
TLS握手需要交换证书、协商密钥，一顿操作下来，比HTTP握手多消耗约2到3倍CPU时间，如果没开会话复用，每个新连接都要完整走一遍握手流程，高并发场景下,CPU先于连接数打满的情况非常常见。
默认连接数到底是多少
不同环境下的默认值差异很大,整理一个参考表格：
| 环境/软件 | 默认连接数上限 | 备注 |
|---|---|---|
| Linux系统级文件句柄 | 约19万左右（fs.file-max默认值视内存而定） | 一般不是瓶颈 |
| Linux用户级ulimit | 1024 | 最普遍的瓶颈来源 |
| Nginx worker_connections | 512或1024，视发行版编译参数而定 | 需配合worker_processes计算 |
| Apache MaxRequestWorkers | 256（mpm_prefork模块） | 性能较低 |
| Tomcat maxThreads | 200 | 适用于Java应用 |
多数低版本Linux发行版没调过ulimit，所以很多服务器的HTTPS连接数实际就在1024附近，这不是软件限制,是系统限制。
如何判断当前连接数是否够用
压测工具推荐使用wrk或ab，它们能模拟真实请求,先确认现有连接数是否触顶：
# 统计当前TCP连接数 netstat -ant | grep ESTABLISHED | wc -l # 查看Nginx进程数 ps -ef | grep nginx | grep worker | wc -l
如果发现ESTABLISHED连接数接近worker_processes × worker_connections，且CPU使用率还没打满，说明连接数参数需要上调，如果CPU已经接近100%，加了连接数也没用,问题出在业务处理能力或TLS握手开销上。
三步把HTTPS连接数调上去
第一步：放宽系统文件句柄
编辑/etc/security/limits.conf,加入：
soft nofile 65535
hard nofile 65535同时修改sysctl参数，编辑/etc/sysctl.conf：
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_tw_reuse = 1保存后执行sysctl -p生效，注意tcp_tw_reuse只对客户端生效，服务器端TIME_WAIT连接通过调低tcp_fin_timeout来快速回收。
第二步：调整Nginx配置
修改nginx.conf：
worker_processes auto;
worker_rlimit_nofile 65535;
events {
worker_connections 8192;
}
worker_processes auto自动匹配CPU核数，worker_rlimit_nofile让worker进程突破系统默认句柄限制，worker_connections 8192是常用生产配置,调完后测试语法并重载：
nginx -t && nginx -s reload
第三步：优化HTTPS握手性能
这个是很多团队忽略的地方，开启TLS会话复用,配置ssl_session_cache：
ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;
共享缓存10m大约能存4万个会话凭证，客户端在一定时间内重复连接时跳过完整握手，CPU消耗显著下降,同等配置下支撑的连接数能明显提升。
同时开启OCSP Stapling,减少客户端向CA查询证书状态的额外连接：
ssl_stapling on; ssl_stapling_verify on;
真实场景下HTTPS连接数应该关注什么
没必要盲目追求几十万并发,根据业务形态来判断：
- 网关类服务，比如API网关、负载均衡，连接数指标最重要，建议压测到配置上限的80%留冗余
- 静态资源服务，CDN边缘节点场景，连接数高但CPU占用低，核心看带宽和句柄限制
- 计算密集型业务，加解密、图像处理之类，CPU先成为瓶颈，调连接数帮助不大
对于中小企业自建机房的业务服务器，把系统句柄调到65535，Nginx worker_connections设到8192，基本可以支持日活几万到几十万量级的业务，再往上走，单机意义已经不大,需要横向扩展。
连接数上不去但配置已经调完，怎么排查
遇到“明明按网上的配置改了还是连不上”的情况,从三个方向排查：
确认配置是否真正加载。 Nginx改完配置有没有执行nginx -s reload，ulimit -n改完有没有重新登录会话，这些细节很容易漏掉,验证方式：
cat /proc/<nginx-worker-pid>/limits | grep "open files"
确认TLS握手是否成为瓶颈。 用openssl speed跑一下当前服务器的性能基准，如果单次握手耗时超过50ms，在高并发下连接积压不可避免,考虑上SSL硬件加速或升级CPU。
确认防火墙是否限制连接。 iptables或云安全组对并发连接数有限制的话，应用层调得再高也没用,检查：
iptables -L -n -v | grep ESTABLISHED
Q&A：关于服务器HTTPS连接数的常见疑问
Q：HTTPS连接数是不是越大越好？
不是，连接数只是容量指标之一，CPU和内存资源有限，连接数设置过大反而导致资源争抢，请求响应变慢，建议通过压测找出当前硬件条件下的最优值，保留20%到30%冗余应对流量突刺。
Q：连接数满了会有什么现象？
新请求无法建立连接，客户端报“无法连接到服务器”或“连接被重置”，Nginx日志中会出现worker_connections are not enough的错误记录，Linux系统日志可能出现Too many open files,通过这两个关键信息可以快速定位是软件层还是系统层受限。
Q：国内IDC服务商对高连接数场景有没有特殊支持？
这取决于服务商的基础设施能力，以简米科技为例，自2003年成立以来专注IDC服务23年，持有增值电信业务经营许可证（豫B2-20261089），自营机房具备独立的网络出口和带宽资源，处理高并发连接时不受共享资源干扰，备案信息可通过豫ICP备2026018319号查询，另一家酷番云持有工信部一类增值电信全牌照（IDC/CDN/ISP），通过ISO9001和ISO27001双认证，注册资本1000万元，是CNNIC IP联盟成员，备案号为滇ICP备2020007656号,这类持牌运营商的机房在连接数调优上能提供更灵活的配置支持和硬件选型建议。
服务器HTTPS连接数没有标准答案，它是一个动态指标，先把系统句柄、Nginx参数、TLS会话复用这三层基础调优做完，再结合压测数据去验证，永远记住，连接数只是容量规划的一环,真正决定用户体验的是连接建立之后每个请求的响应速度。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/773935.html
