Nginx 配置修改：先检查，再平滑加载 一台 VPS 上可能同时托管博客、面板和其他入口。只改目标站点，并使用平滑加载，可以减少对其他服务的影响。找到实际配置nginx -t nginx -T第二条会输出全部配置，可能含上游认证信息，结果只在管理员终端查看，不直接贴到公开文章。重点查目标 server_name、include 路径和端口监听关系。修改前保存原件给目标配置留带日期的副本，保存在仅管理员可读的维护目录。不要把带凭据的 .bak 放进网站根目录，避免被静态文件规则下载。配置通过后才加载nginx -t && nginx -s reload平滑加载会让新请求使用新配置，已有工作进程完成当前请求后退出。仍需检查错误日志和实际入口，因为语法正确不等于上游可用。验证四种请求首页与文章正常返回。管理员登录不被缓存。静态资源无 404。未知路径保持真实 404，不缓存登录失败。若回滚，恢复原配置后再次检查并加载。记录此次改动影响的域名和服务，便于后续维护者快速判断范围。

VPS 测速先分清：延迟、吞吐与真实访问 同一台服务器，测速网站结果和打开博客的体感可能完全不同。它们测试的线路、时间和数据量不一样，不能用一次测速替代实际业务检查。先记录测试条件记录所在网络、测试时间、目标域名和协议；确认是否经过本机代理。对小网页，解析、连接和 TLS 建立时间常常比下载吞吐更影响体验。curl -o /dev/null -s -w "dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} first=%{time_starttransfer} total=%{time_total}\n" https://YOUR-DOMAIN/做少量重复测试在同一网络做三次请求，再换一个时间段比较。第一次可能建立连接或填充缓存，后续请求更接近日常访问；不要把其中最快的一次当作长期保证。根据瓶颈选择调整首字节慢：检查应用查询和页面缓存。静态资源多：减少重复脚本和过大封面。不同地区差异大：比较实际访问线路和服务商网络。丢包持续：先收集时间和路由证据，再向服务商反馈。拥塞控制只能处理其中一部分因素。内核参数不是越多越好；每次调整记录原值、测试方法和回滚命令，最后以真实站点的访问结果判断。

Linux 服务启动失败：把排查缩小到三个入口 服务报错时先不要反复重启。记录失败时间、最近变更和服务名，再分别检查进程、日志与监听端口。第一步：看服务的最后状态systemctl status SERVICE --no-pager -l journalctl -u SERVICE --since "30 minutes ago" --no-pager把 SERVICE 替换为实际服务名。注意退出代码、配置文件路径和失败前最后一条日志。日志可能含个人资料，分享前只保留与错误有关的部分并脱敏。第二步：区分启动失败与无法访问ss -lntp df -h df -i进程存在但端口未监听，通常仍属于服务内部问题；端口只监听回环地址，需要检查原有反向代理入口。空间或 inode 耗尽也会导致服务无法写临时文件，不应直接删除未知业务目录。第三步：一次只改一个变量修改配置前保存副本，使用程序自带的配置检查命令。检查通过后执行 reload；程序不支持 reload 时再安排重启。修改后复查日志和业务请求，而不是只看进程变绿。留下能复用的记录记录版本、触发条件、错误原文、变更项和恢复方式。下一次相似故障先比对这些字段，避免重走所有排查步骤。