必须用 default_server 是因为 Nginx 匹配 server 块时优先精确匹配 listen + server_name，未匹配的才按顺序取首个块——该行为不可靠；显式声明 default_server 才能确保未绑定域名的请求被确定性拦截。
直接禁止未绑定域名的 IP 访问，核心就一条：用 default_server 显式接管所有“没被明确匹配到”的请求，再配合 server_name _ 和 return 444 或 return 403。其他写法要么漏掉 HTTPS、要么触发 conflicting server name 警告、要么让合法域名意外失效。
为什么必须用 default_server 而不是靠配置顺序？
Nginx 匹配 server 块时，优先看 listen + server_name 是否精确匹配；没匹配上的，才按顺序取第一个 server 块——但这不可靠，尤其加了新站点后容易出错。显式声明 default_server 才是确定性行为。
-
listen 80 default_server和listen 443 ssl default_server必须分开写，不能合并成listen 80 default_server ssl - 如果只配了
80端口的default_server，但用户用https://xxx访问未备案域名，仍会落到你某个 HTTPSserver块里，等于白配 -
server_name _中的下划线是 Nginx 官方认可的“无效主机名占位符”，不是随便写的符号
return 444 和 return 403 选哪个？
return 444 是最干净的选择：它直接关闭 TCP 连接，不发任何 HTTP 响应头或 body，连日志里都难追踪完整请求。而 return 403 仍会返回标准响应体，可能暴露服务器指纹，也增加日志体积。
在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...
- 若你用宝塔、AMH 等面板，它们生成的默认配置常含
return 404，这反而可能被爬虫识别为“存在服务”，不如444 -
return 444在 Nginx 0.8.44+ 全版本支持，无兼容性问题 - 注意：
444不是 HTTP 标准状态码，所以浏览器开发者工具 Network 面板可能显示为“(failed)”或“net::ERR_EMPTY_RESPONSE”
HTTPS 场景下证书路径怎么填才不报错？
只要用了 ssl，default_server 的 server 块就必须提供 ssl_certificate 和 ssl_certificate_key，哪怕只是临时证书。否则 nginx -t 会失败。
- 可以复用你主站的证书路径，例如：
ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem - 如果不想暴露主站证书，可生成一个自签名证书专供该块使用：
openssl req -x509 -nodes -days 365 -newkey rsa:2048 -subj "/CN=_" -keyout /etc/nginx/ssl/default.key -out /etc/nginx/ssl/default.crt - 绝对不要留空或注释掉证书指令——Nginx 启动时会校验，缺一不可
多个域名共用一个 IP 时，server_name 写法易踩哪些坑？
当你在主 server 块里写 server_name a.com www.a.com b.com，又另配了 default_server，最容易出现 conflicting server name 警告，导致部分域名无法访问。
- 错误示范：
server { listen 80; server_name a.com www.a.com; }+server { listen 80 default_server; server_name _; }—— 此时www.a.com可能被误判为冲突 - 正确做法：所有非默认
server块的listen行**不加**default_server；default_server块里只写server_name _，**不要重复列出你的合法域名** - 如果要用
rewrite把非法流量导到首页，别用permanent（301），改用redirect（302），避免搜索引擎缓存错误跳转
最关键的细节是：default_server 必须覆盖所有监听端口（80 和 443），且每个端口只能有一个；证书路径不能省；server_name _ 不能和合法域名混写在同一块里。漏掉任意一点，防护就形同虚设。
