一个公网IP到底能挂几个HTTPS站：SNI、证书和反向代理该怎么排布

手上只有一块公网地址，防火墙上只开了一个 443，销售那边却排着队：这个季度要上四个品牌站、两个语言站，还要把三家客户的子站顺手托管进来。问「一个 IP 能挂几个 HTTPS 站」，得到的答案通常是「随便挂，SNI 搞定」——这话不算错，但它只回答了最小的一部分。真正决定这套排布能不能长期跑下去的，是另一个问题：这些站能不能接受共用同一个出口、共用同一个 TLS 终止点。

先把结论摆出来，后面的篇幅都是围绕这几条展开：

数量不是约束。SNI 让一个 IP 上的 HTTPS 站在理论上没有硬上限，实际天花板是内存、文件描述符、证书管理和运维复杂度，不是协议本身。

约束在共享。一个 IP 就意味着一个 PTR、一个发信出口、一个被风控识别的来源、一份被 DDoS 时一起被打的地址。这些是「共享」带来的，跟挂了几个站无关。

证书排布决定运维成本。单域、多域 SAN、通配符各有各的代价，选错的那一种会在第二年续期时把问题一次性还给你。

拆分的触发条件很具体。需要独立出口、需要独立 IP 归属、合同里写了实例隔离、某个站已经大到能拖垮邻居——出现任何一条，共享就该结束。

一、先把「IP 不够」和「端口不够」这两件事分开

很多人把这两个约束混成一件事，其实它们完全不在一层。端口是传输层的概念，一台机器上的 443 只有一个进程能监听（不考虑 SO_REUSEPORT 这类玩法），这是操作系统层面的事实，谁都绕不过去。IP 是网络层的概念，它决定的是「外面世界怎么找到你」。

HTTP 时代解决端口不够的办法是 Host 头：所有域名解析到同一个 IP，请求到达后在 HTTP 头里带着 Host: 字段，Web 服务器靠这个字段把请求分给不同的虚拟主机。这套机制用了二十多年，稳定得很。

HTTPS 的问题在于 Host 头被加密了。TLS 握手发生在 HTTP 之前，服务器要在还看不到 Host 头的时候就把证书发过去——它总得先知道该发哪一张证书。这就形成一个死锁：要看 Host 得先解密，要解密得先发证书，发证书又得知道是哪个域名。

SNI（Server Name Indication，服务器名称指示）就是打破这个死锁的那把钥匙。它是 TLS 的一个扩展，做的事情只有一件：让客户端在握手的第一条消息里，用明文把要访问的域名捎带过去。

二、SNI 到底改的是握手里的哪一步

握手顺序里 SNI 的位置

完整的 TLS 1.2 握手大致是这样：客户端先发 ClientHello，服务器回 ServerHello，紧接着发证书、密钥交换参数、ServerHelloDone，客户端再回密钥交换、切换加密套件、Finished，服务器回切换与 Finished。TLS 1.3 把往返压到一次，但 ClientHello 作为第一条消息的位置没变。

SNI 就挂在 ClientHello 里的扩展字段上。服务器收到 ClientHello，先读 SNI，拿这个域名去匹配自己的虚拟主机配置，选出对应的那张证书，然后再回 ServerHello。也就是说，SNI 起作用的位置在 ClientHello 之后、ServerHello 之前——它是服务器选证书的唯一的早期依据。

这里有个容易被忽略的性质：SNI 是明文。握手里被加密的部分从 ServerHello 往后才开始，ClientHello 里的 SNI 在整个链路上都是可读的。中间设备能看到你在访问哪个域名，只是看不到具体路径和内容。TLS 1.3 时代有了 ECH（加密客户端问候）来补这个洞，它需要 DNS 里发布对应的公钥记录，部署率还谈不上普遍，做架构设计时不该把它当成默认前提。

老客户端不支持 SNI 时，会发生什么

不支持 SNI 的客户端发出的 ClientHello 里没有这个扩展。服务器收不到域名，就只能走「默认虚拟主机」——通常是配置文件里排第一个的那个 server 块，或者显式标记了 default_server 的那个。它会把默认站的证书丢过去，客户端校验时发现证书上的名字跟自己要访问的域名对不上，直接弹证书警告。

注意，这不是握手失败，是握手成功但校验失败。用户看到的是红色警告页，很多老浏览器甚至连「继续访问」的按钮都不给。

