白名单是一种“默认拒绝、例外放行”的安全策略，相比黑名单的“默认放行、例外拦截”，它能从源头上收紧访问入口。域名白名单指的是将特定域名列入信任列表，系统在处理请求时先校验来源域名或目标域名是否在列表中，命中则放行，未命中则拒绝或进入人工审核。常见的应用场景包括：服务器防火墙只允许自家CDN回源、企业邮件系统只接收信任域名的来信、浏览器或安全软件允许特定站点调用本地接口等。不同平台添加白名单的入口和逻辑差别不小，下面按场景逐一展开。
一、域名白名单和IP白名单的区别，先搞清楚再动手
很多人配置失败，根源在于把两种白名单混为一谈。域名白名单校验的是域名这一层信息，例如Nginx中通过valid_referers判断Referer，或者在反向代理场景校验请求头中的Host；而IP白名单校验的是网络层的来源地址。两者的关键差异在于：一个域名可能解析到多个IP，且解析结果会随时变化，如果只加IP白名单，一旦对方更换服务器就会失效。
因此在实操前要先明确需求：如果是限制“谁能访问我”，通常配置来源IP白名单更可靠，因为来源IP不可伪造；如果是限制“我只能被谁调用”或“只信任哪些第三方域名”，则用域名白名单，例如开放API时校验请求方的Referer或Origin。另外要注意，域名白名单支持精确匹配和通配符匹配两种写法，*.example.cn表示放行所有子域名，而example.cn只匹配主域名本身，是否包含子域名取决于具体软件的匹配规则，配置前务必查阅对应文档。
二、在Nginx中添加域名白名单的完整步骤
Nginx是最常需要配置白名单的环节，典型需求是防盗链或限制管理后台的访问来源。以Referer防盗链为例，先定位到站点配置文件，一般在/etc/nginx/conf.d/目录下，找到对应的server块，加入如下配置：
server {
listen 80;
server_name www.ipipp.com;
location /assets/ {
valid_referers none blocked server_names *.ipipp.com ipipp.com;
if ($invalid_referer) {
return 403;
}
}
}配置完成后执行nginx -t检查语法，确认输出ok后再执行nginx -s reload平滑重载。验证时可以用curl模拟带Referer的请求：curl -e "https://other.com" http://www.ipipp.com/assets/a.jpg，如果返回403说明白名单生效。这里有一个容易踩的坑：none表示允许没有Referer的请求通过（比如直接在浏览器地址栏打开图片），blocked表示允许Referer被代理隐藏的请求，是否要放行这两类需要结合业务判断，否则可能出现“配置后图片全挂”的情况。
如果需求是限制API只允许特定域名跨域调用，则应通过CORS响应头实现，在location块中添加：
add_header Access-Control-Allow-Origin "https://www.ipipp.com" always; add_header Access-Control-Allow-Methods "GET, POST, OPTIONS" always;
注意多个允许域名不能直接写多个Origin头，浏览器只认第一个，需要用map按$http_origin动态判断后再输出，这是很多前端联调时跨域失败的常见原因。
三、在防火墙和云安全组中添加白名单
系统层面的白名单以Linux的firewalld为例。先确认服务运行状态，然后将信任的来源加入指定zone并放行端口：
firewall-cmd --permanent --add-source=192.168.1.0/24 firewall-cmd --permanent --add-rich-rule='rule family=ipv4 source address=192.168.1.10 accept' firewall-cmd --reload firewall-cmd --list-all
如果是云服务器，更常用的做法是在云控制台的安全组中配置入站规则：登录控制台，找到对应实例的安全组，添加入站规则，类型选自定义TCP，端口填业务端口如8080，来源填允许的IP段或安全组ID，优先级数值越小越优先。云安全组的特点是默认拒绝所有入站流量，所以新建实例后必须显式放行端口，不少人部署完服务发现“外网打不开”就是这个原因。
需要强调的是，云安全组只能按IP或网段过滤，不能直接按域名过滤。如果对方IP不固定，一种折中方案是写脚本定期解析对方域名并更新安全组规则，另一种方案是把校验放到应用层，比如在Nginx或程序里做域名级别的判断。理解了“网络层管IP、应用层管域名”这个分层原则，遇到问题就知道该去哪一层排查。
四、Web应用防火墙与邮件系统中的白名单设置
使用云WAF或CDN防护时，白名单一般分几类：IP白名单（放行该IP的所有请求）、域名白名单（该域名的请求不做检测）、URL白名单、以及误报放行白名单。操作路径通常是在控制台的“防护配置”或“白名单管理”中新建规则，填写匹配条件（如域名等于某值）和放行动作，保存后约一到两分钟生效。建议规则尽量收窄范围，比如只对特定URL路径加白，而不是整站加白，否则等于给攻击者留了后门。
邮件系统中的域名白名单则用于避免正常来信被判为垃圾邮件。以企业邮箱为例，在管理后台的“反垃圾设置”里找到白名单入口，添加对方域名后保存；如果是自建Postfix，可以在配置中设置smtpd_sender_restrictions配合check_sender_access，指定哈希表中放行的域名：
# main.cf 中添加 smtpd_sender_restrictions = check_sender_access hash:/etc/postfix/sender_whitelist # sender_whitelist 文件内容 ipipp.com OK mail.ipipp.com OK
编辑完执行postmap /etc/postfix/sender_whitelist生成数据库文件，再执行systemctl reload postfix重载服务即可。
五、配置后的验证方法与常见问题排查
任何白名单配置完成后都必须验证，不要想当然地认为保存了就生效。验证思路是“一正一反”：用白名单内的来源访问应成功，用白名单外的来源访问应被拒绝。可用工具包括curl、浏览器开发者工具的Network面板查看请求头，以及在线的HTTP状态检测工具。
常见问题主要有四类：一是配置不生效，多半是忘记reload服务、云安全组规则未保存，或者存在多层防护（本地防火墙和云安全组同时限制，只改了一处）；二是域名加白后仍被拦截，检查是否只加了主域而对方用的是子域，或者通配符写法不被当前软件支持；三是反向代理场景下获取到的来源IP是代理节点IP，需要在应用中读取X-Forwarded-For并做realip模块配置，否则白名单判断的对象本身就是错的；四是规则冲突，多条白名单和黑名单规则同时存在时要理清优先级，一般更精确的规则优先，具体以软件文档为准。
日常维护上，建议建立白名单台账，记录每条规则的原因、添加人和日期，定期清理不再使用的条目。白名单越长，安全面越宽，每一条放行都是一次风险敞口，保持列表精炼才是白名单机制真正发挥作用的关键。