3.3 测试上线：本地、临时域名到正式域名

备案没过，网站怎么调试

最难受的阶段是备案还在审核：服务器已经跑起来了，主题也装好了，但域名解析不能切到正式域名——大陆服务器对外提供网站服务必须先通过 ICP 备案，解析也得等备案通过之后才能切。这段空窗期少则一两周，朋友天天问“能不能先看看效果”。总不能让客户盯着空白页面等备案，但也不能违规先把解析指上去。

我用过两个办法，各有各的用途。

第一个是 hosts 本地绑定：在自己电脑的 hosts 文件里把域名指到服务器 IP，只有改了 hosts 的电脑能访问，零风险。原理很简单：hosts 文件是电脑里优先级最高的域名查询表，浏览器在问 DNS 之前会先看它。Windows 打开 C:\Windows\System32\drivers\etc\hosts，macOS 和 Linux 是 /etc/hosts，加一行：

# 前面是服务器公网 IP，后面是你的域名
123.45.67.89  www.example.com

Windows 改 hosts 要用管理员身份打开记事本，不然保存不了，这是新手最容易卡住的一步。改完在浏览器里敲域名，就直接看到服务器上的网站了，和正式上线没有任何区别。这个方法特别适合改主题、调样式这种反复刷新的活儿，因为hosts 生效是即时的，不用等任何缓存。缺点是只有自己能访问，给老板演示还得远程帮他改一次电脑——我朋友的老板为了看效果，专门学会了改 hosts，算是意外的技能成长。

第二个是临时域名。轻量应用服务器自带面板会分配一个临时访问地址，WordPress 装好后可以先用它调试，相当于一条带口令的后门。临时域名不用动正式解析，备案专员审什么、网站测什么，互不影响。但临时域名自己测试足够，千万别发给客户：既不正式，也不稳定，随时可能失效。

这两个办法怎么选：改主题调样式用 hosts（所见即正式域名），给同事演示验收用临时域名（不用动他们电脑）。

hosts 方案还有个升级玩法：让开发和验收在同一张网里完成。我把自己电脑的 hosts 改好后，把修改内容发给另外两个同事，他们照着改一遍，内测小组就算建成了。注意改完 hosts 出现过“明明改了却打不开”的情况，多半是浏览器有自己的 DNS 缓存（尤其chrome 之类），关掉重开或换个浏览器就好。

灰度切换：先小流量再全量

备案通知下来的那天，朋友恨不得立刻把解析切过去，把名片和宣传册一起印上。我按住他：第一次上线，别让所有人同时当一个没测过的站点的测试员。这背后有个朴素的道理：你自己测了无数遍的网站，和陌生人在各种手机、各种网络下打开的网站，是两个东西。

我的做法是分两步：

1. 先给 www 加一条 A 记录，TTL 设成 600，只告诉两个同事用手机打开看看，就说是内测。这几天盯着服务器访问日志，有报错马上改。这种小范围流量足以暴露大部分问题：手机端排版崩了、某个页面打开是 404、表单在 4G 下转圈——这些问题自己测的时候全没发现。
2. 观察两三天没大问题，再把 TTL 调回 3600，然后通知客户、把域名印到名片和资料上。

基调是：解析记录可以随时改，但客户的第一印象改不回来。灰度期间我发现留言表单在手机上点提交没反应，是表单插件的一个脚本在 HTTPS 没开的时候加载失败，正好趁这几天一起修了，修法见 3.4 节。

上线当天的操作我也排了个固定顺序，照着做不容易乱：

1. 先在解析控制台把 www 的 A 记录加上，TTL 填 600。
2. dig 一下确认返回新 IP，等 TTL 走完。
3. 自己用手机流量访问首页，点开每个页面。
4. 提交一条测试留言，确认通知邮件到了朋友手机。
5. 检查服务器错误日志，确认没有集中报错。
6. 把临时站点地址发给两个内测同事，让他们也走一遍前三步。

这套顺序的核心是：每一步都能立刻验证，不积累未确认的操作。出问题的时候你能准确说出是哪一步坏的，而不是“上线之后就不对劲”。那天我们整趟走完用了不到半小时，因为前面的准备都做在平时了：内容在备案期就填好，证书在灰度前就装好，上线那天只是走流程。