真正在生产环境里还会撞上 SNI 缺失的，主要就这么几类：很老的 Windows 上的老版本 IE、一些停更的嵌入式设备的固件、早年写的 Java 应用（依赖的 JDK 版本没开 SNI 支持）、部分工业控制与 POS 终端的内置组件。现代浏览器、现代操作系统早已全部支持。

处理办法有三种，选哪一种取决于你的用户里这类客户端的占比：

第一种，认了。如果你的访问日志里这类请求常年低于千分之一，就别为它改架构。在默认虚拟主机上放一张自签证书或者直接返回 444 断开，让它明确失败，比给用户一个「看起来能继续但证书不对」的警告页要干净。

第二种，用默认证书兜底。在默认虚拟主机上放一张 SAN 证书，把最可能被老客户端访问的几个域名都列进去。这样老客户端至少能拿到一张名字对得上的证书。代价是这张证书里列出的域名会被写进证书透明度日志，等于公开宣告这些域名归同一个主体。

第三种，给它一块独立 IP。把需要兼容老客户端的那个站单独放到一个 IP 上，让那个 IP 的 443 只服务这一个站点。这是唯一彻底的解法，也是「什么时候必须加 IP」这个问题的第一个答案。

三、证书怎么排：单域、多域 SAN、通配符各自的账

SNI 解决了「服务器怎么知道该发哪张证书」，没解决「这些证书该怎么买、怎么管」。这一层的决策直接影响你未来每一年的运维工作量。

单域证书：一张证书一个名字

最朴素的做法，每个域名一张证书，各管各的。优点是边界清晰：某个站下线了，把它的证书删掉就好；某个站的私钥泄露了，只需轮换这一张；续期失败只影响这一个站。

代价是数量。二十个域名就是二十张证书、二十个续期任务、二十份监控。自动化签发工具（ACME 协议那一类）能把续期这件事基本做成无人值守，但「二十份配置」这个复杂度不会消失——尤其是当这些站分属不同团队、证书签发需要走不同审批的时候。

另外要注意签发频率限制。免费证书服务对同一个注册域在单位时间内的签发张数有上限，同一个域名重复签发也有上限。站点数量上百的时候，这个限制会真的咬人，需要提前规划成按域名分组的 SAN 证书。

多域 SAN 证书：一张证书扛一批域名

SAN（Subject Alternative Name，主体备用名称）字段允许一张证书里列出多个域名。这种证书常被称为多域证书或 UCC 证书。它把二十张证书压成两三张，续期任务从二十个变成两三个。

优点很实在：管理对象少了，出事时的影响面也可控（一张证书挂了，受影响的正好是它覆盖的那批站）。同一批站点的到期日被强制对齐，反而避免了「每个站不同时间到期、每个月都要处理续期」的碎片化状态。

代价有两条，第二条最容易被忽略：一是改动要重签。新增或删掉一个域名，这张证书得重新签发、重新部署，不是加一行配置就能生效。二是名单是公开的。所有公开信任的证书都会被写进证书透明度（CT）日志，任何人都能查到这张证书里列了哪些域名。你还没发布的品牌、还没公开收购的子品牌、给客户托管的子站，都会因为共用一张 SAN 证书而被关联到一起。

给客户托管子站时，这一点尤其要跟对方讲清楚。客户的域名出现在你的证书里，意味着外界可以查证「这个域名和另外十几个域名在同一张证书上」，有些客户对此非常敏感。

通配符证书：子域的批量解法

通配符证书的形式是 *.example.com，能覆盖该域下的任意一级子域。多语言站、客户子站这类场景很合适——cn.example.com、jp.example.com、clientA.example.com 全都在覆盖范围内，新增子域不需要改证书。

三个坑要提前知道：

只覆盖一级。*.example.com 覆盖 a.example.com，但不覆盖 a.b.example.com。二级子域要么另开一张 *.b.example.com，要么就得把具体名字写进 SAN。

主域不一定包含。不少 CA 签发的通配符证书会同时把 example.com 作为 SAN 加进去，但这是个实现细节，不是规范保证，签发前要确认。

私钥共享范围太大。一张通配符证书的私钥要部署到所有用它的服务器上。任何一台机器出问题，影响的是全部子域。站点跨多台机器、跨多个团队时，这个风险敞口比单域证书大得多。

混排才是常态

真实环境里很少只用一种。比较稳的排法是：主品牌站用单域证书（或者一张只包含自家主域的 SAN），语言站与客户子站走通配符，长期不变的边缘域名合并进一张 SAN。判断标准就一条——把「会一起变动、可以一起暴露」的域名放在同一张证书上。

