内容摘要：下午三点，我盯着路由器后台的DNS缓存记录发愣。两个域名，old-shop.com和new-shop.com，解析结果都是203.0.113.7。同一个IP，两台完全不同的业务系统——一个跑着五年前的

下午三点，域名我盯着路由器后台的解析DNS缓存记录发愣。两个域名，域名old-shop.com和new-shop.com，解析解析结果都是域名203.0.113.7。同一个IP，解析两台完全不同的域名业务系统——一个跑着五年前的老商城，另一个是解析刚上线的微服务架构。这配置不是域名我写的，但我知道它为什么存在。解析

最直接的域名理由是迁移。老系统还在给部分客户服务，解析新系统已经接了一部分流量。域名把两个域名都指到同一台服务器，解析靠Nginx的域名server_name区分请求，比改数据库连接串快得多。运维同事图省事，直接在DNS控制面板里加了两条A记录，指向同一个地址。省事，但坑也埋下了。

具体说，问题出在证书上。老域名用的是单域名SSL证书，新域名是通配符证书。当两个域名共用同一个IP时，服务器必须靠SNI（Server Name Indication）来区分该返回哪个证书。老浏览器不支持SNI——比如还在用IE8的客户，访问老域名会直接报证书错误。这情况不多，但每次出现都让人抓狂。你没法在DNS层面解决，只能让老域名单独走一个IP，或者给老系统也换上支持SNI的证书。

更隐蔽的麻烦在日志分析。两个域名的访问记录混在同一个Nginx access log里，按域名拆开倒是容易——awk '$1=="old-shop.com"'就行——但排查问题时总得多一步。上周新系统半夜告警，我下意识先看IP，发现流量正常，再仔细一查，原来是老域名的爬虫在疯狂请求一个已下架的接口。如果两个域名不在同一个IP上，这种干扰根本不会发生。

话说回来，这种配置也不是全无好处。最直接的是省钱——一台服务器能扛两个域名的流量，硬件成本直接减半。对小公司来说，这吸引力很大。我见过一个朋友的公司，把官网、API、管理后台三个域名全指向同一台2核4G的云主机，跑了大半年没出过事。他们聪明在用了路径区分，而不是靠域名，所以Nginx配置反而更简单。

但长期看，我劝你别这么干。IP是稀缺资源，但更是故障隔离的边界。两个域名绑在同一个IP上，等于把鸡蛋放一个篮子里——DNS解析本身没问题，但一旦服务器被DDoS，两个业务一起瘫。你连个临时切换的余地都没有。DNS的TTL设得再短，也要等缓存过期才能换IP。

还有个细节容易忽略：备案。国内服务器要求域名备案，但备案是针对域名而不是IP的。两个域名都备案了，指向同一个IP没问题。但如果其中一个域名备案被注销，而它又和另一个域名共用IP，服务器可能会被运营商封禁——因为无法判断哪个域名违规。这种事我听说过不止一次。

所以，两个域名解析到一个IP，技术上可行，现实中常见，但只适合短期过渡或低风险场景。真要长期跑，还是老老实实分开。或者用CNAME指向一个负载均衡器，让均衡器转发到后端不同服务器——那又是另一套玩法了。但至少，别让两个业务共享一个IP还指望它们互不干扰。

下午四点，我把那两个域名的解析记录改了。老域名指向另一台备用服务器，新域名保持原样。五分钟内，DNS缓存刷新，世界清静了。