我把自己的应用上线了:从买服务器、域名和 DNS,到备案与 HTTPS

从零上线一个网站:服务器、域名、DNS、备案与正式发布

以我已经上线的微言桌面 WyanDesk 为实例,完整走一遍"代码已经写完,如何让用户通过域名稳定访问"的路线。

写完一个网站,和把它真正上线,中间还隔着一整条链路:

text 复制代码
购买服务器 → 注册域名 → 完成实名 → 配置 DNS
       → ICP 备案 → 部署应用 → HTTPS
       → 公安联网备案 → 监控、备份和回滚

每一个箭头都可能出问题。DNS 已经解析,不代表网站就能打开;容器正在运行,不代表外网用户能访问;HTTPS 有了证书,也不代表备份和回滚已经准备好。

这篇文章不绑定某一家云厂商,也不假设你已经懂服务器运维。读完后,你应该能看懂完整的上线顺序,并知道每一步怎样才算真正完成。

本文于 2026 年 10 月 13 日核对。备案、许可和平台界面会变化,实际办理时应以接入商、属地通信管理局、公安机关及其官方平台的当期要求为准。本文不构成法律或行政许可意见。

一、先决定:服务器放在中国大陆,还是境外

这是整条路线的第一个分叉。不要买完服务器后才想起备案。

选择 主要优点 主要代价 适合情况
中国大陆节点 中国大陆用户通常访问路径更短,适合长期经营 通常要先完成 ICP 备案;某些内容或业务还需额外许可 主要服务中国大陆用户的正式产品
中国香港或其他境外节点 可以更快完成技术验证,通常不走中国大陆接入商的 ICP 备案流程 延迟、稳定性、数据和内容合规需另行评估;将来迁回大陆仍要备案 原型验证、海外用户为主的产品

服务器放在境外不等于网站不受任何规则约束,更不应把它当作绕开合规的技术手段。如果你的目标是在中国大陆长期提供服务,最稳妥的方案就是从一开始按大陆节点和正式备案设计。

微言桌面的用户主要在中国大陆,因此我选择了大陆云服务器、自有域名、ICP 备案和 HTTPS 这条更长、但适合长期运行的路线。

二、购买服务器:不要只看 CPU 和价格

对第一个网站,一台常规云服务器就可以起步。比起一开始就追求高配置,下面这些更容易影响后续是否顺利:

  • 地域:靠近主要用户,同时考虑备案主体和服务商支持范围。
  • 公网 IP:确认实例有稳定可用的公网 IPv4;如果使用 IPv6,也要确认客户端和安全策略完整打通。
  • 带宽和计费方式:小网站流量不大时,固定带宽更容易理解成本;图片和下载文件较多时要特别关注出站流量。
  • 备案资格:购买前确认这个节点和产品是否能作为你的备案接入资源。
  • 快照与备份:快照是整机回退手段,但不能代替数据库和用户附件备份。
  • 操作系统:选择仍在安全维护期内的 Linux LTS 版本,不要为了省一点内存使用已停止维护的镜像。

对静态网站、小型 API 或轻量产品,2 核 CPU、2--4 GB 内存、40 GB 左右 SSD 可以作为一个常见的起点,但这不是通用标准。如果你要在同一台机器上运行数据库、搜索、文件处理或多个应用,内存和备份空间很快会成为更重要的瓶颈。

真正实用的方式是:从可承受的配置起步,监控 CPU、内存、磁盘、网络和响应时间,再根据真实使用量扩容。

创建服务器后的第一份检查清单

  • 使用 SSH 密钥,不把密码或私钥写进代码仓库。
  • 先更新系统安全补丁,再安装 Docker、Caddy 等运行环境。
  • 日常维护使用独立账号和 sudo,避免长期直接使用 root。
  • 在云安全组中只开放必需端口:通常是 TCP 80、443,SSH 只对可控来源开放。
  • 不要把 PostgreSQL、MySQL、Redis 等数据库端口直接暴露到公网。
  • 建立固定目录,例如 /opt/myapp,把 Compose、受限环境文件、数据卷和备份分开管理。

三、购买域名:先确定主体,再考虑品牌

域名是你的长期入口,比一台服务器更不应该随意更换。

选域名时可以检查:

  • 是否容易记忆、拼写和口头传播。
  • 是否与产品名、社交媒体账号和开源仓库名尽量一致。
  • 是否存在明显商标冲突或容易造成误解的名称。
  • 续费价格而不只是首年促销价。
  • 注册商是否支持实名、过户、转入转出、DNSSEC 和双因素认证。

