宝塔面板默认不启用系统时间同步服务，需手动启用chronyd并配置云厂商ntp源；应用时间错乱是时区未设所致，与ntp无关。
宝塔面板里 ntpd 服务没启动，时间根本不会自动校准
宝塔装完默认不启用系统级时间同步，ntpd 或 chronyd 很可能处于 inactive (dead) 状态。这不是宝塔的 bug，而是 Linux 发行版（尤其是 CentOS 7+/Ubuntu 20.04+）默认策略：不自动开启 NTP 守护进程，避免与云平台自带的时间服务冲突。
实操建议：
- 先查状态：
systemctl status ntpd（CentOS 7）或systemctl status chronyd（CentOS 8+/Ubuntu） - 如果没运行，用
systemctl enable --now chronyd启用并开机自启（推荐chronyd，比ntpd更适合虚拟机/云服务器） - 别只跑
ntpdate -s time.windows.com临时同步——它不持续，下次重启又漂移 - 确认防火墙放行 UDP 123 端口（
firewall-cmd --add-port=123/udp --permanent），否则 chronyd 无法连外网 NTP 服务器
宝塔后台「计划任务」里手动加 NTP 同步脚本，反而可能冲突
有人在宝塔计划任务里添加每 5 分钟执行一次 ntpdate -s pool.ntp.org，结果发现时间跳变、日志报错 the NTP socket is in use。这是因为 ntpdate 是一次性强制校正工具，和正在运行的 chronyd 抢同一个 NTP socket，会干扰守护进程的平滑调整逻辑。
实操建议：
- 只要
chronyd正常运行，就别再用ntpdate脚本——它该干的事 chronyd 全包了 - 想验证是否生效，用
chronyc tracking查偏移量（Offset字段应为 ±50ms 内），比看系统时间更准 - 如果必须用计划任务（比如某些老系统没 chronyd），改用
sntp -sS pool.ntp.org，它不占 socket，但仍是临时方案
云服务器（阿里云/腾讯云）上 chronyd 同步失败，大概率是 NTP 源被拦截
内网环境或部分云厂商（尤其国内）会屏蔽公网 NTP 服务器（如 pool.ntp.org），导致 chronyc sources -v 显示所有源都是 ^X（failed）或 ^-（unreachable）。这不是配置写错，是网络策略卡死。
实操建议：
- 优先换用云厂商提供的内网 NTP 地址：
阿里云：ntp1.aliyun.com；腾讯云：time.tencentyun.com - 修改配置：
sed -i 's/^server.*/server ntp1.aliyun.com iburst/g' /etc/chrony.conf，然后systemctl restart chronyd - 别迷信“多加几个 server 行”——chronyd 默认只选最优 3 个，冗余配置无意义，还拖慢初始化
- KVM/物理机可放心用
pool.ntp.org，但 OpenVZ/Virtuozzo 虚拟机需联系服务商确认是否透传 NTP 请求
宝塔面板显示时间正常，但 PHP/Python 应用日志时间仍错乱
系统时间校准了，但 phpinfo() 里 date.timezone 还是 UTC，或者 Python 的 datetime.now() 输出 GMT 时间。这是应用层时区没设，跟 NTP 同步完全无关——系统时间和应用时区是两套机制。
实操建议：
- PHP：在
/www/server/php/{版本}/etc/php.ini中改date.timezone = Asia/Shanghai，然后service php-fpm restart - Python：不依赖系统时区，代码里显式指定：
datetime.now(timezone('Asia/Shanghai'))，或设环境变量TZ=Asia/Shanghai - 宝塔网站设置里「PHP 设置」→「禁用函数」若含
date_default_timezone_set，会导致 ini 配置失效，得先删掉 - Node.js 应用需在启动前加
TZ=Asia/Shanghai node app.js，否则new Date()仍按 UTC 解析
真正麻烦的是容器环境：Docker 默认不继承宿主机时区，docker run 必须加 -e TZ=Asia/Shanghai 或挂载 /etc/localtime，这点很容易漏。