四、反代层怎么分：虚拟主机、上游、连接复用

证书决定「能不能握手成功」，反代层决定「握手之后请求去哪」。这一层的排布直接影响故障隔离的粒度。

虚拟主机与上游的映射关系

标准结构是：最外层一个监听 443 的 server 块（或一组按 SNI 分流的 server 块），通过 server_name 匹配域名，每个 server 块用 proxy_pass 指向自己的上游。上游可以是本机的另一个端口，也可以是另一台机器。

这里有个细节值得咬文嚼字：server_name 匹配的是 SNI 值，还是 Host 头？两者都可以参与匹配，但配置不当会出现不一致——用户用 IP 直接访问、或者 SNI 里填 A 域名而 Host 头填 B 域名时，就可能走到错误的虚拟主机。生产环境应该显式禁止 IP 直接访问（配置一个 default_server 返回 444），并且在转发时把 Host 头显式传给上游，别让上游靠猜测判断自己在服务谁。

转发给上游时，这几个头要处理干净：Host 传原始值，X-Forwarded-For 里拼上真实客户端 IP，X-Forwarded-Proto 标成 https，X-Forwarded-Port 标成 443。上游应用如果拿不到正确的协议与端口，生成出来的绝对链接会全是 http，跳转链条立刻出问题。

HTTP/2 与连接复用

HTTP/2 靠 ALPN 在握手里协商，协商发生在证书之后、应用数据之前，所以跟 SNI 不冲突。开 HTTP/2 之后，浏览器对同一个源只会开一条连接，多路复用在上面跑。

共享 IP 加共享证书时会出现一个额外现象：连接合并。如果两张证书覆盖的域名解析到同一个 IP，且证书同时有效，浏览器可能复用同一条连接去请求另一个域名。好处是少握手、少建连；代价是两个站在链路上被明确关联起来。对自家品牌站来说无所谓，对客户托管子站来说又是那个「被关联」的问题。

反代到上游这一段，通常还是 HTTP/1.1 加长连接。上游开启 keepalive 连接池，避免每请求都重建连接。这里容易踩的坑是连接池太小：并发一上来，反代与上游之间的连接数成为瓶颈，表现出来的现象是反代日志里大量上游超时，而上游自己负载很低。

TLS 终止点放哪一层

常见做法是终止在最外层反代，反代到上游走明文 HTTP。好处是证书只在一处管理，上游不需要关心 TLS；代价是反代与上游之间的那段链路是明文，所以这段必须落在内网或者本机回环上，不能跨公网。

合规要求高的场景会把 TLS 一直透传到应用（用流转发而非七层代理）。代价是反代看不到 HTTP 内容，没法做基于路径的分流、缓存、WAF 规则，证书也得在每个上游各自部署一遍。中小企业多品牌站这种场景，七层终止是明显更划算的选择。

五、共享出口带来的连锁影响

这一节是全文的重点。前面讲的都是「怎么做到」，这一节讲的是「做到之后你要接受什么」。

发信：PTR 是按 IP 来的

反向解析（PTR / rDNS）记录挂在 IP 上，不挂在域名上。一个 IP 只有一条 PTR。所以多个站点共用一块地址发信时，所有域名的信都从同一个反向名字出去。

SPF 可以在各个域名自己的记录里声明这个 IP 为合法发信源，DKIM 更是按域名各自签名，这两样不受共享影响。真正受影响的是IP 段的信誉本身：收件方统计的是这个 IP 的投诉率、退信率、垃圾命中率。只要其中一个站的邮件行为失控——买了名单、发了没退订口的营销信、被投诉到封——同一个 IP 上其他站的正常订单邮件会一起进垃圾箱，而且这种牵连不会因为你「每个域名都配了 SPF」而减轻。

结论很直接：事务性邮件（订单通知、验证码、账单）和批量营销邮件不要从同一个出口发，哪怕它们属于同一个 IP 上的不同站。前者走专用发信服务或者独立出口的 IP，后者另开。这个问题在共 IP 场景里会被放大，因为所有站共用同一个信誉池。

风控：IP 是识别维度之一

支付网关、登录风控、广告平台、第三方 API 的访问控制，很多都把来源 IP 作为一个识别维度。共享出口意味着你的四个品牌站在这些系统眼里是同一个来源。

