云服务器明明已经放行22端口，连接却仍然超时；控制台显示安全组无异常，浏览器却打不开网站，这类问题的共同点是：“允许”只代表某一层的配置意图，不代表整条访问链路已经打通。请求还要穿过云安全组、主机防火墙、服务监听地址和连接跟踪状态，任何一层出现偏差，都可能表现为“端口不可达”。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：liteserver（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
第一层是云安全组。它通常按照源地址、目标端口和协议决定报文能否进入实例。排查时不能只看“入方向已放行”，还要确认规则方向、协议类型、源地址范围以及规则优先级是否正确。例如放行TCP 22，却没有放行ICMP或TCP回应报文，现象可能与预期不同。
第二层是主机的nftables规则链。即使云端允许，内核里的input、forward、output链仍可能继续丢弃数据包。规则中的端口、接口、源地址和策略要逐项对应，尤其注意默认拒绝策略、链跳转关系，以及Docker、虚拟网卡等场景下是否命中了不同链。
第三层是服务监听地址。服务进程启动不等于对外监听：监听127.0.0.1的Web服务只接受本机请求，监听0.0.0.0才会覆盖所有IPv4地址；只监听IPv6时，IPv4客户端也可能连接失败。
第四层是连接跟踪状态。有状态防火墙会根据连接表判断报文属于新建连接、已建立连接，还是异常或失效流量。只允许入站新连接、却误伤回程报文时，外部看到的往往仍是超时。
>
先从外部执行TCP端口测试，确认是“拒绝”还是“超时”。快速拒绝通常指向云安全组或主机防火墙明确丢弃；持续超时则要继续检查服务是否启动、监听地址是否正确，以及上游网络是否可达。若22端口拒绝而Web端口可连接，问题多半在服务自身或端口对应规则。
进入服务器后，用ss或netstat查看进程是否真的监听目标端口，再核对监听地址。服务只绑定127.0.0.1时，即使防火墙完全放行，外部请求也无法抵达。随后检查nftables规则计数、策略和连接跟踪表，观察报文是否进入input链、是否被丢弃，以及同一连接的回程流量是否处于正常状态。
最后同时查看云侧流量日志、系统防火墙日志和服务访问日志。云安全组没有命中记录，说明请求可能未到实例；主机日志出现DROP，重点修正nftables规则链；服务没有访问记录，则应优先检查监听地址校验与进程状态。不要为了排障直接关闭全部防火墙，修复后应按最小权限放行，只开放必要端口和来源范围。
ServLlama这类集中日志与连接分析工具，可帮助把云侧记录、主机规则和访问日志放在同一时间线上比对，适合在多实例环境中减少反复切换窗口的排查成本。
云安全组放行后，报文仍可能在主机侧经过nftables规则链。普通公网服务进入input链，容器、VPN或转发流量则可能走forward链。若默认策略是丢弃，或前面已有拒绝规则，后面的accept永远不会命中；应同时检查策略、规则顺序和计数器。
连接跟踪状态影响长连接与回包。通常先允许established,related，再仅对业务端口放行new，既避免误杀回包，也不破坏最小权限放行。还要确认生效的是nftables、ufw还是firewalld，多套管理工具并存时可能互相覆盖规则。
用ss -lntp校验监听地址：127.0.0.1只供本机访问，0.0.0.0覆盖全部IPv4；若绑定私网IP，还要核对公网映射、路由和多网卡。IPv6需单独放行。安全组开放TCP 443而服务监听UDP 443，也会出现“端口已开但连不上”。
可执行检查清单：①确认云安全组绑定的是当前实例，协议、端口、来源网段正确；②执行sudo nft -a list ruleset，查看input或forward的最终策略、序号和计数；③执行ss -lntp，核对进程、协议、监听地址；④本机运行curl -I http://127.0.0.1:端口，验证应用；⑤执行sudo tcpdump -ni any 'tcp port 端口'，观察SYN。
抓包无请求，先查云安全组、云防火墙及上游网络；有SYN却无响应，再查nftables规则链和监听地址。最后只开放必要协议、端口与可信来源，删除宽泛规则；修改后从外网复测，并观察命中计数和系统日志，才能确认“已放行”与“实际可达”一致。
