第一次搭网站的人，最容易卡在三个地方：买了服务器不知道域名该怎么指，域名解析完了不知道服务器里该装什么，程序装好了又因为端口、权限或备案问题访问不了。这些问题看起来分散，本质上是一条链路上的四个环节：域名、服务器、DNS 解析、网站程序。任何一环没接通，浏览器表现都是同一个结果——打不开。

这篇文章按这条链路的顺序讲，把每一环做什么、为什么这么做、做完怎么验证说清楚。命令部分区分 RHEL、CentOS、Rocky 系（使用 dnf 或 yum，防火墙是 firewalld）和 Debian、Ubuntu 系（使用 apt，防火墙是 ufw）。文中使用 example.com 作为示例域名，实际操作时请替换成自己的域名，并且在执行任何修改配置的操作前先备份。

一次网站访问到底经过哪些环节

在动手之前，先建立一个完整的链路图，后面排错会快很多。用户在浏览器输入 https://www.example.com 并回车后，大致发生这些事：

第一，浏览器要先把域名变成 IP 地址，这一步叫 DNS 解析。浏览器先查自身缓存和操作系统缓存，没有命中就向配置的递归 DNS 服务器（通常是运营商或公共 DNS）发起查询，递归服务器再从根域名服务器、顶级域名服务器一路查到你的域名权威 DNS 服务器，拿到 A 记录或 AAAA 记录里的 IP。

第二，浏览器向这个 IP 的 443 端口发起 TCP 连接，完成 TLS 握手，确认证书里的域名与实际访问的域名匹配。如果这里用的是 80 端口且服务端没有跳转，那就是明文 HTTP。

第三，TCP 连接建立后发送 HTTP 请求，请求头里带有 Host 字段。服务器上的 Web 服务（Nginx、Apache、IIS 等）根据 Host 字段匹配对应的虚拟主机配置，决定使用哪个站点目录。这就是为什么一台服务器能同时托管几十个网站。

第四，Web 服务判断请求的资源类型。静态文件（图片、CSS、JS）直接读盘返回；动态请求交给后端处理，比如 PHP-FPM、Java 应用、Node 服务，或者通过反向代理转发到另一台机器。

第五，后端处理过程中通常会查数据库、读写缓存、调用第三方接口，最后生成响应返回给浏览器。浏览器再并行下载页面里的静态资源，完成渲染。

理解这条链路的意义在于：当用户说"网站打不开"时，你可以用分层的方式快速定位，而不是盲目重启服务。

第一步：域名注册与实名认证

域名是在注册商处购买的"使用权"，不是买断所有权，到期需要续费。国内注册商和主流国外注册商都可以注册，选择时看三点：续费价格的长期水平、域名管理后台是否支持你需要的 DNS 功能（比如泛解析、DNSSEC、API 批量修改）、以及转出是否方便。

注册完成后有一个容易被忽略的步骤：实名认证。在国内注册商注册的域名，必须提交真实身份材料完成实名，否则域名会被暂停解析（Serverhold 状态）。这一步通常在注册后几天内完成，材料是个人身份证或企业营业执照，提交后等待审核。

后缀选择上，.com、.cn、.net 是最常见的。需要注意的是，不同后缀的备案政策不同：工信部对可备案的域名后缀有明确清单，一些小众后缀无法用于国内服务器备案。如果你的网站要放在中国大陆的服务器上，注册前先确认这个后缀支持备案。

关于备案，规则是这样的：服务器在中国大陆境内，域名必须完成 ICP 备案才能通过 80/443 端口对外提供服务；服务器在中国香港、新加坡、日本、美国等地，则不需要备案。这不是注册商的要求，而是接入服务商（云厂商）在网络层面的管控。备案通常由云厂商免费代办，流程包括提交主体信息、网站信息、负责人核验（人脸识别或幕布照片）、短信核验、管局审核，整体周期一般是十几天到二十天左右，各地管局时间不同。

备案期间有一个常见误区：有人认为"先用海外服务器，备案好了再迁回来"是个好主意。这确实是可行方案，但要提前想清楚——境外服务器到国内用户的网络延迟和稳定性明显不如境内容量，而且迁移本身有一整套工作量。如果你的用户群体主要在国内且站点长期运营，直接走备案流程通常更省事。

