先确认失败发生在连接的哪一步
域名已经返回预期地址，只能说明名称查询得到了结果。浏览器接下来还要建立连接、协商加密并请求网站内容，这些步骤各自可能失败。排查时先保存完整访问地址，区分超时、连接拒绝、证书错误和 HTTP 错误响应。不要把它们统一归成服务器没开端口，也不要立即放行所有入站流量。本文以公开网站入口和仅监听回环地址的应用为例，沿访问链逐层检查；具体命令使用演示域名和端口，不对应真实服务器配置。
可以使用 curl 的详细输出观察解析结果、连接目标与握手阶段，同时给请求设置超时。命令返回码和响应状态需要一起记录，尤其是收到重定向以后，最终目标可能已经变成另一个地址。分享日志时去除认证头和会话信息。连接拒绝通常意味着路径上存在明确拒绝或没有可接受连接的服务，超时则有更多可能原因；它们都不能凭一条结果确定故障位置。下一步需要本机与外部请求对照，让判断建立在观察之上。
画出实际访问链而不是想象中的链
普通部署可以拆成访问者、云网络入口、主机防火墙、反向代理和应用进程。若还有负载均衡或内容分发，应把它们加入链条，并明确 DNS 指向的是哪一个入口。应用内部监听的端口未必直接向公网开放，代理负责把标准网站端口的请求转发到它。只检查应用端口可用，不能证明外部访问已经完整；反过来，标准端口有服务回应，也不能证明它转发到了正确的应用。先写出链条有助于避免跨层修改。
对每一跳记录协议、目标地址和端口。例如代理接收 HTTPS，再向回环地址的 HTTP 应用发送请求；这种情况下上游协议若写成 HTTPS，可能产生另一种连接错误。还应区分 IPv4 与 IPv6，域名有多个地址时，不同访问者可能沿不同路径到达。当前网络只验证了一个地址族，应明确说明测试范围。部署图不必复杂，只要能指明每条连接由谁发起、连向哪里，以及哪一层承担站点选择即可。
先在服务器本机验证应用
登录服务器以后，查看应用服务状态和近期日志，再向配置中使用的本机地址发起健康检查。这个请求绕过公网安全组和代理，可以快速确认应用进程是否提供响应。健康入口应只返回必要信息，避免暴露配置和内部异常细节。若本机请求失败，应先解决进程启动、端口或应用依赖问题；继续修改云安全组不会使一个没有运行的应用自动可用。若应用健康但具体页面失败，还需要检查对应路由与数据库等业务依赖。
服务状态显示 active 也不等于 HTTP 已经可以响应。某些服务管理方式在进程刚启动时就认为服务已启动，应用仍可能处于初始化或已进入异常状态。应实际请求健康入口，并保留时间与退出码。对容器应用，还需要检查容器内部监听及端口映射，而原生 systemd 应用则查看服务单元中的启动参数。不要混用两种部署的检查路径，也不要因为主机上安装了 Docker 就推定这个网站一定由容器运行。
监听地址决定哪些连接可以进入
用 ss 查看监听端口时，注意地址列而不只是端口数字。仅监听回环地址的应用，通常只能由本机连接，这适合放在反向代理后面。若代理与应用位于不同机器或不同网络命名空间，就不能直接沿用同一回环目标。监听全部接口会扩大访问范围，但不是修复所有代理问题的必要动作。应先确认代理的实际连接位置，再决定应用需要监听哪些地址，并保持内部服务的暴露范围与部署设计一致。
IPv6 的监听表现还取决于系统与应用设置，不能仅从一个通配地址推断两个地址族都已可用。可以分别用明确地址发起本机请求，核对服务接受情况。发现端口由其他进程占用时，记录进程身份与来源，确认是否是旧服务或另一个站点，再选择处理方式。不要直接结束陌生进程来抢占端口；共享服务器上的其他业务可能使用它。监听检查的目标是解释当前连接去了哪里，然后进行有范围的配置修正。
单独检查反向代理入口
应用本机健康以后，检查代理服务状态和完整配置。使用保留目标主机名的本机请求，可以验证站点匹配、证书和上游转发。直接访问回环 IP 可能落到默认站点，不能替代域名测试。代理收到请求却返回上游错误时，应沿其日志检查目标地址、协议和连接状态。日志中的上游错误与应用自己返回的错误需要区分，否则可能在应用已经收到请求时仍去修改安全组，或者在代理根本连不到应用时只检查业务路由。
多站点配置还应确认目标名称没有落到另一个站点，并核对完整导入结果。代理配置校验通过，只能证明配置在相应工具下有效，实际运行是否加载了它需要再次请求验证。修改以后按产品支持的方法加载，再查看日志和服务状态。不要为了让一个站点可用而覆盖其他站点的入口文件。若代理使用自动证书，还要确认验证端口与持久化目录可用；这属于入口准备的一部分，但应按证书日志单独定位，避免不停重启造成额外干扰。
主机防火墙与云安全组分别核对
主机上的防火墙和云平台安全组是两层不同控制。服务器本机请求成功，不能说明外部流量通过了它们。先读取当前主机规则，再在云控制台核对实例实际关联的安全组及入方向规则。公开网站通常需要其采用的标准入口端口，内部应用和数据库不应为了排查全部向公网开放。规则中还包含协议与来源范围，只看到端口数字相同并不足够；某条规则可能仅允许特定网络来源，或者关联的并不是目标实例。
修改应针对已经确定的入口，保留原规则和管理连接的可用性。不要使用关闭整个防火墙作为长期修复，也不要一次添加所有常见开发端口。云网络还可能存在其他访问控制与负载均衡规则，遇到复杂环境应继续扩展链条。外部测试失败时，也要核对访问者自己的网络限制。安全组控制台显示允许，并不能直接证明请求已到达进程；只有与监听、代理日志和外部请求对照，才能说明哪一层仍需调查。
从外部网络进行最后对照
完成本机检查以后，从服务器之外的普通网络请求域名。分别记录 DNS 地址、连接阶段、状态码和正文关键内容。可以比较 IPv4 与 IPv6 请求，观察不同地址族是否进入预期站点。临时固定地址的测试适合定位入口，但交付前还要使用正常解析路径。不要把服务器请求自己的公网地址成功作为全部外部网络都可用的证据，它可能经过不同路由。至少应说明测试位置和连接条件，让结果能够被复核。
如果外部请求没有出现在代理日志中，可以继续调查入口和前置网络；若日志已经记录请求，再沿响应和上游检查。日志可能被过滤或采用其他输出方式，因此没有日志本身也需要先确认记录配置。对间歇问题，保存时间窗口并关联服务日志，避免拿不同时间的成功与失败比较。没有执行的检查不要补写成成功，尤其不要编造端口扫描结果或网络延迟。排查记录可以保留未知项，明确下一步读取哪一层信息即可。
处理恢复与后续监控
修复以后，验证首页、一个业务路由和必要资源，而不只是健康接口。网站入口可能正常，封面、上传资源或子域名跳转仍有错误。还应确认代理与应用在重启之后能按预期启动，配置文件权限和服务环境没有依赖当前交互终端。监控可以分别观察应用健康和公开入口：前者帮助发现进程或依赖异常，后者帮助发现代理与外部可达问题。两个信号承担不同职责，保留区分有助于减少后续告警中的猜测。
变更记录应说明调整了哪个监听或哪条规则，以及验证覆盖了什么。若采用临时诊断措施，恢复到原先约定的暴露范围，并核对没有遗留不必要端口。本文的单机步骤不能替代复杂云网络的路由调查，但能够提供一个稳定起点：先证明应用本机可响应，再证明代理能正确转发，最后证明外部流量到达入口。每一步都缩小一个范围，网站不通就能落到具体连接与配置，而不再依赖全面放行来试运气。
实现片段
# 示例：应用仅供本机代理连接
systemctl status demo-app --no-pager
ss -ltnp
curl --fail --show-error --max-time 10 http://127.0.0.1:3000/api/health
# 在服务器本机保留主机名，验证代理与 TLS
curl --fail --show-error --max-time 15 \
--resolve blog.example.com:443:127.0.0.1 https://blog.example.com/api/health
# 外部机器再使用正常解析路径
curl --verbose --max-time 15 https://blog.example.com/
# 规则检查使用当前发行版的防火墙工具，不在此批量放行
评论 · 0