去年年底我接了一个站群客户的活儿，客户一开口就是"我买了 32 个 C 段、900 多个 IP，怎么网站反而全收录不动了"。那台机器在 raksmart 这类商家手里算是典型的多 IP 独立服务器配置，端口带宽给得也足，硬件一点问题没有。我花了小半个月把机器上的东西翻了个底朝天，最后发现根源不在服务器，在 IP 的分法上。
站群这行当有个天然的矛盾：机器是按"能挂多少站"来卖的，可搜索引擎是按"这是不是一个值得信任的站"来判的。前者鼓励你把 IP 铺开、把站铺多，后者却在拼命找这些站之间的联系。我把这件事拆成了几个可以动手验证的判断方法，写在下面。raksmart（多 IP 独立服务器与站群方案） 如果你也在挑机器，先把 IP 段怎么分、带宽怎么留余量这两件事想明白，再看配置表会踏实很多；线路和 IP 质量这块也可以参考 zorocloud（CN2 GIA / 9929 / CMIN2 精品线路） 的说明做横向对比。
很多人以为搜索引擎判断"站群"是看 IP 段，其实 IP 段只是最容易被观察到的那一层。真正会被系统拿去做关联分析的信号至少有四类：
第一类是网络层。同一个 C 段里的 IP，搜索引擎爬虫抓到的响应头、Server 指纹、TLS 证书签发记录、默认首页截图往往是高度相似的。这一层不针对任何具体 IP，是看"这一段地址上的东西像不像"。
第二类是内容层的相似度。站群里最常见的做法是同一套模板、同一批文章改改标题就上线，机器人在抓的时候很容易把页面归到同一个模板簇里。第三类是行为层，几十个站互相交叉链接、在同一时间点集中提交 sitemap，这种模式在爬虫的日志里非常显眼。第四类才是注册信息层面的痕迹，也就是域名注册商、注册人邮箱、解析用的 NS 这类。
这四类信号是叠加的。你只隔离了其中一类，剩下的三类照样能把站连起来。这也解释了为什么很多站群客户明明买了不同 C 段、以为万无一失，搜索表现却还是一落千丈。
这是我在那台机器上看到的第一个问题。客户为了"分散"，把三十个站塞进了十二个 C 段，每个 C 段放两三个站，以为这样每个段里都只有两三个"干净"的站，搜索引擎就无从判断了。
实际上这样做把最珍贵的东西浪费掉了。一个 C 段里只有两三个站，意味着你为每个站付出的 IP 数量翻了几倍，而每个站能分到的带宽和资源却没变。更麻烦的是，你的 IP 池在外部看起来极其"专业"同一台机器上几十个 C 段、几百个 IP、模板还高度一致，这本身就是一种比"同段多站"更醒目的特征。
我的做法是反过来：让 C 段的数量少于站的总数，但每一个段里放足够多的站，把这个段做成一个"看起来正常的、有自己内容结构的站点集合"。同时段与段之间的差异要拉大不同的服务器软件、不同的 TLS 证书链、不同的页面模板体系，甚至不同的响应头顺序。这比单纯买更多 C 段有效得多。
第二个问题更实际。很多站群客户买的是"1Gbps 优化带宽、不限流量"的独立服务器，看起来带宽完全够用。但站群的真实负载分布是极度不均的：SEO 类的站流量很小，而几个做下载、接口中转、素材代理的站会把出口吃满。
更要命的是服务器自身的流量。这台机器上跑着自动采集、批量发布、缓存预热、定时任务同步，这些东西在业务低谷时就能把出口占掉三成，等到白天真正要服务访客的时候，剩下的带宽已经不是广告上那个数字了。更麻烦的是，一旦出口打满，同 IP 段的所有站会一起变慢，搜索引擎抓取超时率上升，收录自然跟着掉。
我的经验做法是给站群做一个简单的带宽预算表：先测出业务高峰期的真实出向流量，再把采集和发布任务挪到低峰时段跑，最后给出口留至少三成的余量。如果商家给的端口带宽是共享的，还要问清楚并发连接数和超售比这两个数字不限流量的机器最怕的就是这条线。
第三个坑是很多客户完全没意识到的：机器上几十个站的"基础设施指纹"几乎一模一样。这些细节跟 IP 段没关系，但搜索引擎一个都不用费劲就能拿到。
具体来说有这些：所有站用同一个默认 favicon；Nginx 版本号和 Server 头完全一致；站点根目录用的是同一个默认欢迎页模板；robots.txt 是同一份复制粘贴的；每个站都开着同一个统计脚本的同一份代码。最典型的是错误页访问不存在的路径时，404 页面长什么样，如果三十个站一模一样，那就是三十份签名。
还有两个容易忽略的：一是解析。如果所有站都把 NS 指向同一个解析服务商的同一个账户，或者用同一份 CDN 回源配置，关联度会被直接拉满。二是反向解析（RDNS）。很多批量开出来的 IP 段默认没有配 RDNS，或者全部配成同一个主机名，这一条基本上等于在脸上写"我这里是批量业务"。
我的做法是给每个站做一张"基础设施差异表"，逐项填上：服务器软件、TLS 签发机构、favicon、404 页面、robots 规则、统计代码、CDN 节点、RDNS 主机名。填完之后你会发现，能改的成本比想象中低，而改完之后的关联度下降非常明显。这一步做完，再去考虑多 C 段的事，效率高得多。
把上面的东西串起来，我自己现在用的顺序是这样：第一步，先定内容矩阵，把要做的站按主题拆成几个互不重叠的组，组和组之间不要共用模板。第二步，确定需要多少个站，而不是需要多少个 IP，倒过来推机器配置。第三步，按"少量 C 段、段内多站、段间差异大"的原则去分 IP，同一段里的站共享出口但基础设施指纹各不相同。第四步，做带宽预算表，给后台任务和真实访客之间划一条明确的线。第五步，铺差异化清单，逐项落实服务器软件、证书、favicon、404、统计代码、RDNS。第六步才是持续观察收录变化，看哪个环节还有异常再回头调。
如果顺序反了先买一堆 IP 段、再想内容怎么排大概率就是客户找我之前的状态：机器配置看着很豪华，站点却一个都推不出去。IP 资源是站群里的消耗品，不是护身符；真正决定搜索端表现的是内容差异化和基础设施指纹这两件反直觉的事。
最后多说一句，选机器的时候别只盯着"多少个 C 段"这一个数字。独立服务器的稳定性、售后响应速度、能不能加 IP 加段，这些在你需要调整分法的时候价值最大。我自己核对的时候，会要求把端口带宽、并发连接、IP 段的实际可扩展方式这几项写在报价单上，而不是只留一句"多 C 段可选"。
