Nginx Proxy Manager 404 主机Dead Host实战指南优雅处理已下线域名、SEO 降权与访问日志追踪【免费下载链接】nginx-proxy-managerDocker container for managing Nginx proxy hosts with a simple, powerful interface项目地址: https://gitcode.com/GitHub_Trending/ng/nginx-proxy-manager404 主机Dead Host / 404 Host是 Nginx Proxy Manager 提供的一类特殊主机配置它不转发流量到任何后端而是直接向访问者返回 404 错误页面。本文围绕官方帮助文档见 frontend/src/locale/src/HelpDoc/en/DeadHosts.md 及德文版 DeadHosts.md展开结合仓库中的后端实现、数据库迁移、Nginx 模板与 REST API讲解 404 主机的概念、适用场景、配置方法、底层工作原理以及日志追踪能力读完即可在 Nginx Proxy Manager 中独立创建与管理 404 主机。什么是 404 主机根据官方帮助文档的定义404 主机是一种简单的主机配置host setup其作用就是向访问者展示一个 404 页面。它没有反向代理目标、没有转发地址本质上是一个只返回 404 状态码的虚拟主机。在 Nginx Proxy Manager 的管理界面中它位于Hosts → 404 Hosts菜单下前端页面实现见 frontend/src/pages/Nginx/DeadHosts/Table.tsx后端对象在 OpenAPI 规范中被直接描述为 404 Host object见 backend/schema/components/dead-host-object.json。与代理主机Proxy Host、重定向主机Redirection Host相比404 主机最大的不同在于它不把请求转发到任何上游服务而是直接终结请求并返回 404。这一点可以从它的 Nginx 配置模板中直观看出——模板里没有任何proxy_pass或return 30x指令只有一个返回 404 的location块详见下文配置生成原理。为什么需要 404 主机两大核心应用场景帮助文档明确指出了 404 主机的两个典型使用价值场景一处理已下线域名配合搜索引擎优化SEO当你的域名曾经被搜索引擎收录您的域名在搜索引擎中被列入而网站内容已经下线时你可以用 404 主机提供一个比默认错误页更美观、更友好的 404 页面避免访客面对浏览器自带的生硬错误提示明确告知搜索索引器search indexers该域名的页面已不存在促使搜索引擎逐步将这些 URL 从索引中移除加快降权/摘除流程避免陈旧内容长期残留在搜索结果中。这是 404 主机最常见的用法域名到期、业务下线、内容迁移之后把旧域名挂到 404 主机上让爬虫和访客得到清晰一致的已不存在信号。场景二追踪访问日志与引用来源Referrer帮助文档还特别提到拥有这种主机的另一个好处是可以跟踪点击它的日志并查看访问来源referrers。也就是说404 主机可以被当作一个流量探针你可以通过 Nginx 访问日志观察哪些人还在访问这个已下线域名、访问频率如何通过日志中的 Referrer 字段可以看到这些访问来自哪些外部站点、哪些旧链接仍然在别处被引用从而评估外部链接残留情况或发现盗链/异常流量。这两点正是本篇文章展开的主线前半部分讲如何配置一个 404 主机后半部分讲它生成的 Nginx 配置与日志如何支撑上述两个场景。404 主机的数据模型与字段详解要真正理解 404 主机能配置什么、不能配置什么需要先看它在数据库中的结构。dead_host表自项目最初的数据库迁移中就已建立见 backend/migrations/20180618015850_initial.jsknex.schema.createTable(dead_host, (table) { table.increments().primary(); table.dateTime(created_on).notNull(); table.dateTime(modified_on).notNull(); table.integer(owner_user_id).notNull().unsigned(); table.integer(is_deleted).notNull().unsigned().defaultTo(0); table.json(domain_names).notNull(); table.integer(certificate_id).notNull().unsigned().defaultTo(0); table.integer(ssl_forced).notNull().unsigned().defaultTo(0); table.text(advanced_config).notNull().defaultTo(); table.json(meta).notNull(); });随着项目演进模型层 backend/models/dead_host.js 中补充了更多布尔字段http2_support、hsts_enabled、hsts_subdomains、enabled等并统一在boolFields数组里管理const boolFields [is_deleted, ssl_forced, http2_support, enabled, hsts_enabled, hsts_subdomains];综合数据库迁移、模型与 OpenAPI 规范backend/schema/components/dead-host-object.json一个完整的 404 主机对象包含以下核心字段字段类型说明idinteger主机唯一 IDdomain_namesjson 数组绑定的域名列表可配置多个域名指向同一个 404 页面模型中会自动排序certificate_idinteger关联的 SSL 证书 ID0表示无证书纯 HTTPssl_forcedboolean是否强制跳转 HTTPS配合_forced_ssl.conf模板http2_supportboolean是否启用 HTTP/2hsts_enabledboolean是否启用 HSTS 响应头hsts_subdomainsbooleanHSTS 是否作用于子域名配合_hsts_map.conf生成映射advanced_configtext自定义 Nginx 配置片段直接拼入生成的 server 块enabledboolean是否启用禁用时不会生成 Nginx 配置owner_user_idinteger创建者用户 ID用于权限可见性控制is_deletedboolean软删除标记删除操作只置 1不物理删除created_on/modified_ondatetime创建与修改时间模型$beforeInsert/$beforeUpdate自动维护metajson元数据容器用于存储证书指纹等派生信息certificate/owner关联对象通过expand参数加载的关联数据模型关系定义见 backend/models/dead_host.js注意与代理主机不同404 主机没有forward_host、forward_port、forward_scheme、access_list_id、caching_enabled等与转发/访问控制相关的字段——它不转发任何流量这再次印证了404 主机 纯错误响应的本质。404 主机的 Nginx 配置生成原理每个 404 主机在创建或更新后后端都会调用internalNginx.configure(...)生成对应的 Nginx 配置见 backend/internal/dead-host.js。生成的依据是模板 backend/templates/dead_host.conf{% include _header_comment.conf %} {% if enabled %} {% include _hsts_map.conf %} server { {% include _listen.conf %} {% include _certificates.conf %} {% include _hsts.conf %} {% include _forced_ssl.conf %} access_log /data/logs/dead-host-{{ id }}_access.log standard; error_log /data/logs/dead-host-{{ id }}_error.log warn; {{ advanced_config }} {% if use_default_location %} location / { {% include _hsts.conf %} return 404; } {% endif %} # Custom include /data/nginx/custom/server_dead[.]conf; } {% endif %}这段模板揭示了几个关键实现细节核心行为是return 404;use_default_location开启时根路径location /直接返回 404不做任何代理或跳转——这就是404 主机的 Nginx 层面本质。SSL/强制 HTTPS/HSTS 都是可选的装饰能力模板依次引入_listen.conf监听 80/443 端口、_certificates.conf加载证书、_hsts.confHSTS 响应头、_forced_ssl.confHTTP 跳 HTTPS。也就是说即便是一个死掉的域名你仍然可以给它挂上 SSL 证书让 404 页面通过 HTTPS 正常展示避免浏览器安全警告启用强制 SSL把明文 HTTP 请求统一 301 到 HTTPS 后再返回 404启用 HSTS向浏览器声明该域名仅支持 HTTPS。每台 404 主机拥有独立的日志文件access_log /data/logs/dead-host-{{ id }}_access.log日志以主机 ID 隔离——这正是帮助文档所说跟踪访问日志、查看引用来源的物理基础。高级配置可自由注入{{ advanced_config }}会把界面上填写的自定义 Nginx 配置原样嵌入 server 块例如你可以在里面加自定义location、限流limit_req或自定义响应头。预留了手动配置挂载点include /data/nginx/custom/server_dead[.]conf;运维人员可以把自定义 server 级配置放在容器内/data/nginx/custom/目录命名以server_dead.conf为前缀即可被自动加载。创建与配置 404 主机界面实操入口与权限前提在 Web 界面中依次进入Hosts → 404 Hosts → Add 404 Host即可创建。需要说明的是创建/更新操作受权限控制要么是管理员角色要么拥有permission_dead_hosts的 manage 权限且角色为 user校验规则见 backend/lib/access/dead_hosts-create.json 与 dead_hosts-update.json。界面配置项创建 404 主机时核心配置项与后端字段一一对应Domain Names域名填写需要返回 404 的域名可填多个保存时后端会先逐一遍历检查是否与其他主机冲突调用internalHost.isHostnameTaken见 backend/internal/dead-host.js一旦被占用会直接报 is already in use 校验错误。SSL 证书可选择已有的 Lets Encrypt 证书、上传自定义证书或选择 new 在创建主机的同时签发新证书。源码中当certificate_id new时会先创建主机再调用internalCertificate.createQuickCertificate签发并回填证书 ID见 backend/internal/dead-host.js 与 L67-L75并带有证书创建失败则视为内部错误的健全性检查L84-L86。Force SSL勾选后强制 HTTPS 访问。HTTP/2 Support为 HTTPS 监听启用 HTTP/2。HSTS Enabled / HSTS Subdomains启用 HSTS 及其子域名作用范围。Advanced 配置可选的advanced_config文本域用于注入自定义 Nginx 指令。启用状态enabled开关决定是否立即生成并加载 Nginx 配置如果创建时不启用配置不会写入。保存后后端会执行完整的创建流程权限校验 → 域名占用检查 → 写入dead_host表 → 写入审计日志action 为createdobject_type 为dead-host→ 按需签发证书 → 调用internalNginx.configure生成 Nginx 配置并 reload见 backend/internal/dead-host.js。通过 REST API 管理 404 主机404 主机不仅能在界面操作也暴露了完整的 REST API路由定义见 backend/routes/nginx/dead_hosts.js。所有接口都需要 JWT 鉴权jwtdecode()并经过 schema 校验。方法路径功能GET/api/nginx/dead-hosts列出全部 404 主机支持expand如expandcertificate,owner与query搜索按域名模糊匹配见 backend/internal/dead-host.jsPOST/api/nginx/dead-hosts创建 404 主机返回 201GET/api/nginx/dead-hosts/:host_id获取单个 404 主机详情PUT/api/nginx/dead-hosts/:host_id更新 404 主机DELETE/api/nginx/dead-hosts/:host_id删除 404 主机POST/api/nginx/dead-hosts/:host_id/enable启用主机重新生成并加载 Nginx 配置POST/api/nginx/dead-hosts/:host_id/disable禁用主机删除 Nginx 配置并 reload一个创建 404 主机的请求示例JSON 体{ domain_names: [old-site.example.com, www.old-site.example.com], certificate_id: 3, ssl_forced: true, hsts_enabled: true, hsts_subdomains: false, http2_support: true, advanced_config: , enabled: true }要点创建时若传certificate_id: new则会触发随主机一同签发证书的快捷流程见 backend/internal/dead-host.js更新时同样支持new语义并且后端会先读取现有记录把domain_names合并进审计元数据以保证审计日志渲染完整见 L143-L150。启用、禁用与删除生命周期管理启用 / 禁用启用enable校验主机未被启用后将enabled置 1随后调用internalNginx.configure生成配置并加载同时写入 action 为enabled的审计日志见 backend/internal/dead-host.js。禁用disable将enabled置 0调用internalNginx.deleteConfig(dead_host, row)删除对应 Nginx 配置文件并执行internalNginx.reload()主机即刻停止返回 404见 backend/internal/dead-host.js。更新操作也有同样逻辑禁用状态的主机更新时不会重新生成 Nginx 配置见 L170-L174避免为未启用主机生成无效配置。删除软删除删除 404 主机会把is_deleted置为 1软删除数据仍保留在表中同时删除 Nginx 配置并 reload、写入deleted审计日志见 backend/internal/dead-host.js。所有查询get、getAll、getCount都会通过where(is_deleted, 0)过滤掉已删除记录见 L190-L195 与 L334-L336。数据可见性404 主机的可见性受用户权限permission_visibility控制权限可见性为all的管理员可以看到所有主机普通用户只能看到自己owner_user_id创建的主机见 backend/internal/dead-host.js 与 L341-L343。这保证了多人共用 Nginx Proxy Manager 时404 主机与代理主机一样遵循相同的隔离规则。追踪访问日志与引用来源回到帮助文档强调的第二个收益点——跟踪访问日志、查看引用来源。实现这一能力的基础设施正是 backend/templates/dead_host.conf 中为每台 404 主机单独声明的日志文件access_log /data/logs/dead-host-{{ id }}_access.log standard; error_log /data/logs/dead-host-{{ id }}_error.log warn;实战中你可以这样使用定位日志进入 Nginx Proxy Manager 容器的/data/logs/目录按主机 ID 找到dead-host-id_access.log。由于文件名以主机 ID 隔离多台 404 主机的访问记录互不混淆便于按域名分别统计。分析引用来源访问日志的standard格式会记录请求来源Referrer字段从中可以观察到哪些外部网站仍在链向这个已下线域名、哪些旧的推广链接还在产生流量进而决定是保留 404 状态让搜索引擎摘除还是把特定来源的请求单独处理。与审计日志互补对 404 主机的每次创建、修改、启停、删除都会写入审计日志audit-log表action 分别为created/updated/enabled/disabled/deleted配合访问日志即可完整还原谁在何时改动了配置、哪些流量还在访问该域名。常见问题与注意事项404 主机能返回自定义错误页吗可以。利用advanced_config字段注入自定义location或error_page指令即可覆盖默认的return 404行为实现品牌化的错误页面也可以直接在容器挂载的自定义 Nginx 目录中放置server_dead.conf配置。域名冲突怎么办同一个域名不能被两台主机代理/重定向/404同时占用创建时会立即校验并返回ValidationError。这意味着你需要先把旧的代理主机删除或改绑才能把域名交给 404 主机。删除后流量去哪里删除 404 主机会同时删除其 Nginx 配置并 reload此后该域名将不再由 Nginx Proxy Manager 处理回到默认站点或直接连接失败不再返回 404。证书随主机删除吗不会自动删除证书。删除 404 主机只做软删除标记与配置清理关联的证书对象仍保留在证书列表中可在 Certificates 中另行管理。总结404 主机Dead Host是 Nginx Proxy Manager 中一类小而实用的主机类型不转发任何流量只向访问者返回 404 页面并在这一简单行为之上提供了 SSL/HSTS/HTTP2、自定义 Nginx 配置、独立访问日志、完整 REST API 与审计追踪等完整能力。它最适合两类场景下线域名/失效页面的 SEO 清理用规范且美观的 404 明确告知搜索引擎内容已不存在与残留流量观测借助按主机隔离的访问日志分析引用来源。理解其数据模型与 dead_host.conf 模板的生成逻辑后你就能在界面、API 甚至自定义配置三个层面自如地管理它。【免费下载链接】nginx-proxy-managerDocker container for managing Nginx proxy hosts with a simple, powerful interface项目地址: https://gitcode.com/GitHub_Trending/ng/nginx-proxy-manager创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Nginx Proxy Manager 404 主机（Dead Host）实战指南：优雅处理已下线域名、SEO 降权与访问日志追踪
Nginx Proxy Manager 404 主机Dead Host实战指南优雅处理已下线域名、SEO 降权与访问日志追踪【免费下载链接】nginx-proxy-managerDocker container for managing Nginx proxy hosts with a simple, powerful interface项目地址: https://gitcode.com/GitHub_Trending/ng/nginx-proxy-manager404 主机Dead Host / 404 Host是 Nginx Proxy Manager 提供的一类特殊主机配置它不转发流量到任何后端而是直接向访问者返回 404 错误页面。本文围绕官方帮助文档见 frontend/src/locale/src/HelpDoc/en/DeadHosts.md 及德文版 DeadHosts.md展开结合仓库中的后端实现、数据库迁移、Nginx 模板与 REST API讲解 404 主机的概念、适用场景、配置方法、底层工作原理以及日志追踪能力读完即可在 Nginx Proxy Manager 中独立创建与管理 404 主机。什么是 404 主机根据官方帮助文档的定义404 主机是一种简单的主机配置host setup其作用就是向访问者展示一个 404 页面。它没有反向代理目标、没有转发地址本质上是一个只返回 404 状态码的虚拟主机。在 Nginx Proxy Manager 的管理界面中它位于Hosts → 404 Hosts菜单下前端页面实现见 frontend/src/pages/Nginx/DeadHosts/Table.tsx后端对象在 OpenAPI 规范中被直接描述为 404 Host object见 backend/schema/components/dead-host-object.json。与代理主机Proxy Host、重定向主机Redirection Host相比404 主机最大的不同在于它不把请求转发到任何上游服务而是直接终结请求并返回 404。这一点可以从它的 Nginx 配置模板中直观看出——模板里没有任何proxy_pass或return 30x指令只有一个返回 404 的location块详见下文配置生成原理。为什么需要 404 主机两大核心应用场景帮助文档明确指出了 404 主机的两个典型使用价值场景一处理已下线域名配合搜索引擎优化SEO当你的域名曾经被搜索引擎收录您的域名在搜索引擎中被列入而网站内容已经下线时你可以用 404 主机提供一个比默认错误页更美观、更友好的 404 页面避免访客面对浏览器自带的生硬错误提示明确告知搜索索引器search indexers该域名的页面已不存在促使搜索引擎逐步将这些 URL 从索引中移除加快降权/摘除流程避免陈旧内容长期残留在搜索结果中。这是 404 主机最常见的用法域名到期、业务下线、内容迁移之后把旧域名挂到 404 主机上让爬虫和访客得到清晰一致的已不存在信号。场景二追踪访问日志与引用来源Referrer帮助文档还特别提到拥有这种主机的另一个好处是可以跟踪点击它的日志并查看访问来源referrers。也就是说404 主机可以被当作一个流量探针你可以通过 Nginx 访问日志观察哪些人还在访问这个已下线域名、访问频率如何通过日志中的 Referrer 字段可以看到这些访问来自哪些外部站点、哪些旧链接仍然在别处被引用从而评估外部链接残留情况或发现盗链/异常流量。这两点正是本篇文章展开的主线前半部分讲如何配置一个 404 主机后半部分讲它生成的 Nginx 配置与日志如何支撑上述两个场景。404 主机的数据模型与字段详解要真正理解 404 主机能配置什么、不能配置什么需要先看它在数据库中的结构。dead_host表自项目最初的数据库迁移中就已建立见 backend/migrations/20180618015850_initial.jsknex.schema.createTable(dead_host, (table) { table.increments().primary(); table.dateTime(created_on).notNull(); table.dateTime(modified_on).notNull(); table.integer(owner_user_id).notNull().unsigned(); table.integer(is_deleted).notNull().unsigned().defaultTo(0); table.json(domain_names).notNull(); table.integer(certificate_id).notNull().unsigned().defaultTo(0); table.integer(ssl_forced).notNull().unsigned().defaultTo(0); table.text(advanced_config).notNull().defaultTo(); table.json(meta).notNull(); });随着项目演进模型层 backend/models/dead_host.js 中补充了更多布尔字段http2_support、hsts_enabled、hsts_subdomains、enabled等并统一在boolFields数组里管理const boolFields [is_deleted, ssl_forced, http2_support, enabled, hsts_enabled, hsts_subdomains];综合数据库迁移、模型与 OpenAPI 规范backend/schema/components/dead-host-object.json一个完整的 404 主机对象包含以下核心字段字段类型说明idinteger主机唯一 IDdomain_namesjson 数组绑定的域名列表可配置多个域名指向同一个 404 页面模型中会自动排序certificate_idinteger关联的 SSL 证书 ID0表示无证书纯 HTTPssl_forcedboolean是否强制跳转 HTTPS配合_forced_ssl.conf模板http2_supportboolean是否启用 HTTP/2hsts_enabledboolean是否启用 HSTS 响应头hsts_subdomainsbooleanHSTS 是否作用于子域名配合_hsts_map.conf生成映射advanced_configtext自定义 Nginx 配置片段直接拼入生成的 server 块enabledboolean是否启用禁用时不会生成 Nginx 配置owner_user_idinteger创建者用户 ID用于权限可见性控制is_deletedboolean软删除标记删除操作只置 1不物理删除created_on/modified_ondatetime创建与修改时间模型$beforeInsert/$beforeUpdate自动维护metajson元数据容器用于存储证书指纹等派生信息certificate/owner关联对象通过expand参数加载的关联数据模型关系定义见 backend/models/dead_host.js注意与代理主机不同404 主机没有forward_host、forward_port、forward_scheme、access_list_id、caching_enabled等与转发/访问控制相关的字段——它不转发任何流量这再次印证了404 主机 纯错误响应的本质。404 主机的 Nginx 配置生成原理每个 404 主机在创建或更新后后端都会调用internalNginx.configure(...)生成对应的 Nginx 配置见 backend/internal/dead-host.js。生成的依据是模板 backend/templates/dead_host.conf{% include _header_comment.conf %} {% if enabled %} {% include _hsts_map.conf %} server { {% include _listen.conf %} {% include _certificates.conf %} {% include _hsts.conf %} {% include _forced_ssl.conf %} access_log /data/logs/dead-host-{{ id }}_access.log standard; error_log /data/logs/dead-host-{{ id }}_error.log warn; {{ advanced_config }} {% if use_default_location %} location / { {% include _hsts.conf %} return 404; } {% endif %} # Custom include /data/nginx/custom/server_dead[.]conf; } {% endif %}这段模板揭示了几个关键实现细节核心行为是return 404;use_default_location开启时根路径location /直接返回 404不做任何代理或跳转——这就是404 主机的 Nginx 层面本质。SSL/强制 HTTPS/HSTS 都是可选的装饰能力模板依次引入_listen.conf监听 80/443 端口、_certificates.conf加载证书、_hsts.confHSTS 响应头、_forced_ssl.confHTTP 跳 HTTPS。也就是说即便是一个死掉的域名你仍然可以给它挂上 SSL 证书让 404 页面通过 HTTPS 正常展示避免浏览器安全警告启用强制 SSL把明文 HTTP 请求统一 301 到 HTTPS 后再返回 404启用 HSTS向浏览器声明该域名仅支持 HTTPS。每台 404 主机拥有独立的日志文件access_log /data/logs/dead-host-{{ id }}_access.log日志以主机 ID 隔离——这正是帮助文档所说跟踪访问日志、查看引用来源的物理基础。高级配置可自由注入{{ advanced_config }}会把界面上填写的自定义 Nginx 配置原样嵌入 server 块例如你可以在里面加自定义location、限流limit_req或自定义响应头。预留了手动配置挂载点include /data/nginx/custom/server_dead[.]conf;运维人员可以把自定义 server 级配置放在容器内/data/nginx/custom/目录命名以server_dead.conf为前缀即可被自动加载。创建与配置 404 主机界面实操入口与权限前提在 Web 界面中依次进入Hosts → 404 Hosts → Add 404 Host即可创建。需要说明的是创建/更新操作受权限控制要么是管理员角色要么拥有permission_dead_hosts的 manage 权限且角色为 user校验规则见 backend/lib/access/dead_hosts-create.json 与 dead_hosts-update.json。界面配置项创建 404 主机时核心配置项与后端字段一一对应Domain Names域名填写需要返回 404 的域名可填多个保存时后端会先逐一遍历检查是否与其他主机冲突调用internalHost.isHostnameTaken见 backend/internal/dead-host.js一旦被占用会直接报 is already in use 校验错误。SSL 证书可选择已有的 Lets Encrypt 证书、上传自定义证书或选择 new 在创建主机的同时签发新证书。源码中当certificate_id new时会先创建主机再调用internalCertificate.createQuickCertificate签发并回填证书 ID见 backend/internal/dead-host.js 与 L67-L75并带有证书创建失败则视为内部错误的健全性检查L84-L86。Force SSL勾选后强制 HTTPS 访问。HTTP/2 Support为 HTTPS 监听启用 HTTP/2。HSTS Enabled / HSTS Subdomains启用 HSTS 及其子域名作用范围。Advanced 配置可选的advanced_config文本域用于注入自定义 Nginx 指令。启用状态enabled开关决定是否立即生成并加载 Nginx 配置如果创建时不启用配置不会写入。保存后后端会执行完整的创建流程权限校验 → 域名占用检查 → 写入dead_host表 → 写入审计日志action 为createdobject_type 为dead-host→ 按需签发证书 → 调用internalNginx.configure生成 Nginx 配置并 reload见 backend/internal/dead-host.js。通过 REST API 管理 404 主机404 主机不仅能在界面操作也暴露了完整的 REST API路由定义见 backend/routes/nginx/dead_hosts.js。所有接口都需要 JWT 鉴权jwtdecode()并经过 schema 校验。方法路径功能GET/api/nginx/dead-hosts列出全部 404 主机支持expand如expandcertificate,owner与query搜索按域名模糊匹配见 backend/internal/dead-host.jsPOST/api/nginx/dead-hosts创建 404 主机返回 201GET/api/nginx/dead-hosts/:host_id获取单个 404 主机详情PUT/api/nginx/dead-hosts/:host_id更新 404 主机DELETE/api/nginx/dead-hosts/:host_id删除 404 主机POST/api/nginx/dead-hosts/:host_id/enable启用主机重新生成并加载 Nginx 配置POST/api/nginx/dead-hosts/:host_id/disable禁用主机删除 Nginx 配置并 reload一个创建 404 主机的请求示例JSON 体{ domain_names: [old-site.example.com, www.old-site.example.com], certificate_id: 3, ssl_forced: true, hsts_enabled: true, hsts_subdomains: false, http2_support: true, advanced_config: , enabled: true }要点创建时若传certificate_id: new则会触发随主机一同签发证书的快捷流程见 backend/internal/dead-host.js更新时同样支持new语义并且后端会先读取现有记录把domain_names合并进审计元数据以保证审计日志渲染完整见 L143-L150。启用、禁用与删除生命周期管理启用 / 禁用启用enable校验主机未被启用后将enabled置 1随后调用internalNginx.configure生成配置并加载同时写入 action 为enabled的审计日志见 backend/internal/dead-host.js。禁用disable将enabled置 0调用internalNginx.deleteConfig(dead_host, row)删除对应 Nginx 配置文件并执行internalNginx.reload()主机即刻停止返回 404见 backend/internal/dead-host.js。更新操作也有同样逻辑禁用状态的主机更新时不会重新生成 Nginx 配置见 L170-L174避免为未启用主机生成无效配置。删除软删除删除 404 主机会把is_deleted置为 1软删除数据仍保留在表中同时删除 Nginx 配置并 reload、写入deleted审计日志见 backend/internal/dead-host.js。所有查询get、getAll、getCount都会通过where(is_deleted, 0)过滤掉已删除记录见 L190-L195 与 L334-L336。数据可见性404 主机的可见性受用户权限permission_visibility控制权限可见性为all的管理员可以看到所有主机普通用户只能看到自己owner_user_id创建的主机见 backend/internal/dead-host.js 与 L341-L343。这保证了多人共用 Nginx Proxy Manager 时404 主机与代理主机一样遵循相同的隔离规则。追踪访问日志与引用来源回到帮助文档强调的第二个收益点——跟踪访问日志、查看引用来源。实现这一能力的基础设施正是 backend/templates/dead_host.conf 中为每台 404 主机单独声明的日志文件access_log /data/logs/dead-host-{{ id }}_access.log standard; error_log /data/logs/dead-host-{{ id }}_error.log warn;实战中你可以这样使用定位日志进入 Nginx Proxy Manager 容器的/data/logs/目录按主机 ID 找到dead-host-id_access.log。由于文件名以主机 ID 隔离多台 404 主机的访问记录互不混淆便于按域名分别统计。分析引用来源访问日志的standard格式会记录请求来源Referrer字段从中可以观察到哪些外部网站仍在链向这个已下线域名、哪些旧的推广链接还在产生流量进而决定是保留 404 状态让搜索引擎摘除还是把特定来源的请求单独处理。与审计日志互补对 404 主机的每次创建、修改、启停、删除都会写入审计日志audit-log表action 分别为created/updated/enabled/disabled/deleted配合访问日志即可完整还原谁在何时改动了配置、哪些流量还在访问该域名。常见问题与注意事项404 主机能返回自定义错误页吗可以。利用advanced_config字段注入自定义location或error_page指令即可覆盖默认的return 404行为实现品牌化的错误页面也可以直接在容器挂载的自定义 Nginx 目录中放置server_dead.conf配置。域名冲突怎么办同一个域名不能被两台主机代理/重定向/404同时占用创建时会立即校验并返回ValidationError。这意味着你需要先把旧的代理主机删除或改绑才能把域名交给 404 主机。删除后流量去哪里删除 404 主机会同时删除其 Nginx 配置并 reload此后该域名将不再由 Nginx Proxy Manager 处理回到默认站点或直接连接失败不再返回 404。证书随主机删除吗不会自动删除证书。删除 404 主机只做软删除标记与配置清理关联的证书对象仍保留在证书列表中可在 Certificates 中另行管理。总结404 主机Dead Host是 Nginx Proxy Manager 中一类小而实用的主机类型不转发任何流量只向访问者返回 404 页面并在这一简单行为之上提供了 SSL/HSTS/HTTP2、自定义 Nginx 配置、独立访问日志、完整 REST API 与审计追踪等完整能力。它最适合两类场景下线域名/失效页面的 SEO 清理用规范且美观的 404 明确告知搜索引擎内容已不存在与残留流量观测借助按主机隔离的访问日志分析引用来源。理解其数据模型与 dead_host.conf 模板的生成逻辑后你就能在界面、API 甚至自定义配置三个层面自如地管理它。【免费下载链接】nginx-proxy-managerDocker container for managing Nginx proxy hosts with a simple, powerful interface项目地址: https://gitcode.com/GitHub_Trending/ng/nginx-proxy-manager创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考