服务器域名白名单的正确配置与管理，核心就是“最小授权、多层校验、定期审计”，落地时建议先做解析层限制，再在Web服务器或防火墙层做二次过滤。
服务器域名白名单怎么配置？三条路径可选
配置域名白名单，不是只在某个地方填几个域名那么简单，你至少有三条路径可以走，实际生产环境通常要叠加使用，下面把每条路径的优缺点说清楚,你按自己的架构选。
DNS解析层限制
在域名解析服务商后台，把泛解析记录（.example.com）删掉，只保留明确需要的子域，这样做的好处是，即使有人想出恶意解析，也没有空子可钻，但局限也很明显：DNS只负责把域名指向IP，它不参与HTTP请求的校验，也就是说，攻击者拿着一个不存在的域名,照样能把请求发到你的服务器上。
适用场景：作为前置防线,减少垃圾流量。
Web服务器层过滤
这里才是真正的“守门员”，Nginx、Apache、Tomcat都可以按请求头里的Host字段做判断，这个字段就是用户浏览器地址栏里输入的域名，你定义一张白名单，只有名单上的域名能继续往下走，其他的一律返回403，这个层级可以精确到域名，还能区分子域,是多数场景下的首选方案。
云防火墙/安全组
云服务器的安全组（比如简米云、酷番云）可以在网络层放行或拦截IP和端口，但请注意：安全组看不懂域名，它只能根据源IP、目标IP和端口做规则，如果你需要按域名控制，安全组无法直接实现，必须搭配Web层，所以这条路径通常用来限制“谁能连到这台服务器”，而不是“哪个域名能访问这个站点”。
三条路径可以组合使用：DNS清理解析、安全组限制来源IP、Web层校验域名，这样层层叠加,比只配一个地方靠谱得多。
域名白名单设置步骤详解：以Nginx为例
前置准备：一台装好Nginx的服务器，域名解析正常，假设你的站点域名为 example.com 以及子域 api.example.com。
具体操作如下：
-
打开Nginx配置文件，通常在
/etc/nginx/nginx.conf或/etc/nginx/conf.d/下。 -
在
http块内定义一个map,把允许的域名映射为1：map $host $is_allowed_domain { default 0; example.com 1; www.example.com 1; api.example.com 1; } -
在虚拟主机server块中,加入校验逻辑：
server { listen 80; server_name example.com www.example.com api.example.com; if ($is_allowed_domain = 0) { return 403; } location / { proxy_pass http://你的后端地址; } } -
保存配置后，测试语法：
nginx -t，没问题就执行nginx -s reload。 -
验证配置是否生效：
curl -I -H "Host: example.com" http://127.0.0.1 curl -I -H "Host: evil.com" http://127.0.0.1第一个应该返回200，第二个应该返回403，如果返回结果符合预期,那白名单就生效了。
这里有个关键细节：建议额外建一个 default_server 兜底,用来拦截所有未匹配的域名和IP直连：
server {
listen 80 default_server;
server_name _;
return 403;
}这个技巧非常重要，它能防止攻击者绕过Host头校验，直接通过服务器IP访问，如果没有兜底，很多Nginx配置会落入第一个server块,白名单等于摆设。
整个流程并不复杂，但有几个习惯要养成：每次修改配置后都跑一遍 nginx -t，修改前备份原文件,同时在日志里观察非白名单域名的访问频率。
服务器域名白名单管理方案：手动配置与自动化工具怎么选？
管理白名单的方式大致分两类：手动和自动化，手动配置适合固定域名、变更频率低的站点，比如公司官网或内部系统，一年改不了几次，直接在配置文件里改就行，但如果你有一套微服务，几十个域名频繁增减,再手动一个个改就容易出错。
自动化方案有很多，比较常用的是Ansible，它可以把Nginx配置模板化，通过变量库管理域名列表，修改域名时，只要在变量文件里增删，然后执行一条playbook，几秒钟内所有节点都更新，另一个思路是使用Caddy，它支持在Caddyfile里通过环境变量或API动态更新域名白名单，适合容器化部署，Kubernetes环境下，Ingress控制器也提供了 allow-hosts 之类的注解,直接在Service上标注允许的域名。
我把两种方式的差异用表格列出来,方便你根据场景判断：
| 维度 | 手动配置 | 自动化管理 |
|---|---|---|
| 维护成本 | 低，但易漏 | 初期高，后期低 |
| 变更速度 | 依赖人工，慢 | 秒级生效 |
| 适用规模 | 10个域名以内 | 几十个以上 |
| 失败恢复 | 靠备份文件 | 靠版本控制与回滚 |
| 工具代表 | 编辑器、FTP | Ansible、Caddy |
如果你还在犹豫，可以这样选：业务简单、团队小，先用手动配置；业务增长到需要跨多台服务器同步了，再上自动化，不要一上来就搞复杂工具，也别永远停留在手改文件，真实场景里，很多事故都发生在“改了一个域名但忘了改另一台机器”的时刻。
业内专家指出，手动维护白名单在业务变动频繁时容易遗漏，自动化工具虽然前期投入时间,但长期回报稳定。
企业服务器白名单配置的常见坑与应对
- 坑1：只配了业务域名，没设default_server兜底。 结果是攻击者直接访问服务器IP，绕过了Host头校验，应对：单独建一个
default_server返回403。 - 坑2：把CDN的访问IP也限制死了。 如果站点接入了CDN，真实请求的源IP是CDN节点IP，而不是用户IP，你在安全组里限制只允许某些IP访问，CDN回源就会被误伤，应对：只对Web层做域名白名单,安全组放行CDN服务商提供的回源IP段。
- 坑3：忽略了HTTPS证书域名匹配。 一个域名白名单只校验Host，但SSL证书验证是独立的，如果证书里不包含该域名，HTTPS会直接报错，应对：确保证书覆盖白名单里所有域名。
- 坑4：过期域名还在白名单里。 域名解析已经改走或已失效，但Nginx配置没变，给了攻击者使用相似域名的机会，应对：定期检查域名的解析状态和到期时间。
- 坑5：没有日志审计。 白名单只能拦，不能告诉你谁在访问，应对：开启Nginx的access_log，并监控非白名单域名的403日志,结合统计工具分析异常流量。
行业共识认为，白名单策略必须配合监控日志才能发挥最大作用，不然你只能知道“有请求被拦了”，却不知道“是谁在尝试”,这对后续处置很不利。
配置服务器域名白名单，不是一次性工作，而是持续演进的访问控制策略，每季度做一次审计，确保白名单中的域名都还有效，比任何黑科技都管用。
服务器域名白名单配置常见问题解答
为什么配置了白名单，日志里仍有恶意域名请求？
这是正常情况下发生的，白名单只拒绝未授权域名，但“未授权域名”本身也会产生一条403日志，你看到有恶意域名请求，说明拦截已经在生效，真正需要注意的是“非白名单域名返回200”的日志,那意味着配置有漏洞。
域名白名单和IP白名单如何选择？
两者解决不同维度的问题，IP白名单控制来源网络，域名白名单控制访问目标，如果你只关心“谁在访问”，用IP白名单；如果你关心“访问的是哪个业务”，用域名白名单，实际生产环境建议两者同时开启,例如只允许公司出口IP访问指定的业务域名。
多级域名和泛域名怎么处理？
如果业务中存在大量随机子域（user123.example.com），可以在Nginx的正则匹配中实现，~ ^[a-z0-9]+\.example\.com$，但需要注意，不要用 .example.com 这种泛域名作为白名单，因为它等于放行了所有子域，白名单就失效了,建议只开放真正需要的子域。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e6%9c%8d%e5%8a%a1%e5%99%a8%e5%9f%9f%e5%90%8d%e7%99%bd%e5%90%8d%e5%8d%95%e5%a6%82%e4%bd%95%e6%ad%a3%e7%a1%ae%e9%85%8d%e7%bd%ae%e4%b8%8e%e7%ae%a1%e7%90%86%ef%bc%9f%ef%bc%8c%e5%9f%9f%e5%90%8d%e7%99%bd/