另外，备案信息里的域名和服务器接入商是绑定的。后续更换服务商需要做"接入备案迁移"，域名所有者信息变更要做"变更备案"。这些流程本身不复杂，但需要提前规划，不要等到搬家当天才发现域名不能用。

第二步：服务器选型

拿到域名之后是服务器。新手面对的第一个问题是买什么配置。不给具体报价，但可以给出量级参考：

这些是经验起点，不是一个标准答案。真正决定配置的是实际监控数据：内存是否长期吃紧、iowait 是否偏高、数据库缓存命中率多少、峰值并发连接数多少。先按建议起步，跑一段时间后根据数据调整，比一开始就买高配更合理。

地域选择遵循一个原则：离用户越近越好。用户集中在国内就选国内节点并完成备案；用户在海外就选对应的海外区域。带宽方面要注意，云厂商标注的通常是出网带宽，计费方式有按固定带宽和按流量两种。如果流量波动大（比如有促销、有下载文件），按流量计费可能更合适；如果流量平稳且需要稳定的下载速度，固定带宽更容易预估。

还有两个容易被忽视的点：一是按量付费和包年包月的选择，长期运行的业务一般包年包月更划算，临时测试环境用按量付费随时释放；二是快照与备份策略，开一个自动快照策略花不了多少，但能在误删数据时救命。快照不能替代应用级备份，两者是互补关系。

操作系统镜像建议选 Rocky Linux、AlmaLinux、CentOS Stream（RHEL 兼容系）或 Ubuntu LTS、Debian（Debian 系）。Ubuntu LTS 有五年的标准支持期，文档和社区资源最丰富，新手友好；Debian 以稳定著称，软件包版本相对保守；Rocky 和 AlmaLinux 是 CentOS 停服后的主流替代，适合习惯 RHEL 生态的团队。选择时优先考虑自己能查到资料的发行版，而不是"最好"的发行版。

购买后的第一件事不是装网站，而是初始化：

# 查看系统版本
cat /etc/os-release
hostnamectl

创建普通用户并禁用 root 直接登录 SSH（风险提示：修改 SSH 配置前务必保留当前连接不断开，并另开一个终端测试新配置能否登录）：

# Debian、Ubuntu
sudo adduser deploy
sudo usermod -aG sudo deploy

# Rocky、RHEL、CentOS
sudo useradd -m deploy
sudo passwd deploy
sudo usermod -aG wheel deploy

然后更新系统并配置主机防火墙：

# Rocky、RHEL、CentOS（dnf，旧版用 yum）
sudo dnf upgrade --refresh -y
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh
sudo firewall-cmd --permanent --add-service=http
sudo firewall-cmd --permanent --add-service=https
sudo firewall-cmd --reload

# Debian、Ubuntu（apt）
sudo apt update && sudo apt upgrade -y
sudo ufw allow OpenSSH
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp
sudo ufw enable

注意这里有两层访问控制：云平台的安全组，以及操作系统内的 firewalld 或 ufw。两层都要放行 80 和 443，缺一层都访问不了。这是新手最常踩的坑之一——服务器内防火墙配好了，忘了安全组，或者反过来。

第三步：DNS 解析记录类型与 TTL

域名注册商一般会自带 DNS 解析服务，也可以把 NS 记录改成第三方 DNS 服务商（如支持 API 的 DNS 厂商）来获得更细的控制能力和更快的生效速度。解析记录是这套系统的核心，下面这张表把常见类型讲清楚：

主机记录里的 @ 代表裸域名（example.com），* 代表泛解析（匹配所有未单独配置的子域名）。www 是最常用的子域。

TTL（Time To Live）决定了这条记录被递归 DNS 服务器缓存的秒数。TTL 600 表示十分钟内，各地递归服务器大概率直接用缓存结果，不会回来查。这带来两个实际结论：

一是日常运行用较大的 TTL（如 3600 或 600），可以减少查询次数、提升解析速度，也降低权威 DNS 的压力。

二是计划换服务器 IP 之前，要提前把 TTL 调低（如调到 60 或 300），并且要在预计切换时间的至少一个旧 TTL 周期之前就改。比如原来是 3600，想明天十点切换，那今天九点前就得把 TTL 改成 60，让各地缓存尽快过期。这一步没做，切换后会出现部分地区用户还访问旧服务器的现象，而且排查起来很费时间。

