企业官网建设流程全解析

用户：有位做个人博客的朋友，白天还在群里说网站搬家到新服务器后一切正常，晚上就发现站点打不开了。他在群里连发好几条消息，问是不是服务器提供商出了问题。结果检查了一圈，域名解析记录里悄然多了一条指向旧服务器的A记录，TTL缓存还没过期，全球节点一部分解析到新地址，一部分还在访问旧IP——这就是典型的"网站打不开"背后藏着的混合病因。

我这些年帮人排查过不少类似的建站故障，发现大多数"打不开"并不是真的服务器挂了，而是问题出在几个非常具体、非常容易忽略的环节上。今天就把这些场景完整拆开来说，覆盖从DNS解析、服务器状态、Web服务配置到本地网络和程序文件的全部链路，你可以照着顺序一步步排查，大部分问题自己就能定位清楚。

1. 先搞清楚"打不开"到底是哪种打不开

接到"网站打不开"的求助，我第一件事从来不是去敲命令，而是先问一句：你是打不开，还是打开得很慢？是手机打不开还是电脑打不开？是所有人都打不开还是只有你打不开？

这三个问题能直接过滤掉一半的故障原因。很多人把"打不开"当成一种情况，实际上它可以拆成至少五种完全不同的症状：

如果你遇到的是第一种"无法访问此网站"，那就意味着从你的电脑到服务器之间，根本没能建立起TCP连接。这时候不要急着登录服务器去改配置，先按照下面几个环节一步步排查，很多时候问题根本不在服务器上。

还有一种很典型的场景：网站昨晚还好好的，今天突然打不开。这种情况第一反应应该是去检查域名是否到期、服务器是否欠费、HTTPS证书是否过期。这三样东西是"突然打不开"的头号元凶，比程序出bug的概率高得多。

2. 域名解析环节：为什么浏览器找不到你的网站

2.1 先用基础命令确认解析是否正常

当域名打不开时，第一步必然是确认域名解析结果。在你自己的电脑上打开终端（Windows用CMD，macOS/Linux用Terminal），执行：

ping 你的域名

如果你能看到返回的IP地址，说明域名解析是正常的；如果提示"找不到主机"或者ping不到任何IP，那问题就出在DNS解析环节。

接着用另一个命令确认IP是否正确：

nslookup 你的域名

这个命令会返回域名对应的IP地址。重点看返回的IP是不是你服务器当前的真实IP——很多人在服务器提供商的控制面板里换了IP地址，但DNS记录还停留在旧IP上，自然怎么折腾都打不开。

2.2 解析记录改过之后，全球生效需要时间

这里有个非常容易被忽视的坑：DNS解析记录修改后，不是立刻全球生效的。每家域名注册商或云解析服务商都有自己的TTL（缓存存活时间）设置，有的默认是600秒，有的是3600秒甚至更长。TTL时间内，全球各地的DNS缓存服务器还保留着旧记录，用户访问时会被指向旧地址。

我的建议是：修改解析记录之前，先把TTL调小到60秒或300秒，等确认解析全部生效后再把TTL调回正常的3600或7200。新站长很少注意这个细节，结果就是改完解析后别人死活打不开，以为是服务器配置有问题，折腾半天其实是老的TTL在作怪。

2.3 hosts文件与本地DNS缓存：电脑自己"记住"了旧地址

还有一种很气人的情况：域名解析明明已经改成新IP了，手机能够正常打开网站，但电脑就是打不开。这大概率是本机DNS缓存或者hosts文件在捣乱。

Windows系统排查顺序如下：

# 刷新本机DNS缓存 ipconfig /flushdns # 检查hosts文件是否存在解析覆盖 notepad C:\Windows\System32\drivers\etc\hosts

打开hosts文件后，检查有没有一行类似"旧IP 你的域名"的记录。很多人以前调试时手动加过这条记录，之后忘记删除，结果一直访问旧地址。hosts文件的优先级高于DNS服务器，它会直接拦截解析，让你死活连不上新服务器。

macOS和Linux用户对应使用sudo dscacheutil -flushcache和sudo systemctl restart systemd-resolved刷新缓存。

2.4 域名过期是最容易被忽略的"静默杀手"