根据现行《互联网域名管理办法》,域名注册申请者需要提供真实、准确、完整的持有者身份信息。如果后面要做 ICP 备案,域名持有者与备案主体应当按接入商当期要求保持一致。

注册完成后,立即做三件事:

  1. 开启注册商账号的双因素认证。
  2. 开启到期提醒或自动续费,并确保付款方式可用。
  3. 记录域名持有人、注册商、DNS 服务商和到期日,不要让这些信息只留在某个人的邮箱中。

四、配置 DNS:把域名指向服务器

DNS 的作用,可以简化为"把人能记住的域名,翻译成计算机能连接的地址"。

假设你的域名是 example.com,应用希望使用 app.example.com,常见记录可以这样规划:

主机记录 类型 记录值 用途
@ A <服务器公网 IPv4> 根域名 example.com
www CNAME example.com 让 www.example.com 跟随根域名
app A <服务器公网 IPv4> 产品入口 app.example.com

只有服务器真正配置了公网 IPv6,并且防火墙、路由和应用都已支持时,才添加 AAAA 记录。一条错误的 AAAA 记录可能让部分用户优先走到不可用的 IPv6 地址,出现"有人能打开,有人一直超时"。

修改 DNS 后不要只在自己的电脑上刷新浏览器。可以先查看权威结果:

bash 复制代码
dig +short app.example.com A
dig +short app.example.com AAAA

也可以使用 nslookup app.example.com。看到预期 IP 后,还要在服务器外部的网络进行测试。DNS 变更不是全球同时生效的开关;旧记录可能在递归解析器和客户端缓存中保留到 TTL 到期。

DNS 生效了,网站为什么还打不开

DNS 只负责指路。它不负责:

  • 云安全组是否放行 80/443。
  • 主机防火墙是否拦截请求。
  • Caddy/Nginx 是否正在监听。
  • 反向代理的上游端口是否写对。
  • 证书签发机构能否从公网访问验证路径。

我在实际上线 WyanHub 产品时就遇到过:容器和内部健康检查都正常,DNS 也已经指向服务器,但部分子域的 ACME 校验在公网 80/443 上被 reset 或返回 403,因此拿不到证书。最后需要分层检查客户端出口、云安全组、EIP/WAF、宿主机监听和端口映射,而不是反复修改 DNS。

五、ICP 备案:备案的是主体、服务和接入关系

根据《非经营性互联网信息服务备案管理办法》,如果要使用中国大陆服务器提供非经营性互联网信息服务,应当依法履行备案手续。未经备案,不得在中国大陆从事相应非经营性互联网信息服务。

常见的免费个人站点、产品介绍站会先走非经营性 ICP 备案,但最终应按实际服务性质和主管部门规则判断。经营性互联网信息服务实行许可制;新闻、出版、教育、医疗保健、药品和医疗器械、文化、广播电影电视等领域,还可能需要前置或专项审批。

不能用"网站只是我个人做的"来判断是否只需备案。如果涉及付费信息服务、特殊行业、互联网应用或其他持牌业务,应当先向接入商和主管部门确认。

常见的备案顺序

  1. 确定备案主体:个人或单位,并准备对应的有效证件。
  2. 完成域名实名:域名持有人与备案主体按当期规则匹配。
  3. 准备可用的大陆接入资源:在云服务商备案系统中确认实例符合要求。
  4. 通过接入商提交信息:包括主办者、网站负责人、联系方式、通信地址、网站名称、域名、IP、服务器放置地和接入服务商等。
  5. 完成真实性核验:按平台当期要求完成身份、证件和人像核验;如系统要求,及时完成短信核验。
  6. 等待接入商初审和通信管理局审核:材料不一致时按退回原因修正,不要猜。
  7. 获得备案号后再按要求开通:某些首次备案场景对审核期间的网站状态有明确要求,请遵循接入商提示。
  8. 在首页底部中央显示备案编号 ,并将编号链接到ICP/IP 地址/域名信息备案管理系统。

工信部当前办事信息列出:省级通信管理局收到齐全备案材料后,应在 20 个工作日内予以备案或告知不予备案的理由。这是法定办理时限,不等于每次都会等满 20 个工作日,也不包括接入商初审、材料补正和申请人操作的时间。