日常经营里这通常不是问题。但出现下面几种情况时会变成真问题：某个站触发了风控被限流，其他站的调用一起被限；某站的合作方要求把你的出口 IP 加入白名单，结果等于把白名单给了所有站；多品牌站本来是刻意做品牌隔离的，结果在第三方系统里被归到同一个实体。

还有一类容易忽略的：IP 的地理归属。搜索引擎、内容分发、广告投放都会把服务器 IP 的地理位置作为弱信号参与判断。多个面向不同地区的语言站共用一块地址，等于主动放弃了「按地区分别落点」这个手段。

日志归属：不拆开就等于没日志

所有站的反代如果共用一个 access_log，出问题的时候你拿到的是一份混在一起的记录，只能靠域名字段去 grep。这在流量小的时候勉强能用，流量一大就是灾难——你要统计某个客户子站的慢请求占比，得先把整份日志过滤一遍。

正确做法是按虚拟主机拆日志文件，日志格式里带上 $host、$request_time、$upstream_addr、$upstream_response_time、$status。最后两个字段决定了你能不能在三分钟内判断「是反代慢还是上游慢」而不是靠猜。错误日志同理按 server 拆开。日志保留周期和归属也要提前定好，客户子站的日志能不能和客户自己的分析系统对接，最好写进合同。

故障隔离：共享的粒度就是爆炸半径

共用反代进程，意味着下面这些故障是「一站出事、全站陪葬」级别的：

配置 reload 失败。某个站的配置写错了语法，reload 整体失败，所有站一起用旧配置继续跑——这还算好的。更糟的是配置语法没错但语义错，reload 成功，所有站一起按错误配置跑。

证书续期失败。自动续期脚本卡住、某张证书签发失败、磁盘满了写不进新证书，reload 之后受影响的可能不止那一个站。

资源被单个站吃光。某个站被爬虫扫、被 CC 打、上传了大量大文件，连接数、内存、临时目录被占满，其他站的请求排队。

共享模块出问题。反代上装的通用模块（缓存、WAF、Lua 脚本、鉴权）一旦有 bug，影响的是全部流量。

能做的缓解措施有限但有用：配置变更先做语法检查再 reload；证书续期与 reload 分开，续期失败不要触发全局 reload；按站限制连接数与请求体大小；关键站点单独放一个反代实例。但这些全是缓解，不是隔离——真正的隔离只有进程级和实例级两种。

六、一张表看清几种排布

七、什么时候必须拆：四条具体的触发线

共享不是慢慢变坏的，它通常是在某一天突然不成立。下面四条是我在实际排布里认定的硬触发线，命中任意一条就该拆，不要指望靠配置技巧绕过去。

触发线一：需要独立发信出口

只要某个站承担了面向客户的批量邮件，或者订单类邮件量大到退信率、投诉率会影响收件方对该 IP 的判断，它就需要自己的 IP 和自己的 PTR。这条线不看站点流量大小，只看邮件行为。一个日访问量两百的站，只要它在发营销信，就能把同 IP 上日访问量两万的站的订单邮件一起拖进垃圾箱。

触发线二：需要独立 IP 归属

合作方白名单、第三方风控按 IP 判定、行业审计要求「本系统独立地址」、客户合同里写明「独立出口」——这些都是硬性的。它们不看你的架构多优雅，只看这个 IP 上还挂着谁。给客户托管子站时尤其要注意，很多客户自己不知道该提这个要求，等到审计时才来问，那时候再迁就麻烦了。

触发线三：需要实例隔离

合同写了独立实例、合规要求数据不出某个边界、某个站的流量已经大到它的峰值会挤压邻居——这几种情况要拆到实例级。注意这里说的是实例，不只是进程：同一台机器上的两个进程仍然共享内核、共享磁盘、共享网络栈，磁盘打满和内核参数踩坑一样会互相影响。

触发线四：攻击面已经不对等

某个站因为业务性质常年被打、或者被某个来源盯上，而同 IP 上的其他站是无辜的。共享 IP 意味着防护是 IP 级的，攻击流量上来时防护动作（清洗、黑洞、限流）会作用在所有站上。这种时候拆出去，不只是保护别人，也是保护这个站自己——它需要一个可以按自己节奏调防护策略的地址。