邮件相关记录要额外注意。SPF 是一条 TXT 记录，声明哪些服务器被允许用这个域名发信；DKIM 是一条特定主机名下的 TXT 记录，存放公钥；DMARC 是 _dmarc.example.com 的 TXT 记录，告诉收件方如何处理验证失败的邮件。这三条配齐，外发邮件进入收件箱的概率会明显提升，缺配置则容易被判为垃圾邮件。

第四步：验证解析是否生效

DNS 记录添加后不能只看控制台提示"已添加"，必须在多个网络环境下实际验证。常用工具如下。

Windows 命令提示符或 PowerShell：

nslookup example.com
nslookup -type=AAAA example.com
nslookup -type=MX example.com

Linux 或 macOS（dig 在 Debian、Ubuntu 上属于 dnsutils 包，RHEL 系属于 bind-utils 包）：

dig example.com A +short
dig example.com AAAA +short
dig example.com NS +short
dig www.example.com CNAME +short

dig 默认查 A 记录，+short 只输出关键信息。想看完整的 TTL 剩余时间可以去掉 +short，观察输出中的 TTL 数字。想指定某个 DNS 服务器查询，可以加 @ 参数：

dig @1.1.1.1 example.com A
dig @223.5.5.5 example.com A

验证时有一个重要技巧：用公共 DNS 查询，而不是只查本地默认 DNS。本地 DNS 往往是运营商的，缓存策略不可控，查询结果不能代表全网。分别用几个公共 DNS 查一遍，结果一致才说明记录已经扩散。

curl 也可以直接验证 HTTP 层的响应，能绕过浏览器缓存带来的干扰：

curl -I http://example.com
curl -sSv https://example.com -o /dev/null

如果 dig 返回的 IP 正确但 curl 连不上，问题就不在 DNS，而在网络或服务端——这时候应该去检查安全组、主机防火墙、Nginx 是否监听、端口是否开放。这就是前面说的分层定位。

第五步：选择网站程序

环境准备好之后是选程序。程序决定了后续需要什么运行环境，也决定了数据库、缓存、备份策略的形态。

选程序的实用原则有三条。第一，优先选择自己能维护的。一个功能很强但你不会升级、不会备份、出问题不知道看哪个日志的程序，长期成本远高于简单的方案。第二，看生态和更新频率。长期不更新的程序存在安全风险，插件和主题长期不兼容也会导致维护困难。第三，考虑资源消耗。一台 2 GB 内存的机器跑一个重型电商系统，体验会很差，不如一开始就把数据库拆出去或者提高配置。

如果只是为了放一个介绍页面或者文档站，静态站点生成器加Nginx的组合是最省心的：没有数据库，没有动态执行，几乎没有安全面，加载速度也快。只有当确实需要后台管理、用户注册、在线交易时，才必须上动态程序。

第六步：跑通最小闭环

以最常见的 Nginx 为例，先让它跑起来，再考虑装 PHP 和数据库。

Rocky、RHEL、CentOS 系：

sudo dnf install -y nginx
sudo systemctl enable --now nginx
sudo systemctl status nginx --no-pager

Debian、Ubuntu 系：

sudo apt install -y nginx
sudo systemctl enable --now nginx
sudo systemctl status nginx --no-pager

