Nginx 域名配置 IP 的核心在于利用 server 块中的 server_name 指令与 listen 指令，精确控制入站流量，实现基于域名或 IP 地址的虚拟主机路由，通过合理的配置，不仅可以实现单服务器多站点托管，还能有效防止恶意域名解析，保障站点安全与 SEO 权重的集中。
基础域名绑定与监听配置
在 Nginx 中，每一个 server 块都代表一个虚拟主机，配置域名与 IP 的首要任务是定义监听端口和服务器名称,最基础的配置模式如下：
server {
listen 80;
server_name example.com www.example.com;
location / {
root /var/www/html;
index index.html;
}
}
在此配置中，listen 80 表示监听 80 端口（HTTP 默认端口）。server_name 指令则是关键，它决定了该 server 块响应哪些 Host 头部的请求，当用户访问 example.com 时，Nginx 会检查请求头中的 Host 字段，若与 server_name 匹配，则由该块处理请求，若配置了多个域名，可以使用空格分隔，Nginx 支持通配符匹配，server_name *.example.com; 可以匹配所有二级域名,这对于泛域名解析证书的部署尤为重要。
禁止 IP 直接访问与默认服务器处理
在生产环境中，禁止通过服务器 IP 地址直接访问网站是一项重要的安全与 SEO 策略，允许 IP 访问会导致以下风险：一是恶意域名可以指向该服务器 IP，造成内容被恶意篡改或劫持；二是搜索引擎可能会将 IP 和域名同时收录，导致页面内容重复,分散域名权重。
为了解决这个问题，需要配置一个默认的 server 块来捕获所有未匹配到特定域名的请求（包括 IP 访问），Nginx 允许使用 default_server 参数来标记默认主机：
server {
listen 80 default_server;
server_name _;
return 444;
}
在此配置中，server_name _; 是一个无效的域名，用于匹配所有未被其他 server_name 定义的请求。return 444; 是 Nginx 特有的非标准状态码，它表示关闭连接且不发送任何响应头，比返回 403 或 404 更为安全，能有效减少攻击面的暴露，通过将此块置于配置文件的最前方或确保其拥有 default_server 属性，可以确保所有针对 IP 的非法访问都被直接阻断。
基于 IP 的访问控制与限制
除了区分域名和 IP，Nginx 还能根据客户端 IP 进行精细的访问控制，这在后台管理接口保护或 API 限流场景中非常实用，利用 allow 和 deny 指令,可以构建白名单或黑名单机制。
location /admin {
allow 192.168.1.0/24;
deny all;
# 其他配置...
}
上述配置表示仅允许 168.1.0/24 网段的 IP 访问 /admin 目录，其他所有 IP 的访问请求都会被拒绝。这种基于 IP 的 ACL（访问控制列表）应当配合防火墙规则使用，以提供纵深防御，在配置时，需要注意规则的顺序，Nginx 是从上到下依次匹配，一旦匹配到 allow 或 deny 就会停止后续规则的检查。
反向代理中的动态 DNS 解析
在使用 Nginx 作为反向代理时，后端服务器往往也使用域名标识，Nginx 在启动时会将后端域名解析为 IP 地址并缓存，如果后端 IP 发生变化，Nginx 不会自动更新，导致服务中断，为了解决这个问题，必须引入动态 DNS 解析机制。
这需要配置 resolver 指令，并使用变量来设置 proxy_pass：
server {
...
resolver 8.8.8.8 valid=300s;
location / {
set $backend_upstream "backend.example.com";
proxy_pass http://$backend_upstream;
}
}
resolver 指令指定了 DNS 服务器地址（如 Google 的 8.8.8.8）及缓存有效期（valid=300s），通过 set 指令将域名赋值给变量，再在 proxy_pass 中引用该变量，可以强制 Nginx 在每次请求（或缓存过期时）重新解析域名，这是实现高可用性架构的关键配置细节，尤其适用于容器化或云原生环境，后端 Pod IP 频繁变动的场景。
SSL/TLS 与 SNI 机制
在 HTTPS 环境下，域名与 IP 的关系变得更加复杂，因为服务器在建立 TLS 连接时就需要发送证书，这就引入了 SNI（Server Name Indication） 技术，SNI 允许客户端在握手阶段发送访问的域名，从而使 Nginx 能够根据域名选择正确的 SSL 证书。
配置 HTTPS 域名时，必须确保 server_name 与证书中的 Common Name 或 SAN（Subject Alternative Name）一致：
server {
listen 443 ssl;
server_name secure.example.com;
ssl_certificate /etc/nginx/ssl/secure.example.com.crt;
ssl_certificate_key /etc/nginx/ssl/secure.example.com.key;
...
}
如果同一个 IP 托运了多个 HTTPS 站点，必须依赖 SNI，现代浏览器几乎都支持 SNI，但在处理一些老旧系统（如 Windows XP）的请求时可能会出现问题，为了最大化安全性，建议在监听端口上只启用符合现代安全标准的 TLS 协议版本和加密套件。
相关问答
Q1：为什么配置了 server_name 后，通过 IP 依然能访问到网站？
A1：这是因为 Nginx 在处理请求时，如果没有找到匹配 server_name 的虚拟主机配置，它会默认使用第一个加载的 server 块作为响应，要禁止 IP 访问，必须显式配置一个 listen 80 default_server 的 server 块，并在其中返回 444 或 403 状态码,确保该块位于配置列表的优先位置。
Q2：在反向代理场景下，如何防止后端服务器的真实 IP 泄露？
A2：除了配置 proxy_pass 外，必须在 server 或 location 块中添加头字段隐藏规则，具体配置为：proxy_set_header X-Real-IP $remote_addr;、proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; 以及 proxy_set_header Host $host;，后端应用服务器（如 Apache 或 Nginx）应配置为仅信任来自反向代理的这些头部信息,避免直接处理原始请求头。
通过上述配置策略，您可以构建一个既符合 SEO 规范，又具备高安全性和高可用性的 Nginx 服务环境，如果您在配置过程中遇到端口冲突或证书不匹配的问题，欢迎在评论区分享您的错误日志,我们将共同探讨解决方案。