真到要拆的时候，选型的思路是「先拆实例还是先加 IP」。如果只是要进程隔离与资源保障，增开实例、共用原有出口往往就够；如果要的是出口身份的独立，那就必须落到独立 IP 上。一万网络这边深耕 IDC 19 年（成立于 2007 年），这两条路都能走：弹性云一万云 ¥25 起适合先做实例级拆分试水，需要独立出口与更完整的隔离时可以选中国香港自营 E3 8G / 10M CN2 ¥1500/月这一类整机，也可以上裸金属 E5-2620 32G/1T ¥999/月（海外节点有买 1 送 1 的活动，以官网实时活动为准）。有一点要提前问清楚：额外 IP 通常属于套餐外的增项，签约前务必确认套餐内赠送的 IP 数量、增购单价和上限，别等上架了才发现一个地址加不上去。

八、中小企业多品牌站的一套可落地排布

把前面的判断落到具体机器上，一套比较稳的排布是这样的：

网络层：一块公网 IP，安全组只放 80 与 443，80 只做跳转不提供内容。IP 直接访问一律断开，不让默认虚拟主机泄露任何信息。

反代层：单个反代实例，按 server_name 分虚拟主机，每个虚拟主机独立 access_log 与 error_log，日志格式带 $upstream_addr 与 $upstream_response_time。每个站单独设连接数上限与请求体大小上限。反代与上游之间走本机回环或内网。

上游层：流量小、信任度一致的站共用上游进程，靠目录与配置隔离；流量大、客户托管、或者属于不同团队的站，各自独立进程或独立实例。

证书层：主品牌站各用单域证书；语言站与自家子业务走通配符；需要保密归属关系的客户子站单独签发，不并入任何 SAN 证书。所有证书统一纳入到期监控，到期前三十天告警。

发信层：整台机器默认不开放 25 端口出方向，所有事务性邮件走第三方发信服务或独立出口的专用 IP。这条规则写进部署文档，不靠人记住。

变更层：配置变更走「检查语法 → 灰度 reload → 验证关键域名 → 全量」的固定流程；证书续期与 reload 解耦，续期失败只告警不触发全局动作。

九、避坑指南

坑一：把「IP 够不够」当成采购时唯一要问的问题。为什么坑——IP 数量是采购阶段最容易谈的指标，谈完了大家就以为架构问题解决了。实际上发信信誉、风控识别、故障隔离这些约束一个都没被讨论。怎么避——在下单前先列出「这些站里有没有需要独立出口的」，把结论写进采购需求，而不是等上架后再改。

坑二：为了省事把所有域名塞进一张 SAN 证书。为什么坑——证书透明度日志是公开的，任何人都能查出这张证书上的完整域名列表。未发布的品牌、客户的域名都会因此被关联。怎么避——按「能不能一起公开」分组签发，不能公开的单独签。

坑三：日志不分文件，出问题全靠 grep。为什么坑——反代日志是唯一能同时看到客户端与上游两侧的视角，混在一起之后这个视角的价值直接归零。怎么避——按虚拟主机拆文件，格式里必须带上上游地址与上游耗时。

坑四：证书自动续期失败会连带其他站。为什么坑——很多续期脚本的逻辑是「续完就 reload」，任何一张证书失败都会触发全局 reload，把没问题的站也卷进来。怎么避——续期与 reload 分开，只对成功变更的证书做定向生效，失败只发告警。

坑五：默认虚拟主机没处理，IP 直接访问暴露了内部站点。为什么坑——扫描器整天在扫 IP，一个没配 default_server 的反代会把某个站当成默认站返回出去，等于白送一个入口。怎么避——显式配置默认虚拟主机返回 444，并且定期用 IP 直接访问自检一遍。

多站共用 IP 时，最常被追问的六个问题

不支持 SNI 的老客户端还能访问吗？

能握手，但拿到的证书名字对不上，浏览器会弹证书警告，多数老浏览器连「继续」的选项都不给。处理上先看你自己的访问日志里这类请求占多少：低于千分之一就别为它改架构，在默认虚拟主机上返回 444 让它明确失败；如果确实有一批老终端要服务，就把那个站单独放到一块 IP 上，让那块地址的 443 只服务它一个。用 SAN 证书兜底也能缓解，但要接受证书名单被公开这件事。

通配符证书能不能覆盖所有子域？

只覆盖一级。*.example.com 能覆盖 a.example.com，覆盖不了 a.b.example.com，主域 example.com 也不一定自动包含（很多 CA 会作为 SAN 加进去，但要在签发时确认）。如果你的业务会用到多级子域，要么为每个二级前缀再开一张通配符，要么把具体名字写进 SAN。另外要记住私钥是共享的，一张通配符证书部署到十台机器上，任何一台出事影响的是全部子域。

