甲骨文免费 VPS 大概是白嫖圈里最香、也最让人提心吊胆的一台机器：4 核 24G 的 ARM 实例不要钱，代价是随时可能被回收、公网 IP 说换就换。我的那台跑了快两年，经历过一次换 IP、一次差点丢实例，踩过的坑都攒在这篇里。这篇接续站内旧文《甲骨文netboot重装系统遇见问题解决》，只讲保活和避坑，不讲怎么注册抢实例。
先搞清楚：实例是怎么丢的
甲骨文免费层有两个让人丢实例的机制，很多人是稀里糊涂中招的。
第一是闲置回收。 免费实例如果连续 7 天 CPU 利用率低于 20%、网络出入流量低于 20%，甲骨文有权回收。注意是“有权”，不是“一定”，但 ARM 库存紧张的时候，回收动作会明显变勤。很多人把实例当纯反代/跳板挂着，CPU 常年 1%~2%，这就是最危险的一类。
第二是区域库存与配额。 免费 ARM 实例在某些区域（比如东京、新加坡）常年缺货，实例一旦被删、被回收，同一区域很可能再也抢不到。换句话说，丢实例的代价不是“重开一台”，而是“这个区域可能再也没有了”。
第三是账单与合规。 免费层绑定的信用卡过期、扣款失败，或者账号被判定异常，实例会直接停掉。信用卡有效期不到三个月的，尽早更新。
所以保活的核心就一句话：让实例看起来一直在干活，同时保证它丢了也能快速重建。
保活第一步：别让 CPU 闲着
最简单的保活办法，是让实例定期有一点真实负载。我的做法是每天跑两次轻量任务：
- 用 cron 跑一个系统自检脚本：更新 apt 缓存、轮转日志、跑一遍备份检查，单次 CPU 能冲到 30%~50%，持续两三分钟；
- 实例上常驻一个真实服务：我挂的是 Lucky 反代和一个小型监控面板，本身就有进出流量。
# /etc/cron.d/keepalive 每天 8:00 / 20:00 跑一次自检
0 8,20 * * * root /usr/local/bin/daily-check.sh >> /var/log/daily-check.log 2>&1#!/bin/bash
# /usr/local/bin/daily-check.sh
apt update && apt list --upgradable
systemctl is-active lucky || systemctl restart lucky
df -h / && free -h关键点是别用纯空转脚本刷 CPU。甲骨文回收规则看的是 CPU 利用率和网络流量，空转脚本刷出来的 20% 利用率和真实负载在指标上没区别，但一旦被判定为滥用，账号风险更大。用真实任务（更新、备份、日志轮转）去产生负载，既合规又有用。
换 IP：甲骨文换 IP 的正确流程
甲骨文实例的公网 IP 是可以换的，免费层每月前 100 小时内更换不收费（实测小额操作基本不产生费用，但以账单为准）。换 IP 的场景有两个：IP 被墙、IP 段被拉黑。
操作流程：
- 控制台 → 实例详情 → 附加的 VNIC → 临时公共 IP → 编辑 → 选择“不分配公共 IP”并保存，等一分钟；
- 再编辑一次 → 选择“临时公共 IP” → 保存，系统会分配一个新 IP；
- 立即 SSH 登录确认新 IP 能通，再改下游配置。
换完 IP 要同步改的地方，我列个清单，漏一个就断一处：
- 域名解析：A 记录改成新 IP，TTL 提前一天改成 300 秒，换完再改回去；
- Lucky / FRP 的反代目标：如果你的群晖、NAS 服务是经这台 VPS 反代出去的，检查反代规则里的上游地址；
- 监控告警：Uptime Kuma 里监控项的地址要改，否则告警会一直误报；
- 白名单与防火墙：家里 NAS、路由器上如果按 IP 放行了这台 VPS，记得同步更新；
- SSL 证书：证书跟域名走，一般不用动，但如果用了 IP 直连的证书就要重新签。
我自己的教训：有次换完 IP 只改了域名解析，忘了 Lucky 里有一条规则写的是旧 IP 直连，结果图床反代断了半天才发现。从那以后换 IP 必按清单逐项打勾。
丢实例了怎么办：先抢，再重建
如果实例真的被回收了，别慌，按这个顺序处理：
1. 先确认是不是能抢回来。 控制台 → 创建实例 → 选原来的区域和形状（VM.Standard.A1.Flex），反复刷库存。ARM 免费实例的库存是动态释放的，凌晨和工作日上午相对容易刷到。刷到后立刻创建，别纠结配置，先占住再说。
2. 引导卷和数据盘还在吗？ 实例被回收时，引导卷一般也会被删，但如果你之前做了引导卷备份（控制台 → 块存储 → 引导卷备份），可以从备份恢复一个新实例。我的做法是每周自动备份一次引导卷，保留最近两份。
3. 重建后按清单恢复。 按“换 IP 清单”重新走一遍：DNS、反代、监控、防火墙、证书。我的 Lucky 配置、Docker compose 文件都在群晖上另存了一份，重建一台纯净实例后，传配置、起服务，半小时能恢复。
4. 如果这个区域彻底抢不到。 换区域（比如从东京换到首尔或孟买），或者接受现实：把核心服务迁回家里群晖，VPS 只留一个轻量反代。免费的东西，永远要有 Plan B。
监控与备份：丢之前就要配好
保活不是玄学，是监控 + 备份两件套：
- 监控：Uptime Kuma 监控 VPS 的 SSH 端口和几个关键服务，告警推到 Bark 或邮件。实例一停，5 分钟内就能知道，而不是等用户反馈才发现。部署方法见站内旧文《Uptime Kuma 监控告警：NAS、VPS、摄像头在线状态一屏看清》。
- 备份：引导卷每周备份；关键配置文件（Lucky 配置、nginx 配置、Docker compose）同步一份到群晖或 NAS 上。备份方案的思路见《群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好》。
- 留一台备用：条件允许的话，在另一个区域再养一台免费实例做冷备，平时只跑监控，主机一丢，改 DNS 就能顶上去。
避坑清单（照着打勾）
- 信用卡有效期保持在三个月以上，绑卡邮箱能收到账单提醒；
- 实例上常驻真实服务，别让 CPU 和流量长期归零；
- 每周备份引导卷，配置文件在 NAS 上另存一份；
- 换 IP 前把 DNS 的 TTL 改成 300 秒；
- 换 IP 后按清单逐项改 DNS、反代、监控、防火墙，别凭记忆；
- 别把所有服务都押在一台免费实例上，核心服务要有回群晖的退路；
- 免费实例是“随时可能收回”的资源，别在上面放不可替代的数据。
写在最后
甲骨文免费 VPS 的正确用法，是把它当成一台随时可能消失的机器来用：服务能重建、配置有备份、IP 换了有清单、丢了有备用。做到这几点，换 IP 只是一次十分钟的操作，丢实例也只是一次半小时的重建。最怕的是平时什么都不准备，出事那天才发现配置只存在那台机器里。
评论 (0)