1. 先想清楚免费云服务器到底值不值得用“免费云服务器”这四个字对刚入门的人来说像天上掉馅饼对踩过坑的人来说像一份需要逐条读小字的合同。我做过的几个小项目包括一个内部工具站、一个图像处理的小 Demo 接口、一个给朋友用的数据看板全部跑在免费或接近免费的云主机上前后换过四五家厂商的免费方案。整体感受是免费云服务器确实能省掉一笔固定支出但它的门槛不在钱上而在“你愿不愿意花时间把规则摸透”。摸透了它就是一台能跑一年的低成本实验机摸不透你会在某个深夜收到停机通知然后发现数据没备份。这篇内容想解决的就是这件事。它面向三类人手上只有一台笔记本、想找个公网环境练手的初学者想做个人小项目但不想一开始就投入几百块的技术爱好者以及需要给团队搭一个临时演示环境、用完即弃的从业者。我会把从选型、申请、初始化、部署到后期维护的整条链路拆开讲重点放在那些官方文档里一句话带过、实际动手却会卡住半天的地方。有一点必须先说在前面免费云服务器的本质是厂商的获客手段不是慈善。它的免费期、免费规格、免费流量都有明确定义超出的部分要么直接停服要么按量计费。所以你在动手之前脑子里要有一个清晰的问题清单——我要跑什么、需要多大配置、预计多少流量、能接受多久的免费周期、数据丢了能不能重建。这五个问题答不上来后面的操作基本都是白费。1.1 免费额度背后的四种商业模式市面上的免费云服务器按来源大致能分成四类每一类的限制逻辑完全不同搞混了就容易误判。第一类是新用户试用型。注册后给 7 天到 30 天的中高配实例配置往往很不错2 核 4G 甚至更高。它的目的是让你体验完整产品线所以限制点在于时间到期后要么续费要么释放。这类方案最适合做短期压测、临时演示、学习某个中间件的部署流程。第二类是学生与公益计划型。需要完成身份认证价格极低甚至免费周期通常按年算配置偏小但够用1 核 2G 或 2 核 2G 是常见规格。它的限制点在资格审核和续期规则认证材料、年龄范围、续期时间窗都得留意。这类方案是我最推荐新手入门的因为周期长容得下你慢慢折腾。第三类是永久免费层型。注意“永久免费”是带引号的通常只针对特定的小规格实例而且对带宽、流量、公网地址数量有严格上限有的还要求实例必须处于活跃状态否则回收。这类方案适合跑常驻的小服务比如一个个人博客、一个定时任务脚本、一个轻量 API。第四类是活动赠送型。以代金券、时长券的形式发放看起来最灵活实际上最容易踩坑因为券有适用范围、有使用顺序、有到期日同一张券可能只能抵扣特定计费项。把这四类放在一起对比选型的思路就清楚了。类型典型周期常见规格核心限制适合场景新用户试用7 到 30 天2 核 4G 起到期释放不可续压测、演示、学部署学生公益半年到一年1 核 2G 左右需认证续期有条件个人站点、练手项目永久免费层长期有条件1 核 1G 或更小流量、带宽、活跃度常驻小服务、定时任务活动赠送按券面不定适用范围与有效期临时扩容、短期迁移提示不要同时申请同一厂商的多个免费资格。多数平台对同一身份信息下的账号有数量限制超出后不仅新申请失败已有的实例也可能被标记异常。我见过有人用一个身份反复注册最后账号被整体限制连带之前跑得好好的实例一起遭殃。1.2 选型时真正该比的五个指标很多人选免费云服务器只看“几核几G”这是最容易吃亏的看法。CPU 和内存只是入场券真正决定你能不能用下去的是下面这五项。第一是出网带宽与流量包。一台 2 核 4G 但只有 1M 带宽的机器跑静态页面都嫌慢反过来 1 核 1G 配 5M 带宽做个轻量接口反而顺手。流量包要特别看清楚是“内网流量”还是“公网流量”是“当月清零”还是“可累积”是“仅限特定地域”还是“全域通用”。第二是公网地址的分配方式。这里有个非常隐蔽的坑部分免费实例的公网地址是动态分配的实例重启、关机再开机之后地址会变。对个人测试无所谓但如果你已经把域名解析指过去了地址一变站点直接不可访问。我在一个项目上就吃过这个亏半夜实例因为宿主机维护被重启第二天早上域名解析还指着旧地址排查了快一个小时才反应过来。第三是系统盘的类型与容量。免费实例常见 20G 到 40G 的高效云盘读写性能一般。如果你要跑数据库或者构建前端产物磁盘 IO 会成为瓶颈。另外要看清楚系统盘是否包含在免费额度内有些方案是“实例免费、磁盘单独计费”月底账单出来才发现。第四是快照与备份的可用性。免费方案里快照功能经常被限制次数或者干脆不提供。这一点决定了你的容错能力——没有快照误删文件就只能靠你自己提前打的压缩包。第五是计费项的边界。一定要在控制台的费用中心里逐条看公网流量怎么算、快照占不占空间、镜像是否额外收费、绑定弹性地址是否收费。有些平台实例本身免费但你绑了一个弹性公网地址这个地址按小时计费一个月下来比买台低配机器还贵。我自己的判断顺序是先看周期够不够长再看带宽和流量够不够用最后才看 CPU 内存。因为小项目最怕的不是跑得慢而是跑到一半没了。2. 申请环节那些卡住你的硬门槛申请这一步看起来最简单填个表点个按钮实际上它是整条链路上失败率最高的环节。失败原因很少是“服务器不够了”绝大多数是资质、支付方式、风控规则这三类问题。2.1 实名认证、支付绑定与账号权重实名认证是绕不过去的第一步。个人认证通常需要身份信息加人脸核验企业认证需要营业执照等材料。这里有个细节认证信息一旦提交后续修改非常麻烦有些平台甚至不支持修改只能注销重来。所以如果你打算长期用某个账号注册时就想清楚用个人还是企业身份。支付方式绑定是第二个门槛。不少平台的免费方案要求账号绑定有效的支付方式有的是为了验证身份真实性有的会在绑定时做一笔小额的预授权扣款再退回。这一步经常卡住没有双币支付工具的用户。我的建议是提前准备好别等到抢名额的最后一分钟才发现绑不上。账号权重这个词听起来玄实际影响很实在。新注册、无消费记录、无认证、登录环境异常的账号在申请免费资源时更容易被系统判定为高风险表现为申请按钮点了没反应、提示“名额已满”但实际上还有、申请通过后实例创建失败。降低这种概率的做法很朴素——用固定的网络环境和设备登录先把实名做完别用刚注册的账号立刻去抢稀缺资源隔一两天再操作。还有一个常被忽略的点同一身份信息在平台内的账号数量上限。多数平台限制一个身份只能认证一个主账号多开的账号无法完成认证也就无法申请免费资源。别在这上面浪费时间。2.2 申请流程的实操顺序与话术陷阱把流程拆成可执行的步骤大概是这个样子确认资格先读清楚免费方案的适用人群、地域限制、是否需要学生认证。这一步花十分钟能省掉后面半小时的无效操作。完成实名个人或企业认证预留人脸核验的时间。绑定支付方式按提示完成验证注意预授权金额通常会自动退回。进入活动或产品页找到对应的免费入口不要从搜索引擎的第三方链接进容易进到过期页面。选择地域与规格地域优先选离你近的规格按最小可用原则选后面可以升配但降配往往受限。选择镜像第一次用建议选干净的公共镜像别选预装了一堆东西的集成镜像。设置登录方式优先密钥对其次强密码。密码登录在公网上被爆破是常态。确认订单逐条核对计费项特别是“免费”标签旁边的灰色小字。等待创建创建失败先看配额再看地域库存最后看账号状态。这里要提醒几个“话术陷阱”。宣传页上写“免费使用一年”小字里可能是“首年免费次年按原价自动续费”如果你没关自动续费第二年就被扣款了。写“免费领取”可能要求你先完成一笔消费才有资格。写“不限流量”通常指不限次数但限总量。写“高性能”在免费档里基本等于“共享型实例CPU 有积分限制”跑满一段时间会被限速。注意创建实例时如果看到“按流量计费”和“按带宽计费”两个选项一定要选清楚。前者适合流量小但突发高的场景后者适合流量平稳的场景。免费方案里经常只支持其中一种选错了要么额度用不完要么几天就把流量跑光。3. 实例初始化把一台裸机变成能用的机器实例创建成功只是拿到了硬件系统层面的配置才决定这台机器好不好用。这一步我建议慢一点宁可多花二十分钟也别留一堆安全隐患。3.1 系统镜像与规格的取舍镜像选择上我的习惯是学习用途选主流 Linux 发行版的长期支持版本业务用途跟着团队技术栈走。为什么不选 Windows因为免费实例的内存通常很小图形界面本身就要吃掉一大块剩下能给应用的就不多了。命令行环境下 1G 内存能跑不少东西图形界面下可能开个浏览器就卡住了。规格选择上遵循最小可用原则。1 核 1G 能跑静态站点和轻量接口1 核 2G 能跑小型数据库加应用2 核 4G 才谈得上跑容器编排。免费档给的配置往往卡在 1 核 1G 到 1 核 2G 之间所以你要提前想好这个配置能不能撑住你的应用。一个简单的估算方法是本地用虚拟机压到同样配置跑一遍看内存占用峰值和启动时间。系统盘不要贪大。免费额度里的磁盘容量是有限的你把它全给系统盘后面想挂数据盘就没额度了。系统盘 20G 到 30G 对大多数场景够用日志和构建产物记得定期清理。地域选择上离用户近意味着延迟低但也可能意味着免费名额更紧张。如果只是自己用选个名额宽松的地域更实际。3.2 首次登录与基础加固的六步第一次登录进去别急着装软件。先把下面这几件事做完后面会省很多事。第一步创建普通用户并配置免密提权。直接用 root 操作是个坏习惯一旦命令敲错影响面太大。# 创建部署用户 adduser deploy # 加入提权组Debian/Ubuntu 系 usermod -aG sudo deploy # 把本机公钥写进去 mkdir -p /home/deploy/.ssh cp ~/.ssh/authorized_keys /home/deploy/.ssh/ chown -R deploy:deploy /home/deploy/.ssh chmod 700 /home/deploy/.ssh chmod 600 /home/deploy/.ssh/authorized_keys第二步关闭 root 密码登录。公网上的自动化扫描非常密集root 加弱密码基本等于开门迎客。# 先确认密钥登录可用再改配置 sed -i s/^#\?PermitRootLogin.*/PermitRootLogin no/ /etc/ssh/sshd_config sed -i s/^#\?PasswordAuthentication.*/PasswordAuthentication no/ /etc/ssh/sshd_config # 校验配置语法后重启 sshd -t systemctl restart sshd改完先开一个新终端验证能登录再关掉旧会话。这个顺序不能反反了就锁在门外了。第三步修改默认端口。这一步能过滤掉大部分无差别扫描属于低成本高收益的操作。改端口要同步改防火墙规则和安全组规则三处不一致就会连不上。第四步配置时区与时间同步。时间不准会导致证书校验失败、日志时间错乱、定时任务跑偏。timedatectl set-timezone Asia/Shanghai timedatectl set-ntp true timedatectl status第五步配置防火墙与安全组。这里有两层一层是云平台控制台的安全组一层是系统内的防火墙。常见错误是只在系统内开了端口忘了安全组或者只在安全组开了系统防火墙拦住了。我的做法是安全组只放行必要端口系统防火墙作为第二道保险规则保持一致。第六步加一点交换空间。小内存实例遇到突发内存占用容易被系统直接杀掉进程加一个 1G 到 2G 的交换文件能显著降低这种概率代价是磁盘读写变多。fallocate -l 2G /swapfile chmod 600 /swapfile mkswap /swapfile swapon /swapfile echo /swapfile none swap sw 0 0 /etc/fstab提示交换空间不是内存的替代品。它能防止进程被直接杀掉但一旦开始频繁换入换出性能会明显下降。看到交换使用率长期偏高说明该升配或者优化应用了。4. 运行环境搭建把应用真正跑起来环境搭建这一步不同技术栈差别很大但底层逻辑是一致的装依赖、配源、启动服务、做转发、设守护。我按这个顺序讲中间穿插一些实测有效的细节。4.1 依赖安装与软件源配置免费实例通常带宽不大装依赖最耗时的不是编译而是下载。国内环境下把软件源换成就近的镜像能省下大量时间。# Debian/Ubuntu 系先备份再替换 cp /etc/apt/sources.list /etc/apt/sources.list.bak sed -i s|http://archive.ubuntu.com|https://mirrors.example.org|g /etc/apt/sources.list apt update apt upgrade -y换源之后先跑一次apt update验证如果报签名错误多半是镜像站同步还没完成或者密钥没更新换回官方源重试即可。Python 项目要注意系统自带的 Python 版本可能偏低建议用版本管理工具装独立环境不要动系统 Python动了之后系统工具可能直接罢工。虚拟环境目录放在用户目录下不要放在/tmp临时目录重启会清空。Node 项目的内存占用要留意。构建阶段很容易吃掉 1G 以上内存1 核 1G 的实例跑构建大概率被杀。解决办法是在本地构建好产物再上传或者在实例上加交换空间并限制构建并发。Docker在小内存实例上要慎用。容器本身开销不大但镜像分层、日志文件、构建缓存会迅速吃掉磁盘。如果一定要用记得配置日志轮转{ log-driver: json-file, log-opts: { max-size: 10m, max-file: 3 } }这段配置写到/etc/docker/daemon.json后重启服务生效。不配这个某个容器日志写到几 G磁盘满了之后整台机器都会出问题。4.2 请求转发与进程守护应用跑起来之后通常不会直接对外暴露应用端口而是通过一个转发层统一处理 80 和 443。这样做的理由有三个方便统一配置 TLS、方便做静态资源缓存、方便在同一个实例上挂多个站点。server { listen 80; server_name demo.example.org; location /static/ { alias /var/www/demo/static/; expires 7d; } location / { proxy_pass http://127.0.0.1:8000; 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; } }配置里的几个头部字段别省。少了X-Forwarded-For应用拿到的客户端地址全是127.0.0.1日志分析就没意义了少了X-Forwarded-Proto应用生成的跳转链接可能变成 http浏览器会报警告。进程守护用 systemd 就够了不必额外装进程管理工具。一个典型的服务单元[Unit] Descriptiondemo-api Afternetwork.target [Service] Userdeploy WorkingDirectory/opt/demo ExecStart/opt/demo/venv/bin/python app.py Restartalways RestartSec5 EnvironmentENVproduction [Install] WantedBymulti-user.targetRestartalways配合RestartSec能让服务在异常退出后自动拉起这是免费实例上最实用的一条配置。免费实例偶尔会因为宿主机原因重启靠人工发现再手动拉起太被动。Nginx 自身也要设成开机自启systemctl enable nginx。我遇到过一次实例重启后应用起来了但转发层没起来站点直接 502查了半天才发现是忘了 enable。5. 额度监控与数据安全免费方案的生存底线免费方案最大的风险不是性能不够而是在你不知道的时候被停掉。额度超了、实例闲置了、地址变了、磁盘满了这些事不会提前打招呼只能靠监控兜底。5.1 用量监控与告警的最小实现监控不用搞得很复杂三个指标就够起步出网流量、磁盘使用率、服务存活状态。出网流量看平台控制台的用量看板每天扫一眼接近上限的 70% 就该收手了。有些平台提供用量查询接口写个定时脚本拉到本地记录能画出趋势线比人眼看更准。磁盘使用率用一条命令就能查df -h | awk NR1 || /\/$/服务存活状态最省事的做法是用一个外部探测定时请求健康检查接口连续失败就发通知。通知渠道用邮件或聊天工具的自建机器人即可不需要第三方付费服务。再进一步把下面这些也纳入检查清单内存使用率、交换分区使用率、TCP 连接数、系统负载。写成一个脚本每天汇总一次发给自己#!/bin/bash { echo 时间: $(date %F %T) echo 负载: $(cut -d -f1-3 /proc/loadavg) echo 内存:; free -h echo 磁盘:; df -h | grep -E ^/dev echo 监听端口:; ss -tlnp | head -20 } /var/log/daily-report.txt这份报告的价值在于形成基线。当你看到平时负载 0.1、某天突然 3.0不用等用户反馈就知道出事了。注意免费实例的“闲置回收”规则要看清楚。有的平台规定连续若干天 CPU 使用率低于某个阈值就判定为闲置直接释放实例。跑定时任务的机器尤其容易中招。规避办法很简单加一个每天执行一次的低开销任务让机器保持活跃。5.2 备份策略与迁移预案免费方案里数据安全完全靠自己。我的做法是三层应用代码放代码仓库配置文件单独存一份到对象存储数据库定期导出。代码自不必说改完就推。配置文件用打包脚本每天凌晨压一次传上去#!/bin/bash STAMP$(date %F) tar -czf /tmp/conf-${STAMP}.tar.gz /etc/nginx /opt/demo/.env /etc/systemd/system/demo-api.service # 上传到对象存储使用平台提供的命令行工具 storage-cli upload /tmp/conf-${STAMP}.tar.gz backup/conf-${STAMP}.tar.gz rm -f /tmp/conf-${STAMP}.tar.gz数据库导出要注意字符集和权限导出后立刻做一次完整性校验别等到需要恢复的时候才发现文件是空的。迁移预案这件事很多人觉得小题大做直到免费期结束那天才发现自己完全不知道该做什么。其实只要提前准备一份“重建清单”迁移就是半小时的事。清单内容包括系统版本、装的包列表、关键配置文件位置、服务启动顺序、数据恢复步骤、域名解析要改的记录。把这份清单写在仓库的 README 里换个环境照着做一遍基本不会出错。6. 常见问题与排查实录这一节是我这些年攒下来的问题清单按出现频率排序。有些问题看起来很低级但真到现场人在着急的时候就是会往错的方向想。6.1 高频故障速查表现象最可能的原因排查动作处理办法SSH 连不上安全组未放行新端口控制台看安全组规则补齐入方向规则SSH 连不上改配置后没重启或语法错sshd -t校验修正配置后重启站点 502应用没起来或端口不对ss -tlnp看监听修正启动命令与端口站点 502转发层服务未启动systemctl status启动并设开机自启实例重启后域名失效公网地址变了对比控制台地址改解析或换固定地址应用莫名被杀内存不足触发 OOMdmesg搜 oom加交换空间或优化内存磁盘写满日志或缓存未清理du -sh逐层定位清日志、配轮转定时任务没跑时区错或服务没启timedatectl、systemctl改时区、启服务HTTPS 报证书错误系统时间偏差过大date对比标准时间开启时间同步突然全部不可访问免费额度超限被停控制台看用量与状态联系客服或迁移6.2 几条花钱买来的经验第一条不要把免费实例当成唯一环境。我现在的做法是本地留一套能跑起来的完整环境免费实例只作为对外展示和联调。这样即使实例突然没了我十分钟内能在本地或者另一台机器上恢复不至于手忙脚乱。第二条域名解析用短 TTL。免费实例的公网地址可能变化解析记录的 TTL 设成 60 秒到 300 秒地址一变改完很快生效。设成几小时的话地址变了之后你要等很久才能恢复访问。第三条别在免费实例上跑不可重建的数据。这条听起来极端但很实际。免费方案的回收规则、额度规则、维护窗口都不由你控制。把数据当成随时可能丢失来设计你就不会犯“只在服务器上留一份”的错误。第四条记录每一次变更。我在一个文档里记着每次改配置的时间、改了什么、为什么改。这个习惯救过我很多次——某天服务出问题翻记录发现三天前改过一个参数问题瞬间定位。人脑记不住这些细节尤其是同时维护两三台机器的时候。第五条安全组规则宁可少开。只开真正需要的端口用完临时端口立刻关掉。调试期间开了一堆端口忘了关过几个月再看那些端口上不知道被扫了多少次。这件事没有捷径就是养成随手清理的习惯。第六条注意免费方案的“隐性配额”。除了流量和磁盘还有连接数、请求次数、快照数量、弹性地址数量这些配额。某些项目跑着跑着突然失败查半天发现是某个配额到顶了。控制台的配额页面要定期看一眼把它当成体检的一部分。