多个域名共用一个 IP 会不会影响 SEO？

共用 IP 这件事本身不是排名因素，搜索引擎判断的是内容、链接、结构化数据和用户体验信号，不会因为两个站解析到同一地址就降权。需要说清楚的是本文讨论的范围：一家企业自己的多个品牌站、多语言站，以及托管在同一台服务器上的客户子站——这是资源约束下的架构排布问题。它和「在同一批地址上批量铺设大量内容站点」是完全不同的两件事，后者涉及的是内容质量与操纵排名的判断，不在本文讨论范围内。真正会因为共 IP 而受影响的不是收录，而是前面讲的发信信誉、风控识别与故障隔离。

其中一个站被攻击，其他站会不会受牵连？

会，而且是在两个层面上。IP 层面上，DDoS 打到这个地址，清洗与黑洞动作作用在所有站上，邻居站一起不可达；应用层面上，CC 打某个域名会占满反代的连接数与内存，其他站的请求跟着排队。能缓解的手段有限——按站限连接数、限请求速率、把重点站单独放实例——但这些都不是隔离。如果这个站长期被打，唯一干净的解法是把它拆到独立 IP 与独立实例上。

什么时候一定要加独立 IP？

四条具体的线：一是需要独立发信出口，事务邮件或批量邮件量大到信誉会影响其他站；二是需要独立 IP 归属，合作方白名单、第三方风控、行业审计或客户合同里有明确要求；三是需要实例级隔离，且要求落到网络出口上而不只是进程上；四是攻击面长期不对等，某个站常年被打而邻居是无辜的。反过来说，纯展示型企业站、没有邮件需求、没有风控识别需求、没有隔离约定的多品牌站，共享一块地址完全够用，没必要为「看起来更专业」去加。

反代挂了是不是所有站一起挂？

是，这是共享反代最直接的代价，也是这个架构里最大的单点。能做的只有两件事：一是降低反代自己挂掉的概率（配置变更先检查语法、限制单个站的资源占用、证书续期不触发全局 reload、反代实例本身做健康检查与自动拉起）；二是缩短挂掉之后的恢复时间（配置纳入版本管理、保留可快速回滚的历史版本、上游保持无状态以便随时重建）。如果某个站重要到不能承受这个单点，它就不该待在这套共享反代下面。

证书续期失败会不会牵连其他站？

取决于你的续期脚本怎么写。常见的问题是「续完就 reload」，任何一张证书签发失败都会触发全局 reload，把没问题的站一起卷进来。正确的做法是续期与生效解耦：只对成功签发的证书做定向生效，失败的只发告警并保留旧证书继续服务（只要还没到期，旧证书仍然是有效的）。另外记得把到期监控放在证书之外——监控要检查的是「线上实际生效的证书还剩几天」，而不是「续期任务有没有跑成功」，这两者在任务静默失败时会给出完全不同的答案。

免费证书和付费证书在共享 IP 场景里怎么选？

从协议层面看没有区别，共享 IP 与否都不影响证书的信任链。差异在三个地方：有效期（免费证书通常有效期更短，意味着续期频率更高，站点多的时候这个频率会放大运维负担）、签发频率限制（同一个注册域在单位时间内的签发张数有上限，域名数量上百时需要靠 SAN 证书合并来规避）、以及责任与保险（付费证书通常带一定的赔付与身份核验，涉及交易与客户的站点更倾向这一类）。自家品牌站用免费证书完全没问题；给客户托管且合同里有责任约定的，多半得走付费的 OV 证书。

结语

回到开头那个问题——一个公网 IP 到底能挂几个 HTTPS 站。技术上答案是「没有硬上限」，但这不是这道题的关键。真正要回答的是：这些站能不能接受共用同一个出口、同一个 TLS 终止点、同一份 IP 信誉、同一个爆炸半径。能接受，SNI 加一套规整的反代和证书排布就能长期跑下去；不能接受，加多少配置技巧都是在拖延。判断顺序应该是先过一遍发信、风控、日志、隔离这四条线，再决定要不要共享，而不是先把站都堆上去、等出事了再拆。

数据来源：本文涉及的协议与产品机制说明参考公开技术文档与行业通用实践，服务器相关产品与价格信息参考一万网络官网（https://www.idc10000.net/）公开页面，具体以签约时最新报价与合同为准。