1. 免费服务器这件事先把账算明白再动手聊服务器免费这个话题我见过太多人第一反应是去找一个永久免费的机器结果折腾两周要么被限额卡死要么到期扣了一笔说不清的钱。免费服务器的本质不是零成本而是成本被转移到了别的地方——时间、稳定性、流量额度或者数据迁移的麻烦上。我长期在自己项目和团队的小工具上使用各种免费形态从云厂商的体验额度到家里旧笔记本自建踩过的坑比用过的方案还多这篇就把五种主流形态一条条拆开顺带讲清楚从免费额度到自建内网穿透这条路上哪些地方最容易翻车。先给个结论性质的前提免费方案能不能用取决于你的服务是有人随时访问还是我偶尔用一下。前者需要稳定性和可用性承诺免费资源基本给不了后者完全可以靠免费额度、Serverless 甚至家里的旧设备撑住。这个判断做错了后面所有的选型都是白费力气。标题里内网穿透这四个字值得单独说一句它指的是把处于内网环境的设备家里的 NAS、开发机、办公室的小主机通过一条隧道暴露到公网访问是很常规的网络工程做法。本文讨论的自建方案前提都是只访问你自己有管理权限的设备和数据并且遵守所在网络环境与服务提供商的使用规则这一点在动手前就要摆正。1.1 免费的三种成本结构先分清你付的是哪种我习惯把免费方案按成本转移方式分成三类。第一类是额度型免费厂商给你一定量的资源几个月的实例、每月若干次函数调用、若干 GB 流量超额或到期就按量计费。这类方案的风险点在于到期和超出钱是从你没想到的缝隙里流走的比如快照存储、公网出流量、日志留存。第二类是限制型免费资源不要钱但限制死规格比如容器闲置后休眠、函数单次执行最长若干秒、静态站点单文件大小上限。这类方案不烧钱烧的是你的耐心和架构设计的自由度。第三类是资源置换型免费你用自己的硬件、电费、宽带上行带宽去换一台服务器典型就是自建加内网穿透。它看起来零现金支出实际上电费、硬件折旧、运维时间都是成本而且家宽的上行带宽往往只有下行的十分之一这是很多人做完才发现最难受的地方。把这三类对上自己的需求选型基本就清晰了对外提供的展示类页面走第二类内部工具、定时任务走第一类需要长期跑、数据量大、访问者只有自己或小团队的服务走第三类。下面五种形态就是按这个逻辑展开的。1.2 一个反向的判断先想迁移再想免费我在早期犯过一个很典型的错误贪图某个平台的免费额度把数据库和应用都堆在上面连备份都没做到期那天才发现导出数据要额外开一台机器重新部署花了一整个周末。从那以后我形成了一个习惯——任何免费方案在启用前先写好退出路径。退出路径要回答四个问题数据存在哪、怎么导出、导出后能不能在别处跑起来、切换需要多久。如果这四个问题有一个答不上来这个免费方案就不该承载你的核心数据。具体做法很朴素应用尽量容器化配置全部写成文件放进版本管理数据不要放在实例本地盘定期导出一份到对象存储或者自己的机器上。免费额度那种几个月的方案我在到期前两周就开始做迁移演练DNS 记录的 TTL 提前调到 60 秒切换当天基本能做到无感。这些动作看着琐碎但真出事的时候能救命。2. 形态一云厂商的免费额度与新用户体验资源这是大多数人最先接触到的形态。主流云平台会给新账号一段时间的体验资源通常是轻量规格的实例加一定量的流量或者提供长期存在的免费层固定小规格实例、若干 GB 对象存储、有限的 CDN 流量。它最大的优点是开箱即用、生态完整有控制台、有镜像、有安全组、有监控装个环境跑个 Demo 十几分钟的事。它的边界也非常明确。规格低免费实例一般是 1 核 1G 或者 2 核 2G 起步跑个 Nginx 加轻量后端没问题跑数据库加中间件就吃力了。时长久体验资源多是 3 个月到 1 年永久免费层通常只针对极小规格和特定地域。流量不含或者很少这是最容易忽略的一点很多方案给了机器却不给带宽公网出流量单独计价一个小博客被爬虫刷一轮账单就不好看了。2.1 免费额度里最容易被忽略的四项计费点我把这些年被扣过钱的地方列成表你对着自己的控制台逐项确认一遍能省掉不少意外支出。计费项典型触发场景应对做法公网出流量静态资源被外链、爬虫抓取、视频直出图片走对象存储加 CDN接口加限流磁盘快照手动或自动备份累积从不清理设置保留策略定期删旧快照公网 IP 与带宽实例释放后 IP 未解绑仍占资源释放实例时同步释放弹性 IP日志与监控存储默认全量采集且长期保留缩短保留天数只留错误级别还有一个隐形项是自动续费。绑定支付方式之后很多平台在你开通时默认勾选自动续费体验期一过直接按原价扣。我的做法是开通当天就去账单页面把自动续费关掉同时设一个预算告警阈值设在免费额度的一点二倍左右一旦超出立刻能收到通知。2.2 到期前两周该做的迁移动作清单免费额度型方案最怕的不是不够用而是到期那天下不来台。我给自己定的流程是这样到期前 14 天把实例上跑的东西全部梳理一遍标记出哪些是必须在哪些是顺手装的。然后在新环境把必须在的部分重新部署一遍这个过程会暴露出所有硬编码的路径、写死的 IP、藏在本地文件里的配置。到期前 7 天把数据同步一次验证新环境能正常读写。到期前 1 天把 DNS 或者域名解析切过去观察一轮错误日志。注意迁移演练一定要真的切一次流量哪怕只有十分钟。只在本地跑通不算验证DNS 缓存、证书链、防火墙规则这些只有在真实流量下才会暴露问题。这套流程配合容器化用起来最省心应用打成镜像配置走环境变量数据放外部存储新环境拉起来就能跑。反过来如果你在免费实例上手敲了三个月的环境迁移就是一场灾难这也是我建议哪怕只是玩票也把部署过程脚本化的原因。3. 形态二Serverless 与函数计算的免费调用额度函数计算这类产品的免费额度通常按调用次数、执行时长GB·秒和出网流量计算每月给一个相当宽裕的基础量。对低频、突发、事件驱动的负载来说这是性价比最高的形态——一个每天被调用几百次的 Webhook 接收端或者一个每小时跑一次的定时任务放在函数上几乎是零成本还省掉了打补丁、盯监控的功夫。它的适用边界需要说清楚。常驻长连接不适合WebSocket、长轮询这类场景在函数上很难做即使勉强做成本模型也会崩。重计算不适合单次执行有超时上限大文件转码、大数据量批处理容易被腰斩。需要本地磁盘的不适合函数实例的临时目录不保证持久写进去的东西下次调用就没了。需要固定出口 IP 的不适合出网地址通常是共享池对接一些有白名单要求的第三方服务会卡住。3.1 冷启动、并发与超时三个必须提前验证的指标冷启动是函数计算绕不开的体验问题。闲置一段时间后第一次调用平台要重新拉起运行环境延迟可能从几毫秒变成几百毫秒甚至一两秒。我的处理方式是对延迟敏感的接口做轻量预热把依赖包压到最小只装真正用到的库别把整个数据处理框架拖进去初始化逻辑放在函数入口外做复用。并发限制也很关键。免费额度的并发上限通常不高一旦有突发流量超出部分会被限流或者排队。这时候要做的不是加大额度而是在入口处限流并给出明确的降级响应让调用方知道发生了什么而不是拖到超时。超时上限决定了你的业务能不能落在这上面。做批量任务时我会把工作拆成小片每片控制在超时上限的三分之一以内用队列串起来而不是在一个函数里跑几十分钟。这样做还有一个好处失败重试的粒度更细不会因为一片出错整批重来。3.2 出网流量与日志账单从这两个口子漏函数计算的调用次数通常不是问题出网流量和日志存储才是。返回给客户端的大响应、调用外部 API 的流量都算在出网里。我见过一个接口返回了几 MB 的 JSON调用量一大流量费就上去了。解决办法很直接接口做分页、压缩响应、大文件走对象存储加签名链接。日志方面默认配置往往是全量采集并长期保留调用量上来之后这块的存储成本会悄悄超过计算本身。我一般会把日志级别调到只保留 warn 和 error保留期设成 7 天需要排查问题时再临时打开 debug。这个习惯在小项目上体现不出价值项目一上量就很明显。4. 形态三静态托管与边缘分发的免费层如果你的服务器其实只需要对外提供一堆静态文件——文档站、产品介绍页、前端打包产物、图片库——那么静态托管加边缘分发是成本最低、稳定性最好的选择很多平台提供相当慷慨的免费层甚至对个人项目完全免费。这个形态最大的优势是没有运维不用装系统、不用配 Web 服务器、不用担心被打挂边缘节点天然抗压。前端项目我把构建产物往上一扔绑定域名就能访问HTTPS 证书自动管理这块省下来的时间可以全投到内容上。免费层的限制主要在构建次数、构建时长、单文件大小和流量上个人站点基本够用。4.1 单页应用上线后刷新 404问题出在重写规则这个问题几乎每个用静态托管部署单页应用的人都会遇到一次。前端路由是浏览器端处理的用户直接访问/docs/getting-started时托管平台会去文件系统里找这个路径找不到就返回 404。解决方式是配置一条回退规则把未匹配的请求统一指向入口文件。以常见平台的重写配置示意为例不同平台字段名有差异按你用的平台文档改{ rewrites: [ { source: /(.*), destination: /index.html } ] }配完之后还要注意缓存。入口文件不能长缓存否则用户拿到旧版本会一直加载不存在的资源。我一般把入口设成no-cache带哈希的静态资源设成一年这样更新能立刻生效静态资源又能充分利用缓存。# 缓存策略示意 location /index.html { add_header Cache-Control no-cache; } location ~* \.(js|css|woff2|png|jpg|svg)$ { add_header Cache-Control public, max-age31536000, immutable; }4.2 构建超时与大文件仓库里不该放什么免费层的构建时长通常有限制依赖装得太多、仓库里堆了大文件构建就容易超时。我踩过一次坑把一个几百 MB 的素材目录直接提交进了仓库每次构建都在拉这些东西构建时间从两分钟涨到八分钟最后撞上限额失败。后来的做法是把素材放对象存储仓库里只留压缩后的必要资源并用.gitignore把构建产物和本地缓存挡掉。还有一个细节是构建缓存。大多数平台支持依赖缓存把锁文件package-lock.json、poetry.lock之类提交进去、不要随意删能显著缩短构建时间。我在项目里把这一步写进了提交前检查避免有人图省事把锁文件删了重新生成导致构建变慢还引入版本漂移。5. 形态四免费容器托管与轻量应用平台容器托管是介于完整云主机和函数计算之间的形态你把应用打成镜像推上去平台负责运行和扩缩容免费层通常给有限的实例数、内存和月度运行时长。它的好处是部署体验统一——本地跑得起来的镜像线上基本也能跑不会出现我电脑上没问题的经典困境。这个形态最关键的一个特性是休眠机制。为了控制资源占用平台会在应用闲置一段时间后把实例停掉下一次请求触发冷启动用户看到的是几秒甚至十几秒的等待。对于个人工具、内部后台这类我自己用的场景完全可以接受对于对外展示的门面页面就要谨慎。我见过有人为了对抗休眠写定时请求去保活这个做法要先看清楚平台的服务条款很多平台明确不鼓励这类行为被判定为滥用后账号受限得不偿失。更稳妥的思路是接受休眠把首屏做成静态页把重逻辑放到唤醒之后。5.1 容器文件系统是临时的数据库必须外置这是新手最容易踩的一脚应用写了个 SQLite 文件放在容器目录里跑了几天发现数据莫名其妙回滚了。原因是容器的文件系统在实例重启、重新调度之后会被重置本地写入的东西不保证留存。正确做法是把状态全部外置数据库用托管服务或者自建在别处文件上传走对象存储会话用外部缓存或者干脆做成无状态加签名令牌。如果实在要用 SQLite那就要挂载持久卷并且确认平台提供了这个能力以及对应的容量限制。数据类型放在容器内正确做法用户上传文件重启后丢失对象存储加签名 URL数据库文件调度后重置托管数据库或外部实例会话状态多实例不一致外部缓存或签名令牌日志随实例销毁输出到标准输出由平台采集5.2 月度运行时长与实例规格的换算免费容器的额度通常按实例数 × 运行小时计算。假设免费层给的是每月 750 实例小时跑一个实例可以全天候在线跑两个实例就只剩半个月。多副本部署之前先算这笔账否则月中就被限流。内存配额也要留意。免费层一般给 256MB 到 512MBJava 那类默认堆内存偏大的运行时容易直接 OOM。我的经验是把堆内存上限显式设成容器限制的 70% 左右留出元空间和系统开销能用轻量运行时就不用重量级的一个简单的 API 服务用 Go 或者 Node 写出来镜像能压到几十 MB启动也快。6. 形态五自建加内网穿透把家里的机器变成服务器前面四种都是租别人的资源最后一种是拿自己的硬件换一台服务器。数据完全在自己手里、磁盘想多大就多大、想装什么装什么代价是要自己解决外面的网络怎么访问进来这个问题——绝大多数家庭宽带没有固定的公网地址即使有直接暴露端口也不安全。内网穿透就是在这个背景下出现的在公网找个有固定地址的中继节点内网设备主动连出去建立一条隧道外部访问中继节点时流量被转发回内网设备。整体架构其实很简单三部分内网服务家里的 NAS、开发机、树莓派上的应用、隧道客户端跑在内网设备上主动向外建立连接、中继节点有公网地址的机器负责接收外部请求并转发。有些方案还支持点对点打洞即两端尝试直连直连成功就不走中继延迟和带宽都好得多失败时再回落到中继。6.1 打洞与中继的取舍先看你的场景能不能直连直连成功的条件是双方的网络环境允许NAT 类型友好、没有严格的对称型限制。打洞成功时流量不经过中继带宽只受两端上行带宽限制延迟也低。但打洞不是百分百成功尤其是移动网络、多层 NAT 环境失败率不低。中继模式则稳定得多只要客户端能连上中继节点就能通但代价有两个流量绕路带来延迟以及中继节点的带宽和流量成本。如果中继节点本身也是免费额度那就要格外小心流量上限一个视频流或者大量文件同步很容易把它打满。我的实际选择是这样文件同步、远程桌面这类对带宽敏感的场景优先尝试直连设备管理页面、API 调用这类低频小流量的走中继完全够用。配置上通常可以同时启用两种模式让工具自己协商协商失败再强制走中继。6.2 中继端的配置与加固别让隧道变成后门自建中继最怕的一件事是隧道建好了安全没做全网扫描器几天就找上门。我见过有人把内网的管理后台直接映射到公网密码还是默认的结果被批量扫描的脚本拿下。下面这套配置和加固动作是我目前的标准做法。# 中继端示意配置字段名以你实际选用的工具为准 bind_addr 0.0.0.0 bind_port 7000 auth_token 换成32位以上的随机串 max_ports_per_client 5 log_level infoauth_token一定要换成长随机串所有客户端共用同一个 token别用默认值。max_ports_per_client限制单客户端能映射的端口数防止误配把一堆服务全暴露出去。客户端配置示意# 内网端示意配置 server_addr relay.example.net server_port 7000 auth_token 与中继端保持一致 [[proxies]] name nas-web type tcp local_ip 127.0.0.1 local_port 5000 remote_port 15000关键点在于local_ip写127.0.0.1而不是0.0.0.0让它只转发本机上的那个服务避免把内网其他设备的端口也带出去。中继机上的防火墙只放行必要端口uvicorn_placeholder1 ufw default deny incoming ufw allow 22/tcp ufw allow 7000/tcp ufw allow 443/tcp ufw enable ufw status verbose客户端用 systemd 托管保证断线自动重连[Unit] Descriptiontunnel client Afternetwork-online.target [Service] ExecStart/usr/local/bin/tunnel -c /etc/tunnel/client.ini Restartalways RestartSec5 [Install] WantedBymulti-user.target6.3 证书、域名与反向代理把隧道藏在 443 后面直接映射端口能用但体验不好地址带端口号、没有 HTTPS、各种客户端提示不安全。我的做法是在中继机上用 Nginx 做反向代理把隧道映射出来的本地端口包一层统一走 443证书用自动签发工具管理。server { listen 443 ssl; server_name nas.example.net; ssl_certificate /etc/letsencrypt/live/nas.example.net/fullchain.pem; ssl_certificate_key /etc/letsencrypt/live/nas.example.net/privkey.pem; client_max_body_size 200m; location / { proxy_pass http://127.0.0.1:15000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; } }证书签发时有个细节如果中继机的 80 端口不方便对外开放用 DNS 方式验证比 HTTP 方式更省事尤其是给纯内网设备签证书的场景。另外把client_max_body_size显式设一下默认 1MB 在传文件时会直接给你 413我在这上面浪费过半小时。注意对外提供网站服务涉及域名与接入的相关手续各地要求不同本文不展开请按你所在地的规定自行确认后再上线。6.4 实测中最常遇到的四个问题上行带宽是硬伤。家庭宽带的下行看着很爽上行往往只有几十兆甚至更低。远程看个视频、传个大文件瓶颈全在上行这个没法靠配置优化解决只能降低预期或者换方案。地址会变。家庭宽带的公网地址可能定期变化如果你用的是直连而不是中继需要配合动态域名解析客户端定时上报当前地址。中继模式不受影响因为连接是内网主动发起的。中继流量烧得快。中继节点的流量成本要盯着看尤其是拿免费额度做中继的时候。我一般会在中继上做限速并且把大流量服务单独拆出去走直连。重连风暴。网络抖动时客户端可能疯狂重连日志刷屏还占资源。RestartSec设个几秒、工具本身开启指数退避能缓解不少。6.5 内网设备本身的安全底线隧道只是通道设备本身的安全才是根。我这几年固定做几件事禁用密码登录改用密钥、关掉不需要的服务、管理后台加一层基础认证、开启失败登录封禁。管理后台的默认密码是重灾区很多设备出厂密码全网皆知映射出去等于公开。还有一条容易被忽略审计。定期看一眼中继和设备的访问日志有没有陌生的 IP 在扫端口、有没有异常时间的登录尝试。这一步花不了几分钟但能提前发现很多问题。7. 五种形态横向对比按场景选不要按免费选写到这五种形态的脾气基本都摸清了。我做了一张对照表选型时直接对号入座比反复纠结有用得多。形态现金成本稳定性运维负担最适合的场景主要上限云厂商免费额度额度内为零较高中等需要完整环境的学习与小型后端时长、规格、流量Serverless 函数额度内为零高低低频接口、定时任务、事件处理执行时长、并发、冷启动静态托管加边缘基本为零很高极低文档站、前端产物、图片库构建次数、单文件大小免费容器托管额度内为零中等低个人工具、内部后台、Demo休眠、运行时长、内存自建加内网穿透电费与硬件取决于自己高数据自主、大容量存储、长期运行上行带宽、地址变动选型时我的判断顺序是先问访问频率再问数据敏感度最后问预算。访问频率低的走函数纯静态的走托管需要长期在线且数据要自己拿着的走自建中间地带用免费容器兜底实在需要一个完整环境就用云厂商额度过渡。8. 踩坑清单免费方案翻车的完整排查链路这一节讲的是真出事时怎么查。我把最近一次莫名扣费的排查过程完整还原一遍思路可以直接套用。8.1 从账单异常到定位根因的六步链路第一步进账单页面按资源类型分组不要按时间看总额按类型才能看出是哪一类在涨。我那次发现扣费集中在网络流量和存储两项计算资源反而是零。第二步把流量按时间段展开找到突增的时间点。那次是凌晨三点开始持续上涨这个时间点很说明问题——不是真实用户在访问。第三步翻访问日志。日志里能看到大量来自同一批地址的请求抓的是同一个图片路径明显是被批量抓取了。第四步确认是否配置了缓存和限流。检查后发现图片直接由实例出网没走 CDN也没有任何限流。第五步确认存储费用的来源。是快照——之前手动打的一次快照忘了删一直按容量计费。第六步处置并加固图片迁到对象存储加 CDN实例侧加请求限流删掉无用快照设置预算告警和自动续费关闭。整个过程花了不到一小时但如果一开始就按这个顺序查能省掉大量瞎猜。排查的核心是把一笔总额拆成资源类型 → 时间段 → 请求来源 → 配置缺失四层一层层往下钻。8.2 限速、限流、休眠三个不写在显眼位置的隐形坑免费方案的限制往往不体现在报错上而是体现在能用但很难受。限速表现为带宽被压到很低下载文件像蜗牛测速才发现被限制了。限流表现为偶发的 429 或者超时压力小的时候完全看不出来一上量就爆。休眠表现为第一次访问特别慢之后就正常很容易被误判成代码性能问题。识别方法遇到偶发但规律的异常先怀疑平台限制而不是自己的代码。我在项目里会做一个小脚本定时打点记录响应时间连续跑几天看看延迟分布的形态——如果存在明显的双峰快的一批、慢的一批基本就是冷启动或者限流在作怪。8.3 暴露面管理免费资源被扫描是常态公网上的任何地址只要开放了端口几小时内就会开始收到扫描请求这跟你的服务大小无关。免费方案尤其要注意因为很多默认配置是能用就行安全设置基本靠用户自己。我的固定动作有这么几条管理类端口一律不直接对外走隧道加认证SSH 禁用密码登录只留密钥数据库、缓存这类服务绝不放公网对失败登录做封禁定期看看有没有多余的服务在监听。# 快速看一眼当前对外监听的端口 ss -tulnp | grep -v 127.0.0.1 # 检查失败登录尝试 lastb | head -20这两条命令我一般在新机器上线当天就跑一遍确认没有意外暴露的服务。ss那条会把只监听本机的行过滤掉剩下的都是对外的逐个确认用途说不清楚的一律关掉。9. 一点个人体会这五种形态我全都用过而且经常是混着用门面页面放静态托管定时任务丢函数开发机上跑的调试服务和家里的存储走自建隧道需要一个完整环境做压力测试的时候临时开一台免费实例测完就释放。这套组合下来的现金支出几乎为零代价是我得记住每个方案的额度和到期时间还得接受偶尔会慢一下。如果只让我给一条建议那就是别把免费当成长期方案把它当成过渡和验证。真正决定你要不要迁移的不是钱而是某个凌晨服务挂掉时你有没有能力在两小时内恢复。免费方案里能做到这一点的通常只有你已经把部署脚本化、数据外部化、退出路径写好的那些。剩下的玩得开心就好别放重要东西。