后端前端运维MCP 服务【免费下载链接】nginx-uiYet another WebUI for Nginx项目地址https://gitcode.com/gh_mirrors/ngi/nginx-ui点击查看免费下载Site Check站点巡检器是 Nginx UI 内置的健康检查服务它周期性探测 Nginx 所服务的每一个server_name持续刷新 Dashboard站点导航页上的在线 / 离线状态指示。本指南以官方配置文档 config-sitecheck.md 为主体结合仓库源码讲解[site_check]配置节的三个核心参数Enabled、Concurrency、IntervalSeconds的作用、默认值、取值范围与底层实现原理帮助你在保证巡检实时性的同时避免对出口网络和路由器连接跟踪表造成过载。读完本文你将掌握如何通过app.ini精确调优站点巡检的频率与并发度、各参数在源码中的生效路径以及巡检器为规避 conntrack 耗尽所做的连接池设计从而在域名解析出大量 A 记录的场景ngrok、AWS 负载均衡、Cloudflare 等下安全运行。Site Check 是什么从server_name到 Dashboard 状态Site Checker 会收集 Nginx 配置中所有已启用的站点server_name并定期对每个站点发出健康探测请求。探测结果在线 / 离线 / 出错、HTTP 状态码、响应耗时、站点标题、favicon、TLS 证书剩余天数等通过 WebSocket 推送给前端最终呈现在 Dashboard 的状态指示器上。从源码看整个巡检由 internal/sitecheck/service.go 中的Service单例驱动启动时Init会先执行一次数据校准ReconcileSiteConfigSiteIDsIfDirty随后启动两个常驻 goroutine一个是“初始收集”协程等待缓存扫描完成后立即执行一次全量巡检另一个是“周期巡检”协程按配置的间隔反复执行每次巡检分两步CollectSites()从缓存扫描结果中收集已启用站点的 URLCheckAllSites()再对这些 URL 并发发起探测巡检完成后通过broadcastUpdate回调把结果推送给 WebSocket 客户端前端据此刷新状态指示。需要特别说明的是虽然本配置文档只涉及[site_check]全局节但每个站点自身还有独立的健康检查配置site_configs表中的HealthCheckEnabled、CheckInterval、Timeout等字段详见 model/site_config.go。全局开关与站点级开关是“与”的关系——只有两者都启用该站点才会真正被探测源码中EffectiveHealthCheckEnabled: settings.SiteCheckSettings.Enabled config.HealthCheckEnabled。为什么要关注并发与频率conntrack 过载问题在讨论参数之前先理解文档强调的边界条件。当你的server_name解析到会返回大量 A 记录的入口服务如 ngrok、AWS 负载均衡器、Cloudflare时如果巡检器不加以约束一轮巡检可能同时打开大量并发出站 TCP 连接足以耗尽家用 / 小型路由器如 UniFi上的 conntrack 连接跟踪表导致路由器性能劣化甚至断网对应上游 issue #1608。因此Nginx UI 的巡检器在三个层面控制出站连接数量全局并发上限Concurrency参数限制单轮巡检中同时进行的健康检查数量每主机连接上限共享 HTTP Transport 将MaxConnsPerHost与MaxIdleConnsPerHost都设为2见 internal/sitecheck/httpclient.go即使某个主机名解析出再多的 A 记录同一时刻对它的并发连接也不会超过 2 个同目标去重合并checkAllSites会把解析到同一host:port、且探测配置相同的多个server_name别名合并为一次网络探测结果再扇出到各个别名见 internal/sitecheck/checker.go避免多 server_name 配置成倍放大出站连接。此外共享拨号器还通过FallbackDelay: -1禁用了 Happy Eyeballs 的 IPv6 竞速探测以抑制 TIME_WAIT 连接风暴。理解这些机制后下面三个参数的调优就有了明确依据。参数一Enabled全局开关属性值类型bool默认值true适用版本 v2.3.6当Enabled false时Site Checker 服务不会执行任何周期巡检也不会代表巡检器打开任何出站连接。此时 Dashboard 会继续显示最近一次已知的状态首次启动且从未巡检过则为空状态。需要澄清的是从 internal/sitecheck/service.go 的实现看服务进程本身仍会启动“站点发现”CollectSites也照常进行——这样 Dashboard 仍能展示已配置的站点列表被禁止的只是实际的网络探测。checkAllSites在检测到Enabled false时会直接跳过探测并广播一次状态刷新见 internal/sitecheck/checker.go。适合关闭的场景你完全不需要自动化健康检查只想把 Nginx UI 当作纯配置管理面板巡检器正在给上游服务或网络带来困扰例如某些内网主机无法从外部探测、被防火墙拦截等需要立即止血。关闭后每个站点的HealthCheckDisabledReason会被标记为global站点自身关闭则标记为site便于前端展示停用原因。参数二Concurrency单轮巡检并发上限属性值类型int默认值5取值范围[1, 20]适用版本 v2.3.6Concurrency决定一次完整巡检过程中同时进行的健康检查的最大数量调低如1突发性最低出站连接最平缓但整轮巡检耗时变长调高如20整轮巡检更快完成但瞬时出站连接更多。该参数在checkAllSites中以信号量semaphore : make(chan struct{}, concurrency)实现每个探测任务在发起前先获取一个信号量槽位从而严格限制同时执行的探测数见 internal/sitecheck/checker.go。关于取值范围与防护逻辑请对照 settings/sitecheck.go 的实现结构体上的校验标签为binding:omitempty,min1,max20即通过 API 提交时会被限制在 120运行期的GetConcurrency()方法会做二次防御低于1回退为默认值5高于20截断为20。因此即使配置文件被人为写入超范围值也不会导致巡检失控。另外注意Concurrency是“每个探测任务”的并发上限而每个探测任务内部对同一主机的连接又被MaxConnsPerHost 2约束两者叠加才是真实的出站连接峰值。如果你托管了大量站点且网络设备 conntrack 能力有限建议优先保持较低的并发值而不是只依赖每主机连接上限。参数三IntervalSeconds巡检间隔属性值类型int默认值300即 5 分钟最小值30适用版本 v2.3.6IntervalSeconds控制 Site Checker 对全部已收集站点重新发起一轮巡检的频率。默认 5 分钟在“状态新鲜度”与“网络负载”之间取得了平衡。低于 30 的值会被钳制回默认值 300而不是 30这是 settings/sitecheck.go 中GetInterval()的行为func (s *SiteCheck) GetInterval() time.Duration { seconds : s.IntervalSeconds if seconds minSiteCheckIntervalSeconds { // 30 seconds defaultSiteCheckIntervalSeconds // 300 } return time.Duration(seconds) * time.Second }周期巡检循环位于 internal/sitecheck/service.go每个周期用time.NewTimer(settings.SiteCheckSettings.GetInterval())起一个定时器触发后执行“重新收集 全量探测”。注意这里读取的间隔是每次循环开始时的最新值因此修改配置后无需重启即可在下一个周期生效。需要区分的是这个全局IntervalSeconds是“全量巡检的周期”而每个站点还有独立的CheckInterval默认 300 秒API 校验范围 303600 秒。在checkAllSites中若站点自身的CheckInterval尚未到期time.Since(LastChecked) CheckInterval该站点会跳过本轮探测见 internal/sitecheck/checker.go。也就是说全局间隔决定“多久扫一轮”站点级间隔决定“这一轮里谁真正被测”。完整配置示例官方文档给出的最小完整配置如下写入app.ini的[site_check]节[site_check] Enabled true Concurrency 5 IntervalSeconds 300更贴近实际调优场景的几种写法; 高流量 / 弱路由器环境低并发、慢节奏最大限度平抑出站连接 [site_check] Enabled true Concurrency 1 IntervalSeconds 600 ; 内网快速巡检提高并发换取更短的整轮巡检时间 [site_check] Enabled true Concurrency 20 IntervalSeconds 60 ; 完全关闭巡检Dashboard 保留上次状态 [site_check] Enabled false配置的加载链路为settings.Init把SITE_CHECK前缀映射到SiteCheckSettingssettings/settings.go同时注册site_check节同文件第 72 行支持 INI 文件与环境变量前缀NGINX_UI_SITE_CHECK_字段名大写如NGINX_UI_SITE_CHECK_ENABLED两种方式。在 Web 管理界面“系统设置”中修改该节参数后SaveSettings会调用service.SettingsChanged()立即中断当前定时器并触发一次刷新见 api/settings/settings.go 与 internal/sitecheck/service.go无需重启进程。三个参数的联动与调优建议参数默认值合法范围主要影响建议Enabledtruebool是否执行任何出站探测出问题时优先用它一键止血Concurrency51 ~ 20越界自动钳制单轮巡检瞬时出站连接数站点多 / 路由器弱时调低IntervalSeconds300 30低于 30 回退默认状态刷新频率与长期负载对实时性要求高再调低三条实用结论先关后查遇到巡检导致的上游 / 网络问题时先把Enabled置为false确认是否巡检器所致再决定是降低Concurrency还是拉长IntervalSeconds并发与间隔是互补的同样的一轮全量巡检低并发 长间隔最省连接高并发只适合对整轮耗时敏感且网络设备强健的环境不要只调全局参数对个别敏感站点可优先使用站点级配置如关闭该站点的健康检查、拉长其CheckInterval避免全局降频影响所有站点的状态新鲜度。站点级健康检查配置可通过 api/sites/sitecheck.go 中的UpdateHealthCheck接口修改并支持在集群节点间同步SyncHealthCheck。源码佐证与深入阅读如果你希望进一步验证或研究巡检器实现以下仓库路径可作为起点配置定义与取值钳制settings/sitecheck.go配置节注册与保存链路settings/settings.go巡检服务生命周期启动、周期循环、刷新合并、设置热更新internal/sitecheck/service.go探测执行并发信号量、同目标合并、标题 / favicon 提取、证书剩余天数internal/sitecheck/checker.go连接池与 TLS 决策MaxConnsPerHost 2、共享 / 验证型双 Transport、ValidateSSL与自签名站点判定internal/sitecheck/httpclient.go故障分类DNS / 超时 / 连接拒绝 / TLS / 状态码 / 内容校验等ErrorTypeinternal/sitecheck/errorclass.go站点级健康检查配置模型HealthCheckConfig、SiteConfigmodel/site_config.go健康检查配置的读写与集群同步 APIapi/sites/sitecheck.go测试用例覆盖禁用巡检、并发限制、自签名站点等行为internal/sitecheck/service_test.go、internal/sitecheck/selfsigned_test.go总而言之[site_check]三个参数虽然简单却是 Nginx UI 巡检子系统最核心的“节流阀”。结合本文给出的源码级原理与调优建议你可以在保持 Dashboard 状态实时性的同时稳妥地控制出站连接规模避免重蹈 conntrack 过载的覆辙。赞分享后端前端运维MCP 服务【免费下载链接】nginx-uiYet another WebUI for Nginx项目地址https://gitcode.com/gh_mirrors/ngi/nginx-ui点击查看免费下载相关推荐gVisor iptables 集成测试从 Docker 配置到 TestCase 框架的完整实战指南gVisor iptables 集成测试从 Docker 配置到 TestCase 框架的完整实战指南 gVisorrunsc在 raw socket /后端前端运维MCP 服务TDengine taosinspect 巡检工具详解参数、配置文件与全量巡检范围TDengine taosinspect 巡检工具详解参数、配置文件与全量巡检范围 本文详解 TDengine 巡检工具 taosinspect 的使用方法数据库时序数据库大数据物联网云原生VitePress 站点配置完全指南Site Config 选项详解与构建钩子实战VitePress 站点配置完全指南Site Config 选项详解与构建钩子实战 本指南基于 VitePressVite Vue 驱动的静态站点生成器前端文档创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/23 22:24:15 · 阅读 1.2k Nginx UI Site Check 站点巡检器配置详解：Enabled、Concurrency 与 IntervalSeconds
后端前端运维MCP 服务【免费下载链接】nginx-uiYet another WebUI for Nginx项目地址https://gitcode.com/gh_mirrors/ngi/nginx-ui点击查看免费下载Site Check站点巡检器是 Nginx UI 内置的健康检查服务它周期性探测 Nginx 所服务的每一个server_name持续刷新 Dashboard站点导航页上的在线 / 离线状态指示。本指南以官方配置文档 config-sitecheck.md 为主体结合仓库源码讲解[site_check]配置节的三个核心参数Enabled、Concurrency、IntervalSeconds的作用、默认值、取值范围与底层实现原理帮助你在保证巡检实时性的同时避免对出口网络和路由器连接跟踪表造成过载。读完本文你将掌握如何通过app.ini精确调优站点巡检的频率与并发度、各参数在源码中的生效路径以及巡检器为规避 conntrack 耗尽所做的连接池设计从而在域名解析出大量 A 记录的场景ngrok、AWS 负载均衡、Cloudflare 等下安全运行。Site Check 是什么从server_name到 Dashboard 状态Site Checker 会收集 Nginx 配置中所有已启用的站点server_name并定期对每个站点发出健康探测请求。探测结果在线 / 离线 / 出错、HTTP 状态码、响应耗时、站点标题、favicon、TLS 证书剩余天数等通过 WebSocket 推送给前端最终呈现在 Dashboard 的状态指示器上。从源码看整个巡检由 internal/sitecheck/service.go 中的Service单例驱动启动时Init会先执行一次数据校准ReconcileSiteConfigSiteIDsIfDirty随后启动两个常驻 goroutine一个是“初始收集”协程等待缓存扫描完成后立即执行一次全量巡检另一个是“周期巡检”协程按配置的间隔反复执行每次巡检分两步CollectSites()从缓存扫描结果中收集已启用站点的 URLCheckAllSites()再对这些 URL 并发发起探测巡检完成后通过broadcastUpdate回调把结果推送给 WebSocket 客户端前端据此刷新状态指示。需要特别说明的是虽然本配置文档只涉及[site_check]全局节但每个站点自身还有独立的健康检查配置site_configs表中的HealthCheckEnabled、CheckInterval、Timeout等字段详见 model/site_config.go。全局开关与站点级开关是“与”的关系——只有两者都启用该站点才会真正被探测源码中EffectiveHealthCheckEnabled: settings.SiteCheckSettings.Enabled config.HealthCheckEnabled。为什么要关注并发与频率conntrack 过载问题在讨论参数之前先理解文档强调的边界条件。当你的server_name解析到会返回大量 A 记录的入口服务如 ngrok、AWS 负载均衡器、Cloudflare时如果巡检器不加以约束一轮巡检可能同时打开大量并发出站 TCP 连接足以耗尽家用 / 小型路由器如 UniFi上的 conntrack 连接跟踪表导致路由器性能劣化甚至断网对应上游 issue #1608。因此Nginx UI 的巡检器在三个层面控制出站连接数量全局并发上限Concurrency参数限制单轮巡检中同时进行的健康检查数量每主机连接上限共享 HTTP Transport 将MaxConnsPerHost与MaxIdleConnsPerHost都设为2见 internal/sitecheck/httpclient.go即使某个主机名解析出再多的 A 记录同一时刻对它的并发连接也不会超过 2 个同目标去重合并checkAllSites会把解析到同一host:port、且探测配置相同的多个server_name别名合并为一次网络探测结果再扇出到各个别名见 internal/sitecheck/checker.go避免多 server_name 配置成倍放大出站连接。此外共享拨号器还通过FallbackDelay: -1禁用了 Happy Eyeballs 的 IPv6 竞速探测以抑制 TIME_WAIT 连接风暴。理解这些机制后下面三个参数的调优就有了明确依据。参数一Enabled全局开关属性值类型bool默认值true适用版本 v2.3.6当Enabled false时Site Checker 服务不会执行任何周期巡检也不会代表巡检器打开任何出站连接。此时 Dashboard 会继续显示最近一次已知的状态首次启动且从未巡检过则为空状态。需要澄清的是从 internal/sitecheck/service.go 的实现看服务进程本身仍会启动“站点发现”CollectSites也照常进行——这样 Dashboard 仍能展示已配置的站点列表被禁止的只是实际的网络探测。checkAllSites在检测到Enabled false时会直接跳过探测并广播一次状态刷新见 internal/sitecheck/checker.go。适合关闭的场景你完全不需要自动化健康检查只想把 Nginx UI 当作纯配置管理面板巡检器正在给上游服务或网络带来困扰例如某些内网主机无法从外部探测、被防火墙拦截等需要立即止血。关闭后每个站点的HealthCheckDisabledReason会被标记为global站点自身关闭则标记为site便于前端展示停用原因。参数二Concurrency单轮巡检并发上限属性值类型int默认值5取值范围[1, 20]适用版本 v2.3.6Concurrency决定一次完整巡检过程中同时进行的健康检查的最大数量调低如1突发性最低出站连接最平缓但整轮巡检耗时变长调高如20整轮巡检更快完成但瞬时出站连接更多。该参数在checkAllSites中以信号量semaphore : make(chan struct{}, concurrency)实现每个探测任务在发起前先获取一个信号量槽位从而严格限制同时执行的探测数见 internal/sitecheck/checker.go。关于取值范围与防护逻辑请对照 settings/sitecheck.go 的实现结构体上的校验标签为binding:omitempty,min1,max20即通过 API 提交时会被限制在 120运行期的GetConcurrency()方法会做二次防御低于1回退为默认值5高于20截断为20。因此即使配置文件被人为写入超范围值也不会导致巡检失控。另外注意Concurrency是“每个探测任务”的并发上限而每个探测任务内部对同一主机的连接又被MaxConnsPerHost 2约束两者叠加才是真实的出站连接峰值。如果你托管了大量站点且网络设备 conntrack 能力有限建议优先保持较低的并发值而不是只依赖每主机连接上限。参数三IntervalSeconds巡检间隔属性值类型int默认值300即 5 分钟最小值30适用版本 v2.3.6IntervalSeconds控制 Site Checker 对全部已收集站点重新发起一轮巡检的频率。默认 5 分钟在“状态新鲜度”与“网络负载”之间取得了平衡。低于 30 的值会被钳制回默认值 300而不是 30这是 settings/sitecheck.go 中GetInterval()的行为func (s *SiteCheck) GetInterval() time.Duration { seconds : s.IntervalSeconds if seconds minSiteCheckIntervalSeconds { // 30 seconds defaultSiteCheckIntervalSeconds // 300 } return time.Duration(seconds) * time.Second }周期巡检循环位于 internal/sitecheck/service.go每个周期用time.NewTimer(settings.SiteCheckSettings.GetInterval())起一个定时器触发后执行“重新收集 全量探测”。注意这里读取的间隔是每次循环开始时的最新值因此修改配置后无需重启即可在下一个周期生效。需要区分的是这个全局IntervalSeconds是“全量巡检的周期”而每个站点还有独立的CheckInterval默认 300 秒API 校验范围 303600 秒。在checkAllSites中若站点自身的CheckInterval尚未到期time.Since(LastChecked) CheckInterval该站点会跳过本轮探测见 internal/sitecheck/checker.go。也就是说全局间隔决定“多久扫一轮”站点级间隔决定“这一轮里谁真正被测”。完整配置示例官方文档给出的最小完整配置如下写入app.ini的[site_check]节[site_check] Enabled true Concurrency 5 IntervalSeconds 300更贴近实际调优场景的几种写法; 高流量 / 弱路由器环境低并发、慢节奏最大限度平抑出站连接 [site_check] Enabled true Concurrency 1 IntervalSeconds 600 ; 内网快速巡检提高并发换取更短的整轮巡检时间 [site_check] Enabled true Concurrency 20 IntervalSeconds 60 ; 完全关闭巡检Dashboard 保留上次状态 [site_check] Enabled false配置的加载链路为settings.Init把SITE_CHECK前缀映射到SiteCheckSettingssettings/settings.go同时注册site_check节同文件第 72 行支持 INI 文件与环境变量前缀NGINX_UI_SITE_CHECK_字段名大写如NGINX_UI_SITE_CHECK_ENABLED两种方式。在 Web 管理界面“系统设置”中修改该节参数后SaveSettings会调用service.SettingsChanged()立即中断当前定时器并触发一次刷新见 api/settings/settings.go 与 internal/sitecheck/service.go无需重启进程。三个参数的联动与调优建议参数默认值合法范围主要影响建议Enabledtruebool是否执行任何出站探测出问题时优先用它一键止血Concurrency51 ~ 20越界自动钳制单轮巡检瞬时出站连接数站点多 / 路由器弱时调低IntervalSeconds300 30低于 30 回退默认状态刷新频率与长期负载对实时性要求高再调低三条实用结论先关后查遇到巡检导致的上游 / 网络问题时先把Enabled置为false确认是否巡检器所致再决定是降低Concurrency还是拉长IntervalSeconds并发与间隔是互补的同样的一轮全量巡检低并发 长间隔最省连接高并发只适合对整轮耗时敏感且网络设备强健的环境不要只调全局参数对个别敏感站点可优先使用站点级配置如关闭该站点的健康检查、拉长其CheckInterval避免全局降频影响所有站点的状态新鲜度。站点级健康检查配置可通过 api/sites/sitecheck.go 中的UpdateHealthCheck接口修改并支持在集群节点间同步SyncHealthCheck。源码佐证与深入阅读如果你希望进一步验证或研究巡检器实现以下仓库路径可作为起点配置定义与取值钳制settings/sitecheck.go配置节注册与保存链路settings/settings.go巡检服务生命周期启动、周期循环、刷新合并、设置热更新internal/sitecheck/service.go探测执行并发信号量、同目标合并、标题 / favicon 提取、证书剩余天数internal/sitecheck/checker.go连接池与 TLS 决策MaxConnsPerHost 2、共享 / 验证型双 Transport、ValidateSSL与自签名站点判定internal/sitecheck/httpclient.go故障分类DNS / 超时 / 连接拒绝 / TLS / 状态码 / 内容校验等ErrorTypeinternal/sitecheck/errorclass.go站点级健康检查配置模型HealthCheckConfig、SiteConfigmodel/site_config.go健康检查配置的读写与集群同步 APIapi/sites/sitecheck.go测试用例覆盖禁用巡检、并发限制、自签名站点等行为internal/sitecheck/service_test.go、internal/sitecheck/selfsigned_test.go总而言之[site_check]三个参数虽然简单却是 Nginx UI 巡检子系统最核心的“节流阀”。结合本文给出的源码级原理与调优建议你可以在保持 Dashboard 状态实时性的同时稳妥地控制出站连接规模避免重蹈 conntrack 过载的覆辙。赞分享后端前端运维MCP 服务【免费下载链接】nginx-uiYet another WebUI for Nginx项目地址https://gitcode.com/gh_mirrors/ngi/nginx-ui点击查看免费下载相关推荐gVisor iptables 集成测试从 Docker 配置到 TestCase 框架的完整实战指南gVisor iptables 集成测试从 Docker 配置到 TestCase 框架的完整实战指南 gVisorrunsc在 raw socket /后端前端运维MCP 服务TDengine taosinspect 巡检工具详解参数、配置文件与全量巡检范围TDengine taosinspect 巡检工具详解参数、配置文件与全量巡检范围 本文详解 TDengine 巡检工具 taosinspect 的使用方法数据库时序数据库大数据物联网云原生VitePress 站点配置完全指南Site Config 选项详解与构建钩子实战VitePress 站点配置完全指南Site Config 选项详解与构建钩子实战 本指南基于 VitePressVite Vue 驱动的静态站点生成器前端文档创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考