我处理过一个案例：某朋友的网站突然打不开，服务器运行正常、解析正常、本地网络正常，排查了半天才发现是域名过期了，注册商已经停止解析服务。很多域名注册商在域名过期后会进入宽限期，宽限期内还能续费，但解析可能已经停止。

建议所有建站的人给自己的域名设置自动续费，并且保持注册邮箱畅通。域名续费提醒邮件被误判为垃圾邮件、或者留的是很久不用的邮箱，这种情况我见得太多了。

3. 服务器状态排查：CPU、带宽与磁盘的"假宕机"

3.1 服务器是否真的在线？登录控制台看运行状态

如果你确认DNS解析没问题、域名没到期，下一步就要确认服务器本身还活着。很多人习惯用"能不能ping通"来判断服务器是否在线，但这并不完全可靠——很多服务器禁ping，或者防火墙屏蔽了ICMP协议。

最直接的办法是登录服务器提供商的云控制台，查看实例的运行状态和监控图表。如果控制台显示运行中，但CPU或带宽跑到100%，这就是典型的"假宕机"——服务器没挂，但已经没力气响应请求了。

3.2 CPU跑满：被攻击还是一只"死循环"脚本？

CPU使用率100%时，网站会变得极其缓慢甚至完全无法访问。登录服务器后，用下面命令找出是谁吃掉了CPU：

# 查看实时CPU占用排行 top -c # 按CPU占用排序，定位进程PID ps aux --sort=-%cpu | head -20

如果找到某个PHP进程或者Python脚本长期占用CPU，先记录PID，然后用kill -9 PID结束进程，再检查是不是定时任务异常重复执行。

还有一种情况是被人打了流量攻击，带宽被耗尽，CPU反而不高。这时控制台的入方向流量监控会显示异常。遇到这种状况，首先要做的不是跟对方较劲，而是启用服务商提供的流量清洗或高防IP，同时检查服务器的安全组是否只放行了必要端口。

3.3 磁盘写满：服务"活着"但写不了日志

磁盘爆满是一个非常隐蔽的故障原因。服务器CPU正常、内存正常、进程正常，但网站就是打不开，打开时还可能显示500错误。原因可能是日志文件把磁盘占满了，导致Web服务无法写入新的日志、程序无法生成临时文件。

排查命令：

# 查看磁盘使用率 df -h # 找出占用空间最大的目录 du -sh /var/log/*

如果你用的是Nginx或Apache，日志目录通常是/var/log/nginx/和/var/log/apache2/。这些访问日志会无限增长，建议配置logrotate自动轮转压缩，保留7天就够了，别让日志吃掉整块磁盘。

另外还要关注/tmp目录。PHP程序默认的临时文件目录如果满了，用户上传图片、导出文件都会失败，现象同样是页面报错或者卡住不动。

3.4 内存不足触发OOM Killer

内存耗尽时，Linux系统有一个OOM Killer机制，它会根据评分杀掉占用内存最大的进程——如果你的Web服务进程被系统杀掉了，网站自然就"打不开"了。

查看是否发生过OOM：

dmesg | grep -i oom

如果发现Nginx或PHP-FPM经常被OOM杀掉，最直接的解决办法是给服务器加内存，或者优化PHP-FPM进程数配置。很多人在1G内存的小机器上把PHP-FPM的最大进程数设成50，结果内存瞬间被打满。对于1G内存的机器，PHP-FPM进程数控制在10到15个就足够了。

4. Web服务与程序配置：访问日志里的关键线索

4.1 为什么第一步先看错误日志

排查Web层面的问题，我的习惯永远是先看错误日志，而不是打开浏览器反复刷新。错误日志会直接告诉你服务哪里出了问题，省去大量猜测时间。

Nginx的错误日志位置：

tail -f /var/log/nginx/error.log

常见错误对应如下：

4.2 端口监听状态：Nginx起来了，但PHP-FPM没起来

Nginx本身只是个代理，真正处理动态请求的是PHP-FPM。很多人只检查了Nginx状态，发现它是正常的，就以为Web服务没问题，但网站仍然打不开——因为PHP-FPM挂了。

检查端口监听情况：

# 查看Nginx是否监听80/443端口 netstat -tlnp | grep -E ":80|:443" # 查看PHP-FPM是否监听9000端口 netstat -tlnp | grep ":9000"

如果Nginx正常监听但PHP-FPM没有监听，重启PHP-FPM：

