写在成功备案后
决定做一个网站之后，事情好像并没有立刻变得多么复杂。
好像只是先改改模板里的参数，然后再写一点文章而已。
那时的目标很简单：先让它看起来像一个“属于我”的网站。自己觉得舒服一点，就已经很开心了。
那时候的它还只是存在于我的电脑里。
没有域名，没有服务器，也没有谁能够在互联网上访问它。
先给它一个名字
页面做好之后，我开始考虑域名。
这一步比我想象中有意思。
比起页面上的 title，我感觉它才更像网站的名字。
我会在意它好不好记，会不会太长，和网站本身搭不搭。
我开始思考我的网站现在是什么样子，以后又会拿来做什么。
思来想去，便有了你在地址栏看到的那个名字。
如你所见，我在后面加了一个“club”。
一个社团里面有着各种各样的分工，承担着各种各样的任务。这个域名或许也是这样，我也会分给它很多任务，拿来做更多有意思的事情！
虽然这时候网站依然没有真正上线，但它从一个只存在于本地的文件夹，开始慢慢变成一个“有名字的地方”。
服务器要放在哪里
接下来就是服务器。
刚开始看的时候，我先思考的并不是配置问题，而是一个更基础的问题：
到底选国内服务器，还是国外服务器？
国外服务器看起来省事一些，根本不需要走备案流程，便可以立即上线；国内服务器对国内访问更友好，但相应地也意味着要认真处理备案这件事。
我来回比较了一阵。
一边看价格，一边看访问体验，也一边考虑着后面的规划。
最后，我还是决定选择国内服务器。
做都做了，为什么不多做一点没做过的事情呢？一次性走完这全套流程，后面也会更得心应手一些。
方向确定以后，接下来才轮到配置。
CPU、内存、硬盘、带宽、流量……
这些参数以前看起来都只是一些数字，可当它们真的变成需要自己选择的时候，我才开始认真理解它们分别意味着什么。
一开始我会下意识觉得：
配置是不是太低了？
带宽会不会不够用？
万一以后有更多需求怎么办？
但查了不少资料以后，我慢慢意识到，一个刚起步的个人网站其实没有必要一开始就把所有东西都堆到很高。
最后，我便选择了一台这样的服务器：2核，2G，3M带宽。
配置很低，但对现在这个网站来说已经足够了。（以后的事以后再说）
从这一刻开始，这个网站终于有了一个可以“住进去”的地方。
在正式上线之前，先把一些概念弄明白
买完服务器之后，我没有立刻开始把域名解析过去，也没有马上接入 CDN。
一方面是因为备案还没有完成，另一方面也是因为我自己心里很清楚：如果只是照着教程一步一步点过去，却不知道自己到底在做什么，那么后面一旦出问题，还是会一下子懵掉。
所以在这段时间里，我先去学习了一些最基础的东西。
比如 DNS 解析。
以前我只知道，输入一个域名就可以打开网站。
但域名到底是怎么找到服务器的，我并没有真正想过。
后来才慢慢弄明白，域名本身更像是一个方便人记住的名字，而 DNS 的作用，是把这个名字和真正要访问的目标关联起来。
再比如 CDN。
我一开始很在意服务器本身的带宽，总觉得带宽小了，网站访问起来肯定会很卡。
后来查资料才知道，对于我这种以静态内容为主的网站来说，很多资源都可以交给 CDN 去分发。
这样一来，源站并不一定要承担所有访问压力。
这个认知对我来说还挺重要。
因为它让我意识到，遇到性能问题时，解决方式并不总是砸钱，“买更高的配置”。（虽然说砸钱确实能解决就是）
有时候真正需要做的，是先弄清楚问题出在哪里，再选择更合适的方式。（花钱怎么就不合适了？哦原来是我太穷了）
这期间我还顺带了解了一些 HTTPS、证书、缓存、回源之类的概念。
不算深入，但至少到了后面真正开始配置时，我知道每一步大概是在做什么。
那段时间有点像是在“预习”。
网站还没有真正上线，但我已经开始提前想象它上线以后会遇到哪些问题。
9 月 8 日，提交备案
等域名、服务器这些东西都准备好之后，下一步就是 ICP 备案。
以前我当然见过备案号。
很多网站底部都会有一行很小的文字。
但以前从来没有认真想过，它到底是怎么来的。
直到轮到自己。
在真正提交之前，我其实已经提前做过一些功课。
知道首次备案需要准备哪些信息，也知道资料不合适时有可能被退回、要求修改，甚至重新提交。
所以到了真正提交备案的时候，我并没有一种“交上去以后等结果就好”的轻松感。
反而有点忐忑。
会担心自己是不是哪里填错了。
会想网站名称、主体信息、域名信息是不是都符合要求。
也会担心某个不起眼的地方，最后变成被退回的理由。
于是那几天，我其实经常会去看消息。
看看有没有新的短信。
看看邮箱里有没有通知。
（我甚至特地为手机卡充了50块钱以防止突然欠费了接不到电话）
也会忍不住打开备案进度页面，再确认一次现在到底走到哪一步了。
哪怕明知道审核本来就需要时间，也还是会偶尔想：
“不会真的被驳回吧？”
现在回头看，这种担心多少有点像第一次交一份自己很在意的申请。
理性上知道，资料没问题就继续等。
但感情上还是会反复确认，生怕哪里突然出了岔子。
那几天里，我一边等备案结果，一边继续在本地调整网站的细节。
偶尔改改页面，写点文章，再搞一搞我感兴趣的其他项目。
偶尔再看看服务器，研究研究要做的事情。
9 月 14 日，备案通过
这一天，我的备案终于通过了。
时间比我想象的短太多了，也没有接到电话，只有一条短信通知。
看到通过消息的时候，我第一反应其实不是“终于可以继续配置了”。
而是：
我不是在做梦吧，怎么这么顺利？
那种一直悬着一点点的心情，终于放了下来。
也是从这一天开始，这个网站才正式从“准备上线”，进入“真正上线”的阶段。
真正开始解析域名
备案通过之后，我做的第一件事，就是把域名真正解析起来。
这时候之前提前了解过的 DNS 概念终于派上了用场。
最开始需要弄明白的，是域名到底应该指向哪里。
如果直接访问源站，就需要让相应的解析记录指向服务器；如果后面接入 CDN，则还会涉及 CNAME。
我开始学着去看解析记录，而不是只把它当成一个需要填空的表单。
当解析结果不对时，我也知道可以先检查记录是不是填错了，再用 nslookup 之类的方式看看域名现在到底解析到了哪里。
这和之前那种“为什么打不开”的感觉已经不太一样了。
因为我开始能顺着问题往下找。
先看域名有没有解析。
解析对了，再看后面的服务。
而不是一上来就怀疑整个网站都坏了。
接入 CDN
接下来就是 CDN。
之前我已经知道 CDN 大概是做什么的，但真正接入时，还是有一套实际流程要走。
先在 CDN 控制台里添加加速域名，再配置相应的源站IP。
然后根据 CDN 提供的地址，把域名解析改成对应的 CNAME，同时停用源站的 A 记录，让域名指向 CDN 服务器。
接入以后，我也开始碰到一些很典型的问题。
比如网站已经更新了，但访问时看到的还是旧内容。
一开始很容易怀疑是不是部署失败了。
后来才知道， CDN 的缓存不是实时的，需要一定时间来刷新。
我会先确认服务器上的文件是不是已经更新，再去判断是不是 CDN 还缓存着旧资源。
如果确认是缓存问题，就去刷新缓存，再重新访问。
这种问题解决过一次以后，我知道了：
“源站已经更新”和“用户已经看到更新”之间，并不总是等号。
HTTPS 和证书
HTTPS 也是类似的过程。
以前我只是知道浏览器地址栏里有一把小锁，知道它代表连接更安全。
真正轮到自己配置时，我才开始理解证书到底放在哪里、CDN 和源站分别要怎么处理。
这一部分如果出了问题，我现在会优先检查几个和 HTTPS 本身直接相关的地方：
- 证书有没有覆盖当前访问的域名；
- CDN 端有没有正确启用 HTTPS；
- CDN 的回源协议是不是和源站配置匹配。
这样一来，问题就不会再变成一句很抽象的“网站打不开”。
至少我知道，这一节该查的是证书和 HTTPS，而不是把 DNS、CDN、服务器从头到尾重新检查一遍。
第一次自己处理这些事情时，还是需要一项一项核对。
但也正是在这种核对里，我慢慢发现：很多问题其实并没有想象中那么“玄学”，只是需要先把范围缩小。
本地能跑，放到服务器上却不一定
还有一类问题也很典型。
本地运行一切正常，放到服务器以后却出了各种错误。
这时候我就不会再从域名、CDN 那一头重新查一遍，而是把范围直接缩小到服务器本身。
我现在通常会按这样一套顺序来：
- 先确认 Web 服务有没有正常运行；
- 再检查 Nginx 配置文件有没有写错；
- 然后确认 80 和 443 端口有没有正常开放；
- 再看看服务器防火墙是不是把请求挡住了；
- 如果还是没有头绪，就直接去看日志。
这些东西以前对我来说都很陌生。
但每解决一个问题，它们就不再只是一个名词。
比起最开始看到错误页面就完全不知道该从哪里下手，现在至少我已经知道：如果问题已经定位到服务器这一侧，就应该只查服务器这一侧真正相关的东西。
这种“先缩小范围，再去找原因”的思路，比把整条链路反复重查一遍有效得多。
网站终于真的上线了
等域名解析、CDN、HTTPS、缓存这些事情都处理好以后，我又重新从头检查了一遍。
域名能不能正常访问。
HTTPS 是否正常。
静态资源有没有加载失败。
CDN 有没有正常回源。
页面更新以后缓存能不能正确刷新。
这些东西一项一项确认下来以后，我终于可以很确定地说：
这个网站真的上线了。
它不再只是本地预览。
不再只是服务器上的一堆文件。
它真正变成了一个可以通过域名被访问到的网站。
回头看，从开始写本地页面，到买域名、选服务器、了解 DNS 和 CDN，再到提交备案、等待审核，最后真正完成解析和上线，其实也没有经历什么特别轰轰烈烈的事情。
大多数时候，不过是遇到一个问题，就去查资料、看文档、试一个方法。
可能成功，也可能失败。
失败了，那就继续查资料，再换一个思路；解决了，就继续往前。
一些“教程”？
看到这儿，如果你和我一样，也想要从零开始搭建一个属于自己的网站，希望下面的流程可以对你有所帮助。
本文适用于中国大陆服务器 + ICP 备案 + CDN + HTTPS这一类比较常见的个人网站部署方式。
不同云服务商、域名注册商、CDN 厂商和服务器系统的控制台名称可能不同，但整体思路基本一致。
如果使用境外服务器，通常不需要走与中国大陆服务器完全相同的 ICP 备案流程，后续步骤也会有所不同。
1. 先把网站在本地跑通
在购买服务器之前，建议先保证网站在本地已经可以正常运行。
至少确认：
- 页面可以正常打开；
- 路由或页面跳转正常；
- CSS、JavaScript、图片等静态资源路径没有问题；
- 构建命令可以正常执行；
- 如果是静态站点生成器，能够正常生成最终部署文件。
如果使用 Astro、Vite 一类工具，还需要区分“开发环境能运行”和“生产构建能通过”这两件事。
例如开发模式下运行正常，并不代表执行生产构建后不会出现路径、资源引用或环境变量问题。
在上传服务器之前，最好先在本地完整执行一次生产构建，并检查最终产物。
这样可以尽量避免把“代码本身的问题”和“服务器部署的问题”混在一起排查。
2. 购买域名并完成实名认证
确定域名后，先完成购买和实名认证。
如果你打算在国内备案，可以去诸如腾讯云、阿里云等处购买域名。
如果你的域名是在境外注册商处购买的，通常需要转入国内注册商。
购买时建议提前确认：
- 域名后缀是否符合自己的用途；
- 域名是否方便记忆；
- 是否准备长期续费；
建议去一些网站上提前检查一下这个域名有没有“黑历史”。
如果以后准备使用多个子域名，也可以提前规划。
例如：
example.comwww.example.comblog.example.comapi.example.com不同子域名可以分别承担不同用途。
常见问题
域名买下来后为什么不能直接访问网站？
因为购买域名只相当于获得了这个名称的使用权，还需要通过 DNS 解析告诉网络“这个域名应该指向哪里”。
域名实名认证和 ICP 备案是一回事吗？
不是。
域名实名认证属于域名本身的实名管理；ICP 备案则是网站使用中国大陆服务器时涉及的另一套备案流程。
3. 选择服务器：国内还是国外
服务器位置会直接影响后面的流程。
中国大陆服务器
优点通常包括：
- 国内访问延迟较低；
- 访问线路相对更稳定；
- 更适合主要面向国内用户的网站。
需要考虑：
- ICP 备案；
- 域名、备案主体、接入商等信息的一致性；
- 后续 CDN 服务可能也会要求域名已备案。
境外服务器
通常不需要走中国大陆服务器同样的备案流程，上线速度更快，但国内访问体验可能受到机房位置、线路质量等因素影响。
在决定好服务器位置后，可以进行配置的选择。选择时不必只看 CPU 和内存，还应同时考虑：
- 带宽；
- 月流量；
- 硬盘；
- 线路；
- 是否方便升级；
- 是否支持快照或备份。
对于静态个人网站，配置通常不需要一开始就买得很高。
CDN 可以承担大量静态资源分发，因此源站本身未必需要很大的公网带宽。
要区分开“专用带宽”和“峰值带宽”。
一般来说，2M、3M、4M这样的都是“专用带宽”，但也有像是200M这样的“峰值带宽”，并且这两者的月付似乎还差不多。
“专用带宽”虽然带宽较小，往往还有月流量限制，但是胜在稳定，你可以在任何时候访问到自己的服务器。
“峰值带宽”则是多台服务器共享带宽。首先，不太可能跑满这个带宽；其次，在高峰期，你需要和你的“邻居”争抢带宽，你很有可能无法访问自己的服务器。
对个人博客、静态站点这类更重视稳定访问而不是大吞吐量的场景，“专用带宽”通常更合适；如果业务更看重突发带宽、大量下载，则可以考虑“峰值带宽”。
4. 购买服务器并完成最基础的初始化
购买服务器后，先完成基础设置。
通常包括：
- 选择或安装操作系统；
- 设置登录方式；
- 更新系统软件包；
- 安装 Web 服务；
- 配置防火墙或安全组；
- 上传网站文件；
- 确认网站在源站本身可以正常访问。
以常见 Linux 服务器为例，通常会使用 Nginx 提供静态文件。
这时不要急着接 CDN，先确认源站本身是正常的。
关于操作系统，Windows Server操作起来显然更简单，但是图形界面会占用大量的服务器性能，一般更推荐使用Linux系统。
应优先检查的几个地方
- Nginx 是否已经启动；
- 网站根目录是否配置正确；
- 文件权限是否允许 Nginx 读取；
- 80/443 端口是否开放；
- 云平台安全组是否放行相应端口；
- 本机防火墙是否拦截请求。
常见坑：安全组开了，但还是访问不了
云服务器通常可能同时存在两层限制：
- 云平台安全组；
- 操作系统自己的防火墙。
只配置其中一层并不一定够。
另外，Nginx 没有启动、监听地址不正确，也会造成“端口明明放行了，但网站还是打不开”。
5. 使用中国大陆服务器时，先完成 ICP 备案
如果网站使用中国大陆服务器，需要按照接入商提供的流程完成 ICP 备案。
通常会涉及：
- 主体信息；
- 域名信息；
- 网站名称；
- 网站服务内容；
- 负责人信息；
- 身份核验；
- 接入商初审；
- 管局审核。
具体要求以当时的接入商和当地通信管理部门要求为准。
备案前最好仔细检查：
- 域名是否已经完成实名认证；
- 域名实名信息是否与备案主体一致；
- 备案主体信息是否填写准确；
- 网站名称是否符合要求；
- 手机号是否能够正常接听电话和接收短信。
不同地区、不同接入商的备案流程可能存在差异，建议专门查询一下。
备案期间通常应按照接入商和当地通信管理局要求，保持网站处于未开通或不可访问状态。
备案通过后，请及时在网站底部悬挂你的ICP备案号。网站开站后，再进行公安备案。
常见坑：因为信息不一致被退回
常见原因包括：
- 域名实名信息与备案主体不一致；
- 联系方式填写错误；
- 网站名称或服务内容不符合要求；
- 材料照片或核验信息不符合规范。
如果被退回，一般不要急着重新提交，先根据退回原因逐项修改。
6. 备案通过后配置 DNS
备案通过后，就可以开始正式配置域名解析。
如果直接访问源站，常见做法是添加 A 记录：
主机记录：@记录类型：A记录值：服务器公网 IP如果还需要 www：
主机记录：www记录类型：A记录值：服务器公网 IP如果准备接入 CDN，则最终通常会使用 CDN 提供的 CNAME，而不是长期直接指向源站 IP。
如何检查解析是否已经生效
可以使用：
nslookup example.com或者：
ping example.com不过需要注意，ping 只能辅助判断域名解析结果，并不能证明网站服务一定正常。
更可靠的思路是分别确认：
- 域名有没有解析到预期目标；
- 目标服务器有没有正常提供 Web 服务。
常见坑：刚修改解析就反复刷新
DNS 记录修改后不一定立即在所有地方生效。
这是因为：
- DNS 有缓存；
- 解析记录存在 TTL；
- 本地运营商 DNS 也可能有缓存。
如果控制台配置确认无误，但本地仍然解析到旧地址，可以稍等一段时间再测试。
7. 接入 CDN
接入 CDN 的典型流程通常是：
- 在 CDN 控制台添加加速域名；
- 填写源站地址；
- 等待 CDN 创建加速配置；
- 获取 CDN 提供的 CNAME；
- 回到 DNS 控制台；
- 将对应域名改为 CNAME 记录；
- 停用与该主机名冲突的 A 记录；
- 等待 DNS 生效；
- 检查 CDN 是否开始正常回源。
一个简化后的访问链路大致是：
用户 ↓域名 ↓DNS ↓CDN 节点 ↓源站服务器用户命中缓存时，资源直接由 CDN 节点返回；只有未命中缓存或缓存失效时，CDN 才需要向源站请求资源。
常见坑：A 记录和 CNAME 同时存在
同一个主机记录下，A 记录和 CNAME 往往不能按预期同时使用。
接入 CDN 后，应根据 CDN 服务商的要求调整记录，避免旧的 A 记录继续让流量绕过 CDN。
常见坑：CDN 已接入，但访问的还是旧页面
优先按下面的顺序检查：
- 源站文件是否真的已经更新；
- CDN 是否仍然缓存旧文件；
- 是否需要主动刷新 CDN 缓存；
- 浏览器是否还保留旧缓存。
不要一看到旧页面就立即重新部署。
很多时候部署本身没有问题，只是缓存尚未更新。
8. 配置 HTTPS
HTTPS 通常涉及两层：
- CDN 对用户提供 HTTPS；
- CDN 回源时与源站通信。
因此需要分别确认：
- CDN 上是否已经配置有效证书；
- 证书是否包含当前域名；
- 源站是否支持 HTTPS；
- CDN 的回源协议是 HTTP 还是 HTTPS；
- 回源协议是否与源站实际配置一致。
常见坑：证书已经配置，但浏览器仍然报错
可以重点检查：
- 证书是否过期；
- 证书域名是否匹配；
- 是否漏掉某个子域名；
- CDN 是否仍在使用旧证书；
- HTTP 是否已经正确跳转 HTTPS。
常见坑：CDN 开 HTTPS 后出现 502 或回源失败
这类情况可能不是用户到 CDN 的 HTTPS 有问题，而是 CDN 到源站的回源协议不匹配。
例如：
CDN 回源方式：HTTPS源站实际只监听：HTTP就可能导致回源失败。
排查时要区分：
用户 → CDN和：
CDN → 源站这是两段不同的连接。
9. 检查缓存策略
静态网站接入 CDN 后，缓存策略会直接影响更新是否及时。
一般来说：
- 带哈希值的 JS/CSS 文件可以缓存较长时间；
- HTML 页面通常不适合无限期缓存；
- 经常变化的接口不应使用和静态资源相同的缓存策略。
常见坑：页面已经更新，但 CDN 一直显示旧版本
可以依次检查：
- 构建产物是否更新；
- 源站文件是否更新；
- CDN 缓存是否刷新；
- 浏览器缓存是否清理。
如果每次更新网站都必须手动清空所有缓存，通常说明缓存策略还有优化空间。
10. 做一次完整的上线检查
正式上线前，建议按用户真实访问路径完整检查一遍。
域名
- 根域名是否正常；
www或其他子域名是否按预期工作；- DNS 是否已经指向 CDN。
HTTPS
- 浏览器是否显示安全连接；
- HTTP 是否可以正确跳转 HTTPS；
- 证书是否覆盖所有需要的域名。
页面
- 首页是否正常；
- 文章页是否正常；
- 页面刷新后是否出现 404；
- 图片、字体、CSS、JavaScript 是否加载正常。
CDN
- 是否正常命中 CDN；
- 源站是否可以正常回源；
- 更新后的页面是否能够正确刷新缓存。
服务器
- Nginx 是否正常运行；
- CPU、内存和磁盘是否正常；
- 日志中是否有大量异常；
- 防火墙和安全组规则是否符合预期。
11. 出问题时，先判断“是哪一层”
真正上线后，最有用的不是记住所有命令，而是先判断问题属于哪一层。
可以大致按下面的思路分类：
域名完全解析不到→ 检查 DNS
域名能解析，但网站打不开→ 检查 CDN / 源站 / Web 服务
CDN 报回源错误→ 检查源站地址、端口、回源协议
HTTPS 报错→ 检查证书和 HTTPS 配置
页面可以打开，但内容还是旧的→ 检查源站文件、CDN 缓存、浏览器缓存
本地正常，服务器异常→ 检查 Nginx、端口、防火墙、权限和日志把问题先分层，再去检查对应配置，通常比从头把整套环境重新检查一遍更有效。
写在最后
写到这里，我发现我为这个网站好像已经做了很多事情。
域名买了，服务器也有了。
备案通过了，DNS 配好了，CDN 接上了，HTTPS 也终于正常工作。
如果只看这些，似乎可以很有仪式感地说一句：
“好了，网站建完了。”
但真的是这样吗？
现在回头看，ICP备案通过更像是一道真正的起跑线。
在它之前，我一直在为“让这个网站能够正式上线”做准备。
目标很明确：
先让它能够真正出现在互联网上。
可等到备案真的通过以后，我才发现，前面折腾了这么久，其实只是解决了“能不能开始”的问题。
紧随其后的是：
域名应该怎么规划？
服务器以后还要不要跑其他东西？
网站后面要更新什么样的内容？
页面还想不想继续改？
今天觉得挺好看的设计，半年以后会不会又看不顺眼？
还有那些现在根本想不到、以后大概一定还会遇到的问题。
这么一想，“网站上线”这件事本身，好像也没有我原先想象中的那种终点感。
它更像是从“我正在搭一个网站”，变成了“我开始维护一个网站”。
前者总还能说出一个大概的完成标准：
页面写好了，备案通过了，域名能访问了——差不多就算完成。
可后者大概没有。
只要这个网站还在，我就总会想往里面再放一点东西。
写几篇新的文章。
改一处不太顺眼的样式。
加一个突然想到的小功能。
偶尔折腾一下服务器。
再顺手解决一个以前完全没遇到过的问题。
是啊，只要这个网站还在，我大概就还会不断遇到新的问题。
也许以后再回头看，一开始能让我查半天资料的问题，都只是一些再基础不过的东西；现在觉得有些棘手的东西，过一段时间之后，也可能变成随手就能处理的小事。
但我想，这并不会让现在这些经历变得没有意义。
正因为它们曾经真的把我难住过，我才会去查资料、看文档、试一个又一个方法，然后在解决问题的过程中，慢慢弄明白那些原本只是见过名字、却不知道究竟有什么用的东西。
所以现在再看，这些问题到底“基础不基础”，好像已经没有那么重要了。
更值得记下来的，是我怎么从完全不知道，到慢慢知道一点。
我并不是因为先学会了这些东西，才开始建站。
恰恰相反。
是因为决定要把这个网站做出来，我才被一个又一个具体的问题推着往前走。
原本我以为，建站就是把网页写出来，然后把它送到某个网站上。
现在，我又开始觉得：
把一个网站送上互联网，大概也只是第一步。
网站上线了，然后呢？
那大概才是这个网站真正开始的地方。
至于它以后究竟会变成什么样子——
说实话，我也不知道。
不过没关系。
反正才刚刚开始。
文章分享
如果这篇文章对你有帮助，欢迎分享给更多人！