客观地说，灰度那两三天也不是纯等待，而是一种低成本的真人压力测试：两个人足以覆盖主流手机和主流网络，却帮你挡住了全量用户的审视。两个人测，总好过两百个人边看边骂，但是我们觉得值，这个道理朋友听完当场就同意了，并且立刻印了一盒新名片等着用，域名终于有了用武之地。等你一个人维护的网站哪天接了个大客户，突然来一波流量，你会感谢当初有这段缓冲期。分两步走的成本是两三天的耐心，收益是一整年的安稳，这笔账怎么算都划算。

整个灰度期我们一共干了这些事：修了手机端表单的脚本问题、把两张过大的首图压掉、补上了联系页缺失的地图、给案例页的图加了懒加载。这些活儿如果拖到全量上线之后，每一件都会变成一个客户现场目击的事故。灰度的意义就在这里：用最小的代价，把那些只有真人访问才暴露的问题在私底下解决掉。

上线检查清单

上线那天我把所有要确认的项写成一张表，逐项打勾。这份清单救过我两次：一次是表单其实在灰度期就坏了但我没单测，另一次是备案号填错了。人不靠谱，清单靠谱：

前两项是基础，中间两项是业务，最后两项是后路。备份这条尤其别省——上线第一天也是最容易误操作的一天。特别提醒：手机端那条一定要用流量测，公司 wifi 和家里 wifi 的 DNS 缓存经常给你假象，我第一次就是在办公室 wifi 下看一切正常，出门用流量一看首页是白的。

清单里没列、但提醒你注意的一件事：上线前一天千万别做大改。朋友的案例页在上线前一晚突然想换个排版，改完手机上错位，差点当晚没法上线。上线前的最后一次改动只限于文字纠错级别，结构级修改一律等上线稳定后再说。

临时域名在正式域名稳定后就可以撤掉了，我留了一周做对照，确认正式域名访问完全正常、没有任何人反馈打不开之后才删除。

还有一类情况要提前想好：备案审核期间管局可能会打回电话核实信息。朋友接审核电话那天下着雨在工地，信号断断续续，好在备案信息都是我按实际资料填的，问什么答什么。这里提醒一句：备案资料里的办公地址、负责人电话都要写真能联系上的，审核电话漏接一次就要多等好几天。朋友后来感慨，这通电话比他见过的任何客户电话都重要。

上线第一周盯什么

全量开放不等于万事大吉。上线第一周我每天花十分钟看三样东西：访问日志里的错误码、服务器的负载曲线、留言表单是否正常收到内容。访问量不大的时候这些用肉眼就看，不用上监控系统（监控告警是第四篇的事）。第一周结束，错误码归零、留言来了三条真实的问价，这个站才算真正活了下来。

朋友问能不能把网站地址发朋友圈了，我说再等等，等第一周结束。激进推广前先让系统自己在小流量下跑稳，这是小团队也能学的大厂习惯。

从测试到上线的完整路径

回过头看，整个上线路径其实很线性：hosts 绑定或临时域名做开发调试，备案通过，加 A 记录灰度验证，最后全量开放。每一步都有退路：hosts 删一行就恢复，临时域名关掉就失效，A 记录改掉就切走。怕的不是出问题，是出问题的时候没有退路。整套流程跑下来，从备案到全量上线我们只花了三天，比预想的顺。

再多说一句心态问题。朋友在备案等待的那两周很焦虑，总觉得网站“只差临门一脚”，反复问我能不能先把解析指上去凑合用。我的回答始终是：可以但不必。大陆服务器提供网站服务必须先备案，这是硬规矩，违规上线被查到整站关停损失的待客信任远大于等两个星期。等待期不是浪费时间——这段时间正好用来填内容、测表单、做 HTTPS 预演。等备案号下来的那天，你的网站其实已经准备得很充分了，上线才会快。

服务器基础不够熟的读者，建议先看 1Panel 面板运维 再回头做这节的操作；万一上线翻车，按 服务器常见问题 里的步骤排查。想看更大规模站点的平滑扩容思路，可以参考 腾讯云实战手记。

延伸阅读

• 服务器常见问题：上线翻车时的应急排查手册。
• AI 建站手记：想先快速搞一个演示站给老板看的方案。
• 腾讯云实战手记：站点流量起来之后的扩容路线。