上线后,如果发生主体、域名、网站名称、负责人或接入商变化,不要只修改网页;应按当期要求办理变更、新增接入或注销等手续。

六、公安联网备案:不要在拿到 ICP 号后就停下

ICP 备案和公安联网备案是不同的事。

《计算机信息网络国际联网安全保护管理办法》第十二条对相关互联单位、接入单位和使用国际联网的法人及其他组织规定了自网络正式联通起 30 日内办理备案的要求。对外提供服务的网站不应自行忽略这一步;实际范围、材料和展示方式以网站属地公安机关及全国互联网安全管理服务平台的当期要求为准。

常见准备信息包括:

  • ICP 备案主体与网站信息。
  • 域名注册服务商和网络接入服务商。
  • 服务器地址、IP、网站负责人与安全责任人信息。
  • 网站功能、服务内容和安全保护措施。

审核通过后,按审核结果和属地要求在网站底部展示公安备案号、图标和查询链接。

七、部署应用:让服务器只拉取已验证的版本

在生产环境中,建议把"构建"和"部署"分开:

text 复制代码
代码仓库
  → 自动测试
  → 构建固定版本制品
  → 推送到镜像/制品仓库
  → 服务器拉取该版本
  → 健康检查
  → 失败时回退上一版

不要让生产 Compose 使用 latest。否则同一份配置在不同时间可能拉到不同内容,回滚时也无法说清"上一版"究竟是什么。

下面是一个最小 Compose 思路。其中的镜像地址、端口和健康检查命令都必须替换成你的应用实际值:

yaml 复制代码
services:
  app:
    image: ghcr.io/your-name/your-app:v1.0.0
    restart: unless-stopped
    env_file:
      - .env
    ports:
      - "127.0.0.1:8080:8080"
    healthcheck:
      test: ["CMD", "/app/healthcheck"]
      interval: 30s
      timeout: 5s
      retries: 3

这里故意把应用端口绑定到 127.0.0.1,而不是对公网全部网卡开放。公网流量统一先进入 Caddy,再转发给应用。

启动前可以先预览 Compose 会执行什么:

bash 复制代码
docker compose --dry-run --env-file .env up -d
docker compose --env-file .env up -d
docker compose ps

.env 可以存在服务器受限目录中,但不应该提交到 Git,也不要把密码、AK/SK、OIDC secret 或数据库口令打印在部署日志中。

八、用 Caddy 提供 HTTPS

如果 Caddy 安装在宿主机,应用监听在 127.0.0.1:8080,最小 Caddyfile 可以是:

caddyfile 复制代码
app.example.com {
    reverse_proxy 127.0.0.1:8080
}

Caddy 官方文档说明,站点地址使用有效域名时,会默认启用自动 HTTPS 和 HTTP 到 HTTPS 跳转。不要在站点地址前主动写 http://,除非你确定只需要明文 HTTP。

修改配置后,先验证再应用:

bash 复制代码
sudo caddy validate --config /etc/caddy/Caddyfile --adapter caddyfile
sudo systemctl reload caddy

如果你禁用了 Caddy 的 admin API,caddy reload 将不可用;这时需要按自己的 systemd 或容器部署方式验证配置后重建进程。

自动 HTTPS 不是无条件的。在 Caddy 尝试申请公信证书前,至少要确认:

  • app.example.com 已解析到这台服务器。
  • 公网 TCP 80 和 443 可达。
  • 没有旧的 AAAA 记录把部分请求引向错误服务器。
  • 其他 Web 服务没有抢占端口。
  • CDN、WAF 或云防火墙没有拦截 ACME 验证。

九、上线验收:不要只看自己的浏览器

一次可信的上线,至少要从三个视角验收。

1. 服务器内部

bash 复制代码
docker compose ps
docker compose logs --tail=100 app
curl -I http://127.0.0.1:8080/
ss -lntp

确认容器正在运行、健康检查通过、本机上游可访问,并且没有把数据库或管理端口意外监听在 0.0.0.0。

2. 公网外部

bash 复制代码
dig +short app.example.com A
curl -I http://app.example.com/
curl -I https://app.example.com/

应当检查 HTTP 是否跳转 HTTPS、HTTPS 是否返回预期状态码、证书域名和有效期是否正确。最好再用手机移动网络或另一个地区的网络检查,避免把服务器自访问成功当成公网验收。

3. 用户任务

