先确认是不是端口没起来
新站部署完成后，最常见的一类现象是：服务器能登录，程序也已经上传，但浏览器访问域名或 IP 时没有响应。很多人第一反应是“服务器坏了”或“域名没解析”，其实更应该先确认服务端口有没有真正监听。网站访问本质上是浏览器连接服务器的 80、443 或自定义端口，如果 Nginx、Apache、Node.js、Java 服务没有启动，外部再怎么刷新也不会有结果。
在 Linux 服务器上，可以先用 ss -lntp 查看当前监听端口。正常情况下，Web 服务至少应看到 80 或 443 处于 LISTEN 状态；如果是后端应用，还要确认应用端口是否存在。例如 Node.js 项目常见 3000、8000、8080，Java 项目可能是 8080、9000，具体取决于配置。只看到 SSH 的 22 端口，通常说明网站服务本身还没起来。
如果端口没有监听，下一步才是检查服务状态。Nginx 可以用 systemctl status nginx，Apache 常见 systemctl status apache2 或 httpd，自定义应用则要看对应的 systemd 服务、PM2、Supervisor 或容器状态。这个阶段不要急着改 DNS，也不要反复重启服务器，先把“服务有没有在本机运行”这件事查清楚。
再看防火墙和安全组
端口已经监听，不代表外部一定能访问。服务器内部监听成功，只说明程序在本机等待连接；外部访问还要经过系统防火墙、云厂商安全组、机房策略、CDN 或高防转发等多层入口。排查时要把“本机可访问”和“公网可访问”分开看。
可以先在服务器本机执行 curl -I http://127.0.0.1 或 curl -I http://服务器内网IP。如果本机返回正常，但外部浏览器打不开，问题大概率在防火墙、安全组或公网入口。如果本机也访问失败，说明仍然要回到 Web 服务配置、站点目录、反向代理或应用本身。
系统防火墙常见工具包括 firewalld、ufw 和 iptables。比如 firewalld 可用 firewall-cmd --list-all 查看开放端口，ufw 可用 ufw status 查看规则。云服务器还要登录控制台检查安全组，确认入站规则允许 80、443 或业务端口。这里容易犯的错是：服务器系统里已经放行端口，但云安全组没有放；或者安全组放了 80，实际服务跑在 8080。
如果业务面向公网，建议只开放确实需要的端口。SSH、数据库、Redis、管理后台等入口不应随意暴露给全网。对外提供网站服务时，通常只开放 80 和 443；后台管理、数据库连接可以通过内网、VPN、堡垒机或固定 IP 白名单处理。这样既方便排障，也能降低被扫描和爆破的风险。
区分 连接失败、超时和拒绝
浏览器里一句“打不开”太粗糙，排障时需要把错误类型拆开。连接被拒绝通常意味着目标 IP 可达，但目标端口没有服务监听，或者防火墙明确拒绝；连接超时更像是网络链路中某一层丢弃了请求，例如安全组没放行、路由不通或被策略拦截；返回 502、503 则说明 Web 入口存在，但后端应用或上游服务异常。
可以在本地电脑使用 curl -v、telnet 域名 端口 或 nc -vz 域名 端口 做简单确认。Windows 用户也可以用 PowerShell 的 Test-NetConnection 域名 -Port 443。这些命令不需要理解所有底层细节，只要观察是否能建立 TCP 连接，就能快速判断问题是“连不上端口”还是“连上后应用返回错误”。
如果使用 CDN 或高防，还要分别测试源站和加速域名。CDN 域名异常不一定代表源站坏了，源站正常也不代表 CDN 回源配置正确。可以临时用 hosts 指向源站 IP 做验证，也可以在 CDN 控制台查看回源协议、回源端口、证书配置和健康检查状态。排查顺序建议先源站，再 CDN，最后再看浏览器缓存和 DNS 缓存。
检查 Web 服务配置是否指向正确站点
端口开放后，仍然可能因为 Web 配置错误导致访问异常。Nginx 里常见问题包括 server_name 写错、root 目录指错、反向代理 upstream 配错、HTTPS 证书路径错误、默认站点抢占请求等。Apache 里则常见虚拟主机未启用、DocumentRoot 错误、重写规则导致循环跳转。
排查配置时，不建议上来就大改。先执行配置检查，例如 nginx -t 或 apachectl configtest。如果语法正确，再查看当前站点配置文件，确认域名、监听端口、证书路径、站点目录和反向代理地址是否一致。尤其是多站点服务器，A 域名访问到了 B 站点目录并不少见。
日志是最直接的证据。Nginx 通常查看 /var/log/nginx/access.log 和 error.log，Apache 查看对应的 access/error 日志，应用服务也要看自己的运行日志。如果访问请求完全没有进入 access.log，问题多半在 Web 服务之前；如果进入了但返回 404、500、502，就顺着状态码继续查站点目录、程序错误或后端连接。
别忽略域名解析和协议跳转
如果直接访问 IP 正常，访问域名异常，就要重点看 DNS 解析。常见问题包括 A 记录指向旧 IP、CNAME 指向错误、解析线路不一致、域名刚修改还在生效中、IPv6 记录优先但服务器没有配置 IPv6 服务。可以使用 dig 域名、nslookup 域名 或在线 DNS 工具，从不同地区确认解析结果。
HTTPS 也是新站上线时的高频坑。证书没有部署、证书域名不匹配、强制 HTTPS 但 443 未开放、反向代理只配了 80、CDN 使用 HTTPS 回源但源站证书异常，都会让用户觉得“网站打不开”。如果 HTTP 正常而 HTTPS 异常，排查重点应放在 443 监听、证书链、Nginx SSL 配置和 CDN SSL 模式。
还有一种情况是跳转链配置不合理。比如 HTTP 跳 HTTPS，HTTPS 又跳回 HTTP；裸域跳 www，www 又跳裸域；后台配置了错误站点 URL，导致登录页循环跳转。用 curl -I -L 域名 可以看到每一步跳转，定位比只看浏览器直观得多。
形成固定排查顺序
端口不通的问题最怕乱查。建议固定顺序：先确认服务是否启动，再确认本机端口监听，再确认本机 curl，再确认系统防火墙，再确认云安全组，再确认公网连通性，最后看 DNS、CDN、证书和应用日志。每一步只回答一个问题，避免同时改很多配置，导致问题被掩盖。
如果是生产环境，排查前最好先记录当前配置和关键命令输出。修改防火墙、安全组、Nginx 配置或证书前，先备份原文件。需要重启服务时，优先使用 reload；必须 restart 时，也要确认业务低峰或有回滚方案。服务器运维不是靠运气试出来的，而是靠证据一步步缩小范围。
对于不想自己维护底层环境的站点，可以选择带基础运维支持的云服务器方案。例如速维云的 云服务器与服务器产品 更适合需要稳定建站、部署业务和后续扩容的用户；如果只是企业官网、活动页或中小型业务，提前把端口、安全组、证书和备份流程梳理好，后续排障会轻松很多。