# CentOS/RHEL系列 systemctl start php-fpm # Ubuntu/Debian系列 systemctl start php8.1-fpm

重启后观察是否还会挂掉。如果频繁挂掉，查看PHP-FPM日志（通常在/var/log/php-fpm.log），大概率是慢请求堆积导致进程崩溃，调整pm.max_children和request_terminate_timeout参数。

4.3 伪静态规则错误：白屏、404还是Internal Server Error

伪静态规则也是建站打不开的高频原因之一。你从网上找了个漂亮的主题，附带一套Nginx伪静态规则，复制进去后网站直接502或404。

不同的建站程序有不同的伪静态规则。使用WordPress的话，Nginx伪静态规则必须是：

location / { try_files $uri $uri/ /index.php?$args; }

有些主题要求在Nginx里额外添加一段规则，但很多新手把Apache的.htaccess规则直接硬搬到Nginx里，格式完全不对，自然就报错了。

如果你不确定当前伪静态规则是否正确，最稳妥的办法是先把规则改为最基础的WordPress规则，确认网站能打开后，再逐段追加主题的额外规则，每次追加后刷新页面测试，这样能精确找出哪一段规则引发了问题。

4.4 HTTPS证书过期：不怕你访问，就怕你访问

另一个隐蔽故障是HTTPS证书过期。浏览器会拦截过期证书，显示"您的连接不是私密连接"，很多新手以为是网站挂了，其实是证书到期了。

检查证书到期时间：

echo | openssl s_client -servername 你的域名 -connect 你的域名:443 2>/dev/null | openssl x509 -noout -dates

如果你用的是免费的三个月期证书，记得设置自动续期。如果是通过云服务商申请的证书，在控制台里找到该证书，看是否到期、是否跟当前域名匹配、是否部署到了正确的服务器区域——这三个环节任何一个出错，网站都会打不开。

4.5 数据库连接失败：网站白屏的常见元凶

网站能打开首页，但登录后台或访问文章详情时白屏，这种情况多半是数据库的问题。要么是数据库服务没启动，要么是数据库连接信息错误。

检查数据库服务状态：

systemctl status mysql # 或者 systemctl status mariadb

如果你改过数据库密码，记得同步修改程序配置文件里的数据库连接信息。WordPress的配置文件是wp-config.php，里面有DB_HOST、DB_NAME、DB_USER、DB_PASSWORD四个关键项。曾经遇到过一位朋友改了数据库密码但没改配置文件，前台页面还能打开，后台一登录就报错——这种情况排查起来相当迷惑。

5. 安全组与防火墙：云平台里那道"看不见的门"

5.1 安全组规则：服务器开了门，防火墙又加了一道锁

很多云服务商在服务器之外还有一层"安全组"规则，相当于机房门口的保安。即使你在服务器内部把Nginx配得再好、防火墙全部放行，安全组没放行80和443端口，外部流量依然进不来。

排查方法很简单：在云控制台找到"安全组"或"防火墙"配置，检查入方向规则里有没有放行TCP 80（HTTP）和TCP 443（HTTPS）。很多服务器默认只放行了22端口（SSH登录用），80和443没有放行，这就是为什么FTP能连上、SSH能登录、但网站就是打不开。

我建议的安全组入方向规则只保留必须端口：

5.2 Linux防火墙：firewalld还是ufw，规则别互相冲突

云安全组放行之后，服务器内部还有一层防火墙。CentOS系统用的是firewalld，Ubuntu系统用的是ufw。这两层防火墙只需要配置一层即可，如果你在云控制台安全组已经放行，内部防火墙可以直接关闭，免得两套规则互相冲突，排查时看花了眼。

# CentOS/firewalld systemctl stop firewalld systemctl disable firewalld # Ubuntu/ufw ufw disable

关闭内部防火墙的安全前提是：云平台安全组规则严格控制了端口。如果你用的是物理服务器或者没有安全组机制的VPS，那内部防火墙一定要保留，只放行必要端口。

6. 本地网络与客户端问题：为什么只有你打不开

6.1 浏览器本身：缓存、代理和扩展插件的三重干扰

有时候网站一切正常，服务器状态绿灯，但你的浏览器就是打不开。这时候可以尝试：