真正按用户路线操作:

  • 首页是否能快速打开,手机是否溢出。
  • 注册、登录、退出和回跳是否正常。
  • 写入、查询、上传、下载和删除是否符合权限。
  • 公开页是否可匿名访问,管理页是否会拦截未登录用户。
  • 断网、刷新、重复提交和两个设备同时编辑时会发生什么。

只有这些真实任务通过,才能说产品已经上线,而不是"容器已启动"。

十、上线不只是能打开:让用户愿意相信和分享

如果网站承担产品推广,上线前还应该检查:

  • 清晰的 <title> 和页面简介。
  • Canonical 规范地址,避免多个 URL 指向同一内容时产生歧义。
  • Open Graph/Twitter 标题、简介和正方形图标,让分享链接至少能生成基础卡片。
  • Favicon、PWA Manifest 和移动端图标。
  • 合理的 robots.txt 和 Sitemap,但不应将管理后台、回执、私密数据页放进搜索引擎。
  • 备案号、隐私说明、数据删除途径和有效的反馈联系方式。
  • 真实的 404、错误状态和加载失败提示,不要把所有失败都伪装成首页 200。

这些看起来不如"新增一个功能"显眼,却直接决定用户第一次打开、分享和判断网站是否可信时的感受。

十一、备份、监控和回滚:网站上线是运维的开始

至少保留三类备份:

  1. 配置备份:Compose、Caddyfile、服务单元和受限环境配置。
  2. 数据备份:使用数据库自身导出机制,而不是只复制正在写入的数据文件。
  3. 用户文件备份:附件、图片、导出结果等按业务保留期单独备份。

备份不是"脚本没报错"就算完成。应定期在隔离环境解压、校验和试恢复,确认备份真的可用。包含密钥、个人信息或业务数据的备份应加密、限制访问,并遵守明确保留期。

监控至少覆盖:

  • 站点从公网是否可访问,证书是否即将到期。
  • CPU、内存、磁盘和容器重启次数。
  • 数据库、同步任务和备份是否成功。
  • 4xx/5xx、上游超时和异常登录。

发布时先备份,再拉取固定版本,切换后做健康检查,失败时恢复上一份 Compose 或镜像。需要注意:镜像回滚不等于数据库回滚,包含不可逆迁移的版本必须另行设计数据恢复方案。

十二、真实案例:微言桌面是怎样上线的

微言桌面 WyanDesk 是我做的一个本地优先浏览器桌面:把常用网站、任务、日程、便签和专注计时放进一个安静、可定制的页面。

它的官方站点不只是一个静态演示页,而是一个真正按上述路线运行的产品:

text 复制代码
用户
  ↓ HTTPS
desk.wyanhub.com
  ↓ DNS
Caddy(TLS、安全响应头、公开/登录路由)
  ├── Desk 静态前端(未登录也能使用)
  ├── WyanHub/Casdoor(用户主动登录)
  └── Desk API(可选云同步、历史版本和删除)

我在设计时先确定了数据边界:

  • 未登录用户的快捷网站、任务、便签和设置默认留在当前浏览器。
  • 登录不是使用前提,只在用户主动选择时增加跨设备同步能力。
  • 云同步可选 AES-256-GCM 端到端加密,加密口令不上传,服务端不能解密载荷。
  • 用户可导入、导出和删除数据;同步保留最近 20 个历史版本供恢复。
  • Chrome/Edge 扩展只在用户使用对应功能时申请标签页或书签权限;当前扩展可从项目 Releases 下载,不宣称已在扩展商店上架。

上线层面也遵循同样的可恢复思路:代码提交不会直接变更生产;新的不可变版本标签触发自动测试和 linux/amd64 镜像构建,生产再人工执行带备份、健康检查和回滚的发布脚本。

截至 2026 年 10 月 13 日,微言桌面官方站点已正式开放,实际公网验证返回 HTTPS 200,并已配置 HSTS、安全响应头、Canonical 和 Open Graph/Twitter 分享元数据。站点页脚显示 鄂ICP备2023002649号-3,并链接工信部备案系统。

你可以直接试用:

如果你不想注册账号,打开就能使用本地功能;如果你需要在多台设备之间衔接,再选择登录和同步。这正是我想验证的产品关系:本地数据是主角,账号和服务器提供增量能力,但不反过来绑架最基本的使用。

十三、最终上线清单

可以在正式对外发布前,逐项打勾:

基础资源

  • 服务器地域、规格、带宽、公网 IP 和续费价格已确认。
  • 操作系统仍在安全维护期。
  • SSH 使用密钥,云安全组与主机防火墙只开放必需端口。
  • 数据库和内部管理端口未暴露公网。

域名和合规

  • 域名已实名,持有人与备案主体符合当期要求。
  • A/CNAME 记录正确;没有无效的 AAAA 记录。
  • 需要 ICP 备案的站点已取得备案号,并在首页底部展示和正确链接。
  • 已根据属地要求办理公安联网备案并展示相应信息。
  • 经营性或特殊行业已另行确认所需许可/前置审批。

部署和安全

  • 生产使用固定版本标签或镜像摘要,未使用 latest。
  • 密钥只在受限环境或密钥系统中,不在 Git 和日志中。
  • HTTP 跳转 HTTPS,证书域名正确,公网 80/443 可达。
  • 公开路由和管理路由的认证边界已实际验证。
  • 依赖、系统补丁、安全响应头和错误页已检查。

产品与运维

  • 手机和桌面端的关键用户任务已验收。
  • 标题、简介、图标、Canonical 和分享卡片已配置。
  • 隐私说明、数据导出/删除路径和反馈通道可用。
  • 数据库、用户文件和配置均有备份,且已试恢复。
  • 有外部可用性、证书、磁盘和错误监控。
  • 发布失败时知道如何回到上一版;数据迁移有单独恢复方案。

常见问题

可以先写网站,等备案通过后再上线吗?

可以。代码开发、本地测试、自动构建、运维脚本、备份和内网验收都可以先做。是否可以在备案审核期间使用当前域名对外提供内容,应遵循接入商当期指引。

只购买域名,不解析,需要备案吗?

单纯持有域名和利用大陆接入资源对外提供互联网信息服务不是一件事。备案解决的是在中国大陆境内提供相应互联网信息服务的问题;实际启用前按服务器地域、接入商和业务性质确认即可。

有了 ICP 备案号,是不是什么网站都能做?

不是。ICP 备案不代表获得了所有业务的许可。经营性服务、特殊行业、互联网新闻、医疗药品、视听内容等可能需要其他许可或审批。

为什么服务器内访问正常,外网却打不开?

按这个顺序查:DNS 记录 → 公网 IP/EIP 绑定 → 云安全组 → 主机防火墙 → 80/443 监听 → Caddy 站点地址 → 上游应用端口 → CDN/WAF → IPv6 AAAA。不要因为某一层正常就跳过后面的层。

有了 HTTPS,网站就安全了吗?

不是。HTTPS 保护传输通道,不会自动修复弱密码、越权接口、依赖漏洞、错误的跨域、公开数据库或没有备份等问题。

参考资料


把网站上线的意义,不只是得到一个可以分享的 URL。

它迫使我们回答一系列更具体的问题:用户的数据放在哪里?服务失败后怎么恢复?域名和证书到期时谁来处理?一次错误发布能不能回退?用户第一次看到这个网站时,凭什么愿意相信它?

当这些问题都有答案时,一个"我写出来的项目",才真正开始变成一个可以长期使用的产品。

相关推荐
suhan1 小时前
【数据结构】三、栈和队列:6.链队列、双端队列、队列的应用(树的层次遍历、广度优先BFS、先来先服务FCFS)
数据结构·后端·算法
neoooo1 小时前
🚀Claude Code 小技巧(二):找回会话,撤销修改
前端·人工智能·后端
数据库小学妹1 小时前
向量检索最小可运行实现:HNSW索引参数与召回率/延迟权衡
数据库·后端
姜鱼问生1 小时前
Docker Volume 备份与恢复实战:不停机迁移数据
后端·算法·架构
suhan1 小时前
【数据结构】三、栈和队列:5.顺序队列(循环队列)(初始化,判空判满,入队,出队,实例)
数据结构·后端·算法
看浪的路人1 小时前
第7讲:大模型后端服务化——Go 实现高并发 LLM Proxy / Router / Fallback
开发语言·后端·golang
suhan1 小时前
【数据结构】三、栈和队列:3.链栈(链栈栈的初始化,判空,进栈,出栈,读取栈顶,链栈实例)
数据结构·后端·算法
邱杰4701 小时前
数智人事系统(十一):Spring Boot + MyBatis-Plus 的 CRUD 落地
后端·github
姜鱼问生1 小时前
服务器磁盘满了?从告警到清理的完整排查
后端·算法·架构