Nginx 限制域名是服务器安全配置中的关键环节，其核心目的在于防止恶意域名指向服务器IP以及禁止通过IP地址直接访问网站，从而规避恶意流量劫持、SEO权重分散和未授权访问等风险。Nginx 限制域名的核心原理在于通过 server_name 指令定义合法的访问入口，并利用 default_server 属性构建一个“拦截”服务器块，用于丢弃或重定向所有未匹配到合法域名的请求。 这种配置方式不仅能够确保服务器的资源仅被授权域名调用，还能有效阻断扫描器和攻击者的探测行为，是构建高安全性Web环境的基础设施。
限制域名访问的必要性与安全风险
在深入配置之前,必须明确为什么要进行严格的域名限制，默认情况下，Nginx 的第一个 Virtual Host 配置往往会作为默认处理块，如果未显式配置 default_server，任何指向服务器公网 IP 的请求，或者将恶意域名解析到该 IP 的请求，都会被该配置块处理，这会导致严重的安全隐患。
防止恶意域名解析（域名劫持），攻击者可以将自己的恶意域名解析到服务器的 IP 地址，Nginx 没有做限制，用户的浏览器在访问恶意域名时，实际上加载的是服务器上的内容，这不仅会消耗服务器带宽资源，更严重的是，如果恶意域名被搜索引擎收录，会导致网站内容被抄袭，甚至因为恶意域名的存在导致原站点被搜索引擎降权。
避免 IP 直接访问泄露信息，允许通过 IP 直接访问网站，往往会暴露服务器的具体版本信息或默认页面，这为攻击者提供了便利的侦察信息，通过限制域名，可以强制所有流量必须经过预定义的域名入口，便于统一管理和安全过滤。
基于 default_server 的拦截配置方案
实现 Nginx 域名限制最专业且通用的方案，是配置一个独立的“拦截”服务器块，该块不包含任何业务逻辑，仅用于处理非法请求。关键在于使用 listen 指令中的 default_server 参数，将其标记为所有未匹配 server_name 的请求的默认去处。
在 HTTP（80端口）层面，推荐配置如下：
server {
listen 80 default_server;
server_name _;
# 记录非法访问日志，便于后续分析攻击源
access_log /var/log/nginx/default_access.log;
error_log /var/log/nginx/default_error.log;
# 直接返回 444 状态码
return 444;
}
这里有几个关键点需要专业解读。server_name _ 是一种约定俗成的写法，_ 并不是一个特殊的通配符，但它是一个无效的域名，永远不会匹配到用户真实的 Host 头，因此常用于标记默认服务器。return 444; 是 Nginx 特有的非标准状态码，它的作用是服务器关闭连接且不发送任何响应头给客户端，相比于返回 403 或 404，444 能更彻底地阻断连接，节省服务器资源，并且让攻击者无法通过响应包获取任何信息。
HTTPS 环境下的域名限制与 SSL 处理
在 HTTPS（443端口）环境下，配置会稍微复杂，这是因为 SSL/TLS 握手发生在 Nginx 解析 HTTP Host 头之前，如果客户端访问的域名不在证书覆盖范围内，或者直接用 IP 访问，SSL 握手本身可能会报错。
为了解决这个问题,需要为默认的 default_server 配置一个自签名的 SSL 证书，或者使用任意一个已有域名的证书，只要能让 SSL 握手完成，Nginx 才能进入 HTTP 阶段去执行 return 444 的逻辑。
server {
listen 443 ssl default_server;
server_name _;
# 指定一个自签名证书或任意证书，仅用于完成握手
ssl_certificate /etc/nginx/ssl/dummy.crt;
ssl_certificate_key /etc/nginx/ssl/dummy.key;
return 444;
}
这种配置确保了即使用户尝试通过 IP 访问 HTTPS 站点，或者使用未配置的域名，Nginx 也能在 SSL 握手后立即断开连接，保护了真实业务服务器的安全性。
白名单机制与正则匹配的进阶应用
除了使用“拦截”块作为黑名单机制，还可以利用 Nginx 的正则匹配功能实现更精细的白名单控制。*如果服务器只允许 `.example.com` 的子域名访问**，可以在业务配置块中使用通配符或正则表达式。
server {
listen 80;
# 仅匹配 example.com 及其子域名
server_name example.com *.example.com;
# ... 业务配置 ...
}
配合前文的 default_server 拦截块，这就形成了一个严密的闭环：合法域名进入业务逻辑，非法域名进入拦截逻辑。这种分层架构不仅符合网络安全的最小权限原则，也极大地提升了运维的可维护性。 建议将拦截配置放在 conf.d 目录下的第一个文件（如 00-default.conf），确保在 Nginx 加载配置时，该块优先被读取作为默认规则。
独立见解：日志审计与动态防御
在实际的生产环境运维中,仅仅拦截是不够的。建议对 default_server 的访问日志进行单独的审计和监控。 这些日志记录了所有试图通过 IP 或恶意域名访问的请求，其中往往包含着扫描器的指纹、DDoS 攻击的试探流量。
通过分析 /var/log/nginx/default_access.log，运维人员可以提取出高频攻击的源 IP，并利用 Nginx 配合 ngx_http_limit_req_module 模块或者防火墙（如 iptables、Fail2Ban）进行动态封禁。将被动防御（域名限制）转变为主动防御（IP 封禁），是构建高可用 Web 架构的高级思路。
对于 SEO 优化而言，如果网站发生了域名变更，不要在 default_server 中直接使用 444，而应使用 301 重定向，将所有非法域名的流量 301 到新的合法域名，既能保留原有的链接权重，又能引导用户和搜索引擎更新索引，这是安全配置与业务增长策略相结合的最佳实践。
相关问答
Q1：Nginx 配置了 server_name 后，为什么还能通过 IP 访问？
A： 这是因为 Nginx 在处理请求时，会寻找与请求头中的 Host 字段匹配的 server_name，如果没有找到匹配项，它会使用第一个加载的 server 块作为默认处理，如果您的业务配置恰好是第一个加载的配置文件，IP 访问就会直接进入该业务块，解决方法必须显式配置一个带有 default_server 标记的拦截块，并确保它被优先加载。
Q2：在配置域名限制时，返回 444、403 和 502 哪个更好？
A： 从安全和性能角度来看，444 是最佳选择，403 Forbidden 虽然禁止了访问，但仍然会向客户端发送响应头和页面，攻击者可以通过响应体判断服务器状态，502 则是服务器错误，会暴露服务端异常，而 444 直接关闭 TCP 连接，不发送任何数据，攻击者无法获得任何反馈，既节省了带宽，又增加了攻击者的探测难度。
如果您在实施 Nginx 域名限制过程中遇到具体的配置问题，或者有更复杂的场景需要探讨，欢迎在评论区留言，我们将为您提供进一步的技术支持。
