问题不一定出在服务本身
很多人第一次遇到“服务已经启动，但外部访问不了”时，会马上怀疑程序崩了、端口没开，或者云服务器配置不够。实际排查里，服务进程正常、端口也在监听，但外部请求仍然进不来，是很常见的情况。原因往往不在应用本身，而是在监听地址、防火墙、安全组、反向代理或网络路径中的某一层。
这类问题最容易误导人的地方在于：你在服务器本机执行 curl 127.0.0.1:端口 可能是通的，用 systemctl status 看服务也是 running，于是误以为服务端没有问题。但从用户浏览器、另一台机器或公网访问时，链路会经过更多环节，只看本机结果远远不够。
排查时建议先把问题拆成三段：服务有没有真正监听、服务器本机到端口是否可达、外部网络是否能进入服务器。三段分别验证，比一上来重启服务、改配置、反复清缓存更稳，也更不容易把原本正常的环境改乱。
先确认监听地址和端口
第一步是确认服务到底监听在哪里。常用命令是 ss -lntp，它可以看到 TCP 监听端口、监听地址以及对应进程。比如输出里如果是 127.0.0.1:8080，说明服务只接受本机回环访问，外部机器即使知道服务器公网 IP，也无法直接连到这个端口。如果输出是 0.0.0.0:8080 或指定的内网 / 公网地址，才表示它对对应网卡开放。
很多开发框架默认只绑定 127.0.0.1，本地测试没问题，部署到服务器后就会出现“服务启动成功但外部打不开”。这时不要急着怀疑云厂商或线路，先看应用启动参数、配置文件里的 host/bind/listen 项。例如 Node、Python、Go、Java 的开发服务器，经常需要显式改成 0.0.0.0 或交给 Nginx 做反向代理。
如果服务本来就只应该本机访问，例如数据库、Redis、内部管理端口，那就不要为了“外部能访问”直接绑定公网。更安全的做法是让 Nginx、网关、SSH 隧道或内网访问来承接外部入口。公网暴露越少，后续安全压力越小。
再区分本机可达和外部可达
确认端口监听后，可以在服务器本机分别测试 curl 127.0.0.1:端口、curl 内网IP:端口 和 curl 公网IP:端口。这三个结果的差异非常关键：如果只有 127.0.0.1 通，多半是监听地址问题；如果内网 IP 通但公网 IP 不通，就要继续查防火墙、安全组、NAT 或云平台入口规则；如果本机所有地址都不通，则服务本身或端口映射还没跑起来。
从另一台机器测试时，可以用 curl -v、telnet 或 nc -vz 判断是连接超时、连接被拒绝，还是 HTTP 层返回错误。连接超时通常意味着请求被网络路径、防火墙或安全组丢弃；连接被拒绝通常表示目标主机可达，但该端口没有服务监听或被主动拒绝；如果能连上但返回 403、404、502，则已经进入 Web 或代理层，需要换方向查 Nginx、后端和路由。
做这一步时，最好记录测试来源和目标地址，不要只写“打不开”。来自服务器本机、同机房内网、办公室宽带、手机 4G 的结果可能完全不同。排障记录越清楚，越容易判断问题是在服务器内、云平台边界，还是用户网络侧。
防火墙和安全组要分开看
Linux 主机上的防火墙和云平台安全组不是一回事。主机防火墙通常由 iptables、nftables、firewalld 或 ufw 管理；安全组则在云平台侧控制进入云服务器的流量。一个端口要从公网访问，通常需要两边都放行。只改其中一边，问题可能仍然存在。
在服务器上可以先查看本机规则，例如 firewall-cmd --list-all、ufw status、iptables -S 或 nft list ruleset。如果不熟悉规则含义，不建议直接清空防火墙。更安全的做法是只针对需要的端口添加规则，并保留 SSH 端口可用，避免把自己锁在服务器外面。
云平台安全组则要到控制台检查入方向规则。重点看协议、端口范围、来源 IP 和绑定对象。有时规则看起来放行了 80/443，但应用实际跑在 8080；有时规则放行到某个安全组或内网段，却没有放行公网来源；还有些环境同时有实例安全组、负载均衡安全组和防火墙策略，需要逐层确认。
反向代理会改变排查路径
如果业务前面有 Nginx、Apache、Caddy、宝塔面板、负载均衡或 CDN，外部访问的入口就不一定是应用端口。用户访问 80/443，代理再转发到本机 8080、9000 或 Unix Socket。此时直接开放后端端口未必必要，真正要确认的是代理监听是否正常、域名是否命中正确站点、转发地址是否可达。
Nginx 场景里，可以先执行 nginx -t 检查配置语法，再看站点配置里的 server_name、listen、proxy_pass、证书路径和日志路径。外部访问返回 502 时，重点查 error.log 里的 upstream 报错；返回默认站点或 404 时，重点查 server_name 和站点匹配顺序；HTTPS 正常但 HTTP 不正常，则看 80 端口监听和跳转规则。
如果业务部署在 速维云香港服务器线路 或其他海外节点上，还要区分“代理配置错误”和“跨地区链路体验不好”。例如管理后台、API 服务、下载站点对延迟和连接稳定性的感知不同，选线路时不能只看机房地区，还要看回国线路、带宽峰值、晚高峰表现和业务访问人群。
用日志和抓包确认请求有没有到达
当你不确定请求卡在哪一层时，日志是最直接的证据。访问 Nginx 时，先看 access.log 有没有对应请求。如果 access.log 没有记录，说明请求还没到 Web 服务，方向应转向 DNS、CDN、安全组、负载均衡或主机防火墙。如果 access.log 有记录但状态码异常，再结合 error.log 查代理、权限、文件路径或后端响应。
应用服务也要看自己的日志。很多后端服务在启动时会打印监听地址、端口、环境变量和路由信息。外部请求如果进入了应用，日志里通常能看到请求路径、状态码或异常堆栈；如果完全没有记录，说明问题仍在应用前面的网络或代理层。
必要时可以用 tcpdump 做确认，例如在服务器上临时抓目标端口流量，判断外部请求是否真的到达网卡。抓包不适合长期打开，也不要随意保存敏感业务数据，但在“安全组说放了、防火墙说通了、服务说正常”的僵局里，它能快速把问题边界缩小。
按顺序处理，避免越修越乱
这类问题最忌讳同时改很多地方：一边改应用监听，一边清防火墙，一边重载 Nginx，一边改安全组。最后即使恢复了，也很难知道真正原因是什么。推荐顺序是：确认进程和监听端口，验证本机访问，验证内网 / 公网访问，检查本机防火墙，检查云平台安全组，检查反向代理，最后再看 DNS、CDN 和线路。
如果是生产环境，修改前要先记录当前配置，必要时备份 Nginx 站点文件、防火墙规则和应用配置。重载服务优先于重启机器，短时间内能回滚的改动优先于大范围改动。SSH、防火墙、安全组相关操作尤其要谨慎，避免为了开放一个业务端口，把远程管理入口也一起影响了。
总结下来，“服务启动了但外部访问不了”并不是一个单点故障，而是一条链路问题。只要按监听地址、本机可达、外部入口、防火墙 / 安全组、反向代理、日志证据这个顺序走，大多数场景都能定位到明确原因。定位清楚之后再修，比靠重启和猜配置靠谱得多。
