轻量服务器入口：https://cloud.tencent.com/product/lighthouse 云服务器CVM入口：https://cloud.tencent.com/product/cvm GPU云服务器入口：https://cloud.tencent.com/product/gpu 云数据库入口：https://cloud.tencent.com/product/tdsqlc... 展开详请

带宽跑不满别光盯着网卡，90%的瓶颈根本不在网络层。按这个顺序查，十分钟定位： 先看应用本身 ：top或htop看CPU和内存是否打满，进程是否在等IO（iowait高）；用ss -s看TCP连接数和发送队列，如果Send-Q堆积、连接数远低于预期，说明应用吐数据太慢，不是带宽问题。 再查磁盘IO ：iostat -x 1盯%util和await。若磁盘利用率长期>80%或等待时间超20ms，说明读写拖慢了响应，带宽自然上不去。SSD云盘也可能被限IOPS，控制台看监控确认是否触顶。 最后验网络 ：iperf3对端测速排除链路问题；ethtool eth0看网卡丢包/错误计数；检查安全组、QoS策略是否限速。若iperf能跑满但业务不行，铁定是前两步的问题。 记住：带宽是结果，不是原因。应用慢→响应延迟高→并发上不去→带宽闲置，这才是真实链条。别一上来就升带宽，先让应用把数据“吐”出来。 官方详细解决方案：https://cloud.tencent.com/document/product/1207... 展开详请

先固定变量再下结论。在CVM上用客户端持续探活执行select 1并计时，同时长ping数据库内网IP看丢包率。超时发生时分三种形态判断：连接建立就超时，telnet内网端口不通，偏向网络层或连接数打满；TCP握手成功但查询慢，看数据库的Threads_connected、锁等待和慢查询日志；偶发丢包，检查是否跨可用区、安全组和ACL有没有限速。云监控里拉数据库连接数和CPU曲线对齐故障时间点，必要时在CVM上抓包看SYN有没有得到回应。实战里最常见的反而是应用侧连接池没配好，突发流量排队建连，先查这个再怀疑云。... 展开详请

先装 chrony：yum install -y chrony 或 apt install -y chrony。编辑 /etc/chrony.conf，注释掉默认 pool，加腾讯云内网 NTP：server ntp.tencentyun.com iburst，保存后重启服务 systemctl enable --now chronyd。 验证别只看 date，用 chronyc sources -v 看源状态，* 表示已同步；chronyc tracking 查偏移量，System time 应小于 10ms。若显示 ? 或偏移持续增大，检查安全组是否放行 UDP 123，或换 ntp.tencent.com 重试。 CVM 默认可能跑着 ntpd，务必先停掉避免冲突：systemctl stop ntpd && systemctl disable ntpd。校时生效后，建议加个 cron 每小时跑一次 chronyc tracking | grep 'System time' 写日志，方便事后排查时间跳变。 官方详细解决方案：https://cloud.tencent.com/product/cvm... 展开详请

别折腾SCP，直接上 rsync 最稳。 先确认你手里的是 Linux 版服务端（ZomboidServer.x64），别把 Windows 的 .exe 传上去，跑不起来。 命令很简单： rsync -avz ./pz-server/ user@IP:/home/user/pz-server/ 传完进服务器 chmod +x ZomboidServer.x64 加权限。启动记得带参数：./ZomboidServer.x64 -batchmode -nographics。 强烈建议用 screen 或 tmux 挂着，不然 SSH 断了服务就崩了。端口 16261 UDP/TCP 记得在防火墙放行。配置文件改好 server.ini 里的 IP 和存档路径，搞定。 官方详细解决方案：https://cloud.tencent.com/product/lighthouse... 展开详请

别慌，先确认是不是权限卡脖子。很多云数据库工具默认给的是只读账号，或者新开的实例没给你 DDL 权限（CREATE/ALTER），直接报“Access Denied”。 其次，检查连接配置。是不是 IP 白名单没加你当前机器的外网 IP？或者密码过期了？有时候就是个小疏忽。 如果权限和网络都没问题，看看控制台有没有维护窗口。有些云服务在备份或升级期间会锁定元数据，暂时不让改结构。 最后，试着重启下 WorkBuddy 客户端，或者换个浏览器试试，排除本地缓存导致的假死。实在不行，直接连命令行用 SQL 跑一下，看是工具 Bug 还是数据库真挂了。 官方详细解决方案：https://cloud.tencent.com/product/workbuddy-enterprise?Is=sdk-topnav... 展开详请

别被 UnauthorizedOperation 吓住，这通常就是权限没给对。先抓重点： 检查动作名称（Action）：这是最常见坑点。比如你要调 CVM 的 DescribeInstances，策略里必须写 cvm:DescribeInstances，少个前缀或拼错都报错。去 API 文档复制标准 Action 名，别自己编。 看资源范围（Resource）：如果策略里写了 "Resource": "arn:qcs:...:instance/*"，但你操作的是特定实例 ID，且策略没包含它，就会拒之门外。测试时先用 "Resource": "*" 放行，确认能通后再收紧。 生效延迟：CAM 策略修改后可能有几秒到几分钟的同步延迟，刚改完就测容易翻车。 附加策略 vs 自定义策略：确认子账号挂载的是“系统策略”还是“自定义策略”。有时候你配了自定义策略，但没勾选“允许继承”，或者角色信任关系（Trust Policy）没绑对。 快速验证：临时给子账号挂上 AdministratorAccess，如果还能报这个错，那就是网络或签名问题；如果不报了，说明是具体 Action 或 Resource 写错了。 官方详细解决方案：https://cloud.tencent.com/product/cvm?Is=sdk-topnav... 展开详请

别慌，这是Linux系统没识别到新分区的问题。扩容只是后端加了空间，前端还得“认账”。 确认底层已扩容：先跑 lsblk 或 fdisk -l。如果这里显示的大小已经变大，说明云盘没问题，是系统层卡住了。 刷新分区表： 如果是LVM（推荐），直接跑 pvresize /dev/vdb1（假设你的盘符是vdb1）。 如果是普通分区且没格式化过新空间，可能需要 parted 或 growpart 工具扩展分区边界。 调整文件系统： ext4 文件系统：执行 resize2fs /dev/vdb1。 xfs 文件系统：执行 xfs_growfs /mount/point。 跑完这两个命令，再 df -h 看容量就回来了。记住，以后扩容前先把数据备份好，虽然在线扩容很稳，但手滑风险永远存在。 官方详细解决方案：https://cloud.tencent.com/product/cbs?Is=sdk-topnav... 展开详请

先别急着改代码，这通常是网络或配置层面的“背锅”。第一步，登录阿里云控制台，检查轻量服务器的防火墙设置。很多人忘了在控制台的“防火墙”标签页里放行Docker映射的端口（比如8080），光在Linux内部开没用，云厂商的安全组也得放行。 第二步，确认Docker容器是否真的监听在0.0.0.0而不是127.0.0.1。如果启动时绑定了本地回环地址，外网肯定连不上。可以用docker ps看下端口映射情况，或者进容器执行netstat -tlnp验证。 第三步，排查IP冲突或端口占用。有时候宿主机上其他服务占用了该端口，导致Docker没成功绑定。最后，试试在服务器本地用curl http://localhost:端口号测试，如果本地不通，那就是应用本身的问题；如果本地通但外网不通，90%是上述两步防火墙或绑定地址搞鬼。按这个顺序查，基本能解决。 官方详细解决方案：https://cloud.tencent.com/product/lighthouse?Is=sdk-topnav... 展开详请