chrony接收Kiss of Deaths(KoD)问题及配置优化咨询

嗨，我来帮你梳理下这个chrony的KoD问题和配置优化的思路，结合你的场景给出一些实用建议～

一、要不要在意KoD错误？ #

首先得明确：偶尔出现的KoD不用过度焦虑，但频繁触发的话确实需要重视。

KoD（Kiss of Death）是公共NTP服务器发送的“拒绝服务”信号，通常原因是请求频率过高、服务器负载饱和，或者你的IP被服务器的限流机制盯上了。你已经把minpoll设到10（对应1024秒，约17分钟）、maxpoll到12（4096秒，约1小时10分钟），这个请求频率已经很低了，还收到KoD可能是公共池里的部分服务器限流规则更严格，或者你的网络出口IP在某些服务器的灰名单里。

如果只是偶尔出现，chrony会自动跳过这些服务器，切换到池里的其他节点，不会影响整体同步稳定性。但如果KoD频繁出现，会导致chrony可选的同步源减少，万一公司NTP服务器也掉链子，就可能出现时钟偏移风险，所以还是得针对性调整。

二、只依赖公司NTP服务器的风险与折中方案 #

你担心只用工司服务器会因为它lag导致时钟偏移，这个顾虑很合理——单源同步确实有单点故障风险，完全放弃公共池不是最优解。这里给你几个折中方案：

1. 优化公共池配置，减少KoD触发 #

• 改用地区性NTP池：比如如果你的业务在国内，换成cn.pool.ntp.org这类地区池，服务器距离更近、负载相对更低，能降低KoD概率。甚至可以用更细分的地区池（比如1.asia.pool.ntp.org），效果更好。
• 调整poll参数：可以把maxpoll调到13（对应8192秒，约2小时20分钟），进一步降低请求频率，减少触发服务器限流的可能。
• 用pool指令替代多个server：你的配置里写了4个公共池server，不如换成pool指令让chrony自动管理节点：

  pool 0.cn.pool.ntp.org iburst minpoll 10 maxpoll 13
  

  这样chrony会从池里自动选择可用服务器，避免反复请求同一个可能限流的节点。
• 忽略频繁发KoD的服务器：如果日志里发现某几个服务器总发KoD，可以用ignore指令拉黑它们，比如：

  ignore 0.pool.ntp.org
  

2. 强化公司服务器的优先级，同时保留冗余 #

你的配置里已经给公司服务器加了prefer，这会让chrony优先选择它同步，这个设置很合理。再配合以下配置增强稳定性：

• 保留maxdistance 5.0：这个参数会让chrony拒绝同步时间差超过5秒的服务器，一旦公司服务器lag超过这个阈值，chrony会自动切换到公共池，避免同步到错误时间。
• 启用makestep快速修正时钟：如果之前没开这个参数，可以加上：

  makestep 1.0 3
  

  意思是当时间差超过1秒时，chrony会在3次同步周期内快速调整时钟（而不是慢慢漂移），避免时钟skew导致其他服务报错。注意生产环境如果对时钟连续性要求极高，可以把阈值调小（比如0.5秒），或者谨慎开启。
• 不要调整stratumweight到过低：你现在设了stratumweight 0.001，这个参数会让chrony几乎不考虑服务器的stratum等级。其实公司服务器是Stratum5，公共池可能有更低的stratum节点，但你已经用prefer给公司服务器最高优先级，所以把stratumweight调回默认值（比如0.01）也没问题，不会影响公司服务器的优先地位，还能让chrony在选择备选节点时更合理。

总结下来的推荐配置 #

# 公司NTP服务器，优先使用
server MY_NTP_SERVER iburst prefer

# 地区性公共池作为冗余，降低KoD概率
pool 0.cn.pool.ntp.org iburst minpoll 10 maxpoll 13

# 拒绝时间差过大的服务器
maxdistance 5.0

# 快速修正时钟偏移，避免服务报错
makestep 1.0 3

# 恢复默认stratum权重，合理选择备选节点
stratumweight 0.01

备注：内容来源于stack exchange，提问作者aurelius