• 清理浏览器缓存，尤其是DNS缓存（Chrome地址栏输入chrome://net-internals/#dns点击清空）
• 关闭浏览器代理插件，某些代理插件规则会导致本地请求异常
• 切换到无痕模式访问，排除扩展程序干扰
• 换一个浏览器测试，比如Chrome打不开换Firefox

如果换了浏览器能打开，说明问题出在原浏览器的扩展插件或配置上；如果换了浏览器还是打不开，那问题在网络层面。

6.2 路由器缓存与运营商DNS劫持

家用路由器长期不重启，也会缓存旧的DNS解析结果。建议把路由器和光猫断电重启一次，很多时候本地网络问题就消失了。

另外，某些运营商的DNS服务器解析结果可能滞后或异常。遇到这种情况，可以把电脑的DNS手动改为公共DNS，例如114.114.114.114或8.8.8.8（后者在某些场景不符合国内网络环境，更推荐前者），或者使用国内知名互联网服务商提供的DNS服务，比如阿里云的223.5.5.5。

改DNS的方法：打开网络适配器设置，将"自动获取DNS服务器地址"改为"使用下面的DNS服务器地址"，填入223.5.5.5作为首选，114.114.114.114作为备用，确定后重新打开网站测试。

6.3 手机端测试：排除设备问题的终极方法

前面提到的排查手段都试过之后，还有一个终极测试法：用手机流量访问你的网站，先关闭WiFi，再用4G/5G流量直接访问。

这一步能非常干脆地隔离问题。如果手机流量能打开而WiFi打不开，问题在你的局域网或路由器；如果手机也打不开，问题在服务器或域名解析层面。手机流量访问走的DNS路径和路由器完全不同，这个测试基本能一锤定音判断到底是服务端问题还是本地网络问题。

7. 综合场景实战：一个朋友网站的完整排查记录

这里分享一个我最近帮朋友排查的案例，比较有代表性。朋友的网站部署在云服务器上，域名通过某注册商购买，用的是Nginx加PHP-FPM组合，程序是WordPress。

故障现象：电脑和手机都无法访问网站，Chrome显示"无法访问此网站"。

排查过程：

第一步，我在自己的电脑上ping他的域名，结果显示能够解析出IP地址，说明DNS解析正常。但我试着直接访问该IP地址，同样无法打开——这就排除了DNS层面的问题，把注意力聚焦到服务器上。

第二步，我让朋友登录云控制台检查服务器状态，显示运行中，CPU使用率3%，内存剩1.2G，看起来一切正常。然后用SSH登录服务器，检查Nginx服务状态为running，端口监听也正常。

第三步，检查安全组规则——发现问题了。入方向规则里只有22端口是放行的，80和443端口压根没配。这就是为什么服务器一切正常但网站打不开的直接原因：流量根本到不了服务器。

解决方式：在云控制台安全组中添加放行TCP 80和TCP 443的规则，保存后立即生效，网站在几分钟内恢复了访问。

这个案例的教训很典型：很多人配好了服务器内部环境，却忽略了云平台安全组这道"外部大门"。尤其是拿旧服务器镜像创建新服务器时，安全组配置是独立于服务器镜像的，经常被遗漏。每当"服务器一切正常但网站打不开"时，请优先检查安全组。

还有一个我印象很深的案例。另一位朋友用的宝塔面板管理网站，某天突然发现站点打不开，强制刷新也没用。检查后发现是他在面板里配置了"Cowboy"方式部署，监听端口和应用实际端口不一致，导致请求全部超时。这种面板类工具踩坑也很常见——配置文件里的监听端口、运行目录路径、伪静态规则三项，只要有一项跟实际环境不一致，站点就起不来。遇到面板类站点无法访问时，先检查这三个位置。

8. 最后的速查清单：照着做一定能定位问题

文章写到这里，核心内容都已覆盖。为了让你在遇到"网站打不开"时能快速行动，我把整个排查链路浓缩成一张速查清单，建议收藏：

我个人在实际操作中的体会是：绝大多数"网站打不开"的问题，按这条链路排查能在10分钟内定位。真正困难的不是解决，而是没找对排查顺序、东一榔头西一棒子。把顺序固定下来，每排查一步就在纸上划掉一步，问题很快就水落石出。最后再补充一句——排查时记得保持冷静，很多人在网站打不开的瞬间就焦虑到失去逻辑，但故障排查就像拆线头，一根一根来，总能找到终点。