Debian 系的站点配置放在 /etc/nginx/sites-available/ 与 /etc/nginx/sites-enabled/，两者通过符号链接关联；RHEL 系一般直接放在 /etc/nginx/conf.d/*.conf。两边都会在主配置里 include 这些目录。

写一个最小的站点配置文件：

server {
    listen 80;
    listen [::]:80;
    server_name example.com www.example.com;

    root /var/www/example.com/public;
    index index.html;

    access_log /var/log/nginx/example.com.access.log;
    error_log  /var/log/nginx/example.com.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

创建目录和测试页面：

sudo mkdir -p /var/www/example.com/public
echo '
Hello
' | sudo tee /var/www/example.com/public/index.html
sudo nginx -t
sudo systemctl reload nginx
curl -H 'Host: example.com' http://127.0.0.1/

nginx -t 是每次修改后必做的动作，它会检查语法并输出配置文件路径。语法检查不通过就不要 reload，否则旧进程虽然还在跑，但你的改动没有生效，很容易误判。确认本机 curl 返回正常内容后，再从外网浏览器访问域名，这时候通了才算真的通。

最后加 HTTPS。Certbot 是最常用的免费证书工具：

# Debian、Ubuntu
sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

# Rocky、RHEL、CentOS
sudo dnf install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

# 必须验证自动续期，这是很多站点三个月后证书过期的根因
sudo certbot renew --dry-run
sudo systemctl list-timers | grep certbot

从零到上线清单

把上面的步骤压缩成一张可勾选的清单，照着做不会漏项：

常见误区

有几个坑几乎每个新手都会踩一次，提前知道能省很多时间。

第一个是把 DNS 和 Web 服务的职责搞混。DNS 只负责把域名翻译成 IP，它不关心你的 Nginx 是否运行、是否有多个站点。改记录、改服务器的 Nginx 配置，这是两件独立的事。

第二个是忽略 DNS 缓存。刚改完解析立刻刷新浏览器，发现没变化就反复修改。正确的做法是等 TTL 过期，或者用 dig 加指定 DNS 服务器来验证记录本身是否已经正确。

第三个是只配了安全组没配系统防火墙，或者反过来。云平台安全组是网络层的访问控制，firewalld 和 ufw 是主机层的，两者是串联关系，都要通过才会放行。

第四个是把源码直接放在网站根目录。正确做法是让根目录指向一个专用于对外暴露的子目录（如 public），把配置文件、环境变量、备份放在它之外，避免被直接下载。

第五个是证书配完就不管了。免费证书有效期九十天，自动续期必须验证成功才算数。很多"网站突然打不开提示证书过期"的事故，都是续期定时任务从来没成功运行过。

常见问题

国内服务器必须备案吗？

服务器在中国大陆境内就必须备案，这是接入商在网络侧的强制要求。如果选择中国香港、新加坡、日韩、欧美等地节点，不需要备案，但国内用户访问延迟通常会明显更高。

域名在一个平台、服务器在另一个平台可以吗？

完全可以。域名注册商和服务器厂商不需要是同一家，只要在域名注册商（或你所用的 DNS 服务商）处把解析记录指向服务器 IP 即可。备案则需要通过服务器所在的接入商提交。

解析添加之后多久能访问？

记录本身一般在几分钟内同步到 DNS 服务商的全部节点，但各地递归 DNS 会用旧缓存直到原来的 TTL 过期，所以全球完全生效通常需要几十分钟到一天不等。验证时用多个公共 DNS 查询比盯着浏览器刷新更准。

一台服务器可以放多个网站吗？

可以。Nginx 和 Apache 都支持基于 server_name（Apache 里是 ServerName 和 ServerAlias）的虚拟主机，多个域名可以指向同一个 IP，由 Web 服务根据请求头里的 Host 字段区分站点。

备案期间域名可以先解析吗？

可以解析，但在备案通过前，境内服务器上的 80 和 443 端口对外是被接入商拦截的，浏览器访问会被阻断或提示未备案。这时候可以用非标准端口配合临时访问做调试，正式上线还是得等备案通过。

静态网站服务器要什么配置？

资源要求很低，1 核 1 GB 内存的机器足以支撑相当可观的静态页面访问量。真正的瓶颈通常是带宽而非 CPU，配合 CDN 和对象存储可以进一步降低源站压力。

总结

• 网站上线是域名、服务器、DNS、程序四个环节的串联，排错时要按链路分层定位，不要一上来就重启服务。
• 国内服务器必须完成 ICP 备案才能对外提供 80/443 服务，注册域名时就要确认后缀是否在可备案清单内，且需要提前预留十几天到二十天左右的审核周期。
• DNS 记录要理解 A、AAAA、CNAME、MX、TXT、NS 各自的用途，尤其是 MX、SPF、DKIM、DMARC 对邮件可达性的影响；迁移前提前降 TTL 是避免长时间不一致的关键动作。
• 服务器初始化必须同时处理云平台安全组和主机防火墙（firewalld 或 ufw），两者缺一都访问不了；SSH 来源要限制，不要对全网开放。
• 程序选型以"自己能长期维护"为第一原则，站点根目录指向专门的公开子目录，SSL 证书签发后必须实际验证自动续期，数据库和上传文件要做异地备份并演练恢复。