禁止IP访问必须使用独立的default_server块，而非在业务server块中用if判断；需配置listen 80 default_server和listen 443 ssl default_server，server_name _，并返回444或403。
直接在 server 块里加禁止 IP 访问的逻辑，是常见误区——兜底行为必须由独立的 default_server 块承担，不能靠业务 server 块内部判断实现。因为 Nginx 匹配 server 是按 listen + server_name 组合优先级进行的，不是靠 if 或 rewrite 拦截。
必须用独立兜底块，而非改写已有 server
已有业务 server 块（比如 listen 80; server_name example.com;）只响应匹配域名的请求。它对 IP 访问、空 Host 或未配置域名的请求完全不处理——这些请求会落到第一个带 default_server 的 server 块上。所以禁止 IP 访问的关键，是确保：
- 有且仅有一个 listen 80 default_server（同理 HTTPS 要配 listen 443 ssl default_server）
- 这个块的 server_name 设为 _（占位符，不匹配任何真实域名）
- 它放在所有业务 server 块之前或之后均可，但不能遗漏或重复
标准兜底配置写法
在 http{} 块内新增一个 server，内容如下：
-
listen 80 default_server;—— 明确指定这是 HTTP 的默认入口 -
listen 443 ssl default_server;—— 若启用 HTTPS，也必须加这一行，并配上证书路径（否则 nginx -t 会报错） -
server_name _;—— 不是必须，但加上更清晰，避免误读为配置遗漏 -
return 444;—— 最干净的拒绝方式，直接断连，无响应体、无日志冗余
如果想返回友好提示页，可换成：return 403; + 配置 error_page 403 /403.html;，并确保该静态页存在且可访问。
常见错误及规避
以下配置看似合理，实则无效或危险：
- 在业务 server 块里写
if ($host != 'example.com') { return 444; }—— Nginx 官方明确不推荐在 server 级别用 if，易出匹配逻辑异常 - 多个 server 块都带
default_server—— nginx -t 直接报错，启动失败 - 只写
server_name _;却没加default_server—— 请求仍可能落到其他 server 块（按配置顺序第一个能 accept 的） - HTTP 和 HTTPS 的 default_server 分开写，但漏掉其中一者 —— 对应协议的 IP 访问仍可穿透
验证是否生效
配置完成后执行：nginx -t && nginx -s reload
然后测试：
-
curl -I http://你的服务器IP→ 应返回空响应或 connection reset（444 效果） -
curl -I https://你的服务器IP→ 同样应断连（前提是已配好 443 default_server） -
curl -H "Host: fake.com" http://你的服务器IP→ 也应被兜底块拦截 - 用浏览器访问 IP 地址 → 显示 ERR_EMPTY_RESPONSE 或连接被重置
只要业务域名访问正常，而所有 IP 直连均失败，说明兜底生效。
