VPS 保活与避坑：甲骨文换 IP、丢实例怎么办 甲骨文免费 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 只是一次十分钟的操作，丢实例也只是一次半小时的重建。最怕的是平时什么都不准备，出事那天才发现配置只存在那台机器里。相关旧文甲骨文netboot重装系统遇见问题解决Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选Uptime Kuma 监控告警：NAS、VPS、摄像头在线状态一屏看清群晖 3-2-1 备份方案：Hyper Backup + 快照 + 异地备份一次配好

为什么放弃 FRP 选了 Lucky：一次工具选型心路 为什么放弃 FRP 选了 Lucky：一次工具选型心路家里这台群晖 NAS 跑了三四年，上面挂的东西越来越多：博客、相册、文件分享、下载器、监控面板，全都要从外网访问。内网穿透这件事，我最早用的是 FRP，后来换成了 Lucky。不是 FRP 不好，而是我的需求变了，工具没跟上。这篇不讲部署步骤，只讲一次真实的选型心路：当初为什么选 FRP、后来哪里不顺手、换 Lucky 之前我列了哪些需求、又是怎么验证的。如果你也在 FRP 和 Lucky 之间纠结，希望这篇能帮你少走点弯路。一、先说背景：我用 FRP 的那两年2024 年刚把博客和几个服务搬上 NAS 时，我用的是 FRP。老牌开源方案，文档全、教程多，群晖上用 Docker 跑一个 frpc 客户端，配好 frpc.ini，指向一台有公网 IP 的 VPS，几分钟就能把服务穿出去。那两年 FRP 跑得很稳，博客、相册、文件分享都走它，VPS 上一个 frps 服务端带五六个隧道，没出过什么大问题。说实话，如果需求一直停在“穿出去就行”，FRP 完全够用，我也不会换。转折点出现在服务越挂越多之后。每次加一个新服务，都要改 frpc.ini 加一段配置、重启容器、去 VPS 上确认端口。改一次两分钟，不麻烦，但改十次就烦了。更关键的是，有一次我手滑把配置文件里一个端口写错，重启后博客和相册一起断了，排查了半小时才发现是自己改错了行。那一刻我意识到：问题不是 FRP 不稳定，而是我的使用方式已经超出了“改配置文件”这种模式的舒适区。我需要一个能看得见、改得快、出错能立刻发现的管理方式，而不是每次靠文本编辑器和重启碰运气。二、换之前，先把需求写下来选型最忌讳凭感觉。换之前，我先把自己的真实需求列了一张表：多服务、多域名：NAS 上七八个服务，每个都要独立域名和 HTTPS，不能共用一个端口硬凑。改配置要快：加一个服务、改一个端口，最好在网页上点几下就完成，不用 SSH 进容器改文件、重启。证书要自动：HTTPS 证书到期要自动续，不能靠我每三个月想起来手动续一次。能看到状态：哪个隧道通、哪个断了、流量走了多少，最好一眼看得到，出问题不用先猜。维护成本低：家里这台 NAS 是 7×24 小时跑的，我不想每周都花时间伺候穿透工具，越省心越好。留退路：新工具如果水土不服，要能在一小时内切回 FRP，不能把全家服务押在一个没验证过的方案上。列完这张表我才发现，FRP 能满足前两条的一半：它能穿多服务、也能配 HTTPS，但“改配置要快”“能看到状态”“证书自动”这三条，它天生就不擅长。FRP 的设计哲学就是“配置文件即全部”，稳定、透明、可脚本化，代价就是一切都要手改文件、重启生效。这不是 FRP 的缺点，是它的定位。只是我的需求变了。三、为什么是 Lucky，不是别的当时摆在我面前的选择有三个：继续用 FRP、换 Lucky，或者试试 ECH（Cloudflare 隧道那套）。三者我之前都实测过，结论写在《Lucky / FRP / ECH 三种内网穿透实测对比》里：延迟上 FRP 和 Lucky 差不多，ECH 免费但节点和稳定性要看运气。这次选型我换了一个判断标准：不再只比延迟和成本，而是按上面那张需求表逐项打分。改配置：Lucky 带 Web 界面，端口转发、反向代理、域名绑定都在网页上点几下完成，改完即时生效，不用重启容器，直接命中我最痛的地方。证书：Lucky 内置 ACME 自动申请和续期，域名解析过去之后，证书自己申请、自己续期。我之前为证书单独写过同步脚本，换了 Lucky 之后那套脚本直接退役了。状态可见：Lucky 的管理界面能看到每条转发规则的状态，断了就是断了，不用先 SSH 再查日志。反代能力：Lucky 本身就是一个反向代理，多域名、多服务、路径分流都能在一个地方配齐，NAS 上的服务统一从它进出，架构反而比“FRP 穿透 + 另外一个反代”更简单。成本：Lucky 和 FRP 一样开源免费，部署同样是 Docker 一个容器，迁移成本就是把规则从配置文件抄到网页上，一个晚上能做完。ECH 我认真考虑过，但它依赖 Cloudflare 的网络，对我这种要稳定访问家里摄像头和 NAS 管理界面的场景来说，多一层不确定因素。免费是真免费，不可控也是真不可控。我的结论是：ECH 适合做备用通道，不适合当主力。所以最后的决定是：主力切到 Lucky，FRP 的服务端和客户端配置原样保留一个月，当作回滚预案。四、切换过程：一个晚上，平滑完成切换我分了三步走，没敢一次性全切：第一步：先搭 Lucky，不动 FRP。 在群晖 Container Manager 里新建一个 Lucky 容器，先把一个不重要的服务（下载器的 Web 界面）切过去跑两天，验证反代、HTTPS、证书续期都没问题。第二步：逐个服务迁移。 按“先边缘、后核心”的顺序迁移：先是文件分享、监控面板这类影响小的，最后才是博客和相册。每个服务切过去后，立刻从外网打开验证一遍，确认没问题再迁下一个。整个过程里 FRP 一直在跑，任何一个服务出问题，改回域名解析就能立刻恢复。第三步：观察两周，再拆 FRP。 全部服务切完后，我没有马上删 FRP，而是让它空跑了两周。这两周里 Lucky 经历了两次 NAS 重启、一次宽带断线重拨，都自动恢复了，证书也正常续了一次。确认稳定后，才把 FRP 的容器停掉，配置文件备份存档。整个切换没有一次全家断网，最长的一次单服务中断是博客切域名解析的几分钟，还是我自己手快改错了记录，改回来就好了。五、用了半年之后，诚实地说说 Lucky 的短板选了 Lucky 不代表它完美。用了半年，短板也得如实写出来：界面是强大，但也是负担：Lucky 的功能非常多，第一次打开管理界面，菜单密密麻麻，新手容易不知道从哪下手。FRP 的配置文件虽然原始，但至少一眼能看全。出了问题，排查要进界面：FRP 出问题看日志文件就行，Lucky 出问题要先打开管理界面，再找对应的规则和日志。对习惯命令行的老手来说，这一步反而多绕了一圈。版本更新要自己盯：Lucky 更新不算频繁，但也没有 FRP 那种“几年不动也稳”的气质。大版本升级前，最好先看一眼更新说明，别无脑点更新。这三条没有一条是致命的，但如果你是那种“配好一次、五年不碰”的用户，FRP 反而更合适。工具没有高下，只有适不适合当下的你。六、我的结论：选型看需求，不看名气这次选型最大的收获不是“Lucky 比 FRP 好”，而是想明白了一件事：工具的优劣是相对的，锚点是你自己的需求清单。如果你只有一两个服务要穿透，配置改得少，FRP 依然是最稳、最省心的选择。如果你的服务越来越多，改配置越来越频繁，又想要证书自动续、状态一眼可见，那 Lucky 值得换。如果你追求零成本、不在乎多一层不确定性，ECH 可以当备用通道，但别当唯一主力。顺便提醒一句：站内 2024 年写的 FRP 客户端部署旧文（用 Docker 跑 frpc、接免费 FRP 服务那套）现在看流程还能跑通，但思路已经过时了——免费 FRP 服务的稳定性、端口限制和现在的需求对不上号，如果你是新上手，建议直接按本文的思路先列需求、再选工具，不要照着旧文一步步抄。选工具和选人一样，没有完美的，只有合适的。FRP 陪我跑了两年，功劳簿上有它一笔；Lucky 接过下一棒，是因为下一程的路变了。下一程路再变的时候，我还会再列一次需求表。相关旧文Lucky / FRP / ECH 三种内网穿透实测对比：延迟、成本、稳定性怎么选：https://www.yeyhome.com/2026/10/14/268.htmllucky证书更新群晖自动同步：https://www.yeyhome.com/2026/10/25/296.htmlLucky 反代宝塔面板 — Docker macvlan + bridge 双网络解决方案：https://www.yeyhome.com/2026/02/26/68.html群晖 DSM 7.2 Container Manager 迁移避坑：从旧 Docker 平滑搬家：https://www.yeyhome.com/2026/11/05/304.html

免费的内网穿透服务-星河frp内网穿透 内网穿透利用frp程序实现无公网访问内网资源内网穿透，也即 NAT 穿透，进行 NAT 穿透是为了使具有某一个特定源 IP 地址和源端口号的数据包不被 NAT 设备屏蔽而正确路由到内网主机。本次推荐的是星河提供的免费服务，利用frp 客户端实现资源的访问。星河内网穿透介绍官网地址：http://galaxyfrp.xhuzim.top/星河内网穿透提供免费的线路，通过实名认证后可以选择自己适合的线路来建立虚拟隧道。流量可以通过每日签到获得。使用步骤1、登录网站并注册为会员，进行实名认证。2、创建隧道，选择自己合适的节点，填写相关信息。隧道名称：自定义即可隧道类型：http、https、tcp等本地地址：默认即可本地端口：即为局域网内需要穿透的端口远程端口：默认绑定域名：通过浏览器输入访问的域名，这个域名需要解析到下面配置文件中的A地址。（顶级域名或者二级域名都可以，不需要填写http或者https）高级设置：直接默认3、点击创建即可完成隧道的建立。查看配置文件，写入frpc文件即可使用{message type="info" content="这里的服务器选择与建立隧道时候的服务器一致"/}