先判断“连不上”指什么

能 ping 通日本服务器，不代表业务端口可用；ping 使用的协议与网页、数据库等服务的 TCP 或 UDP 端口不同。反过来，ping 不通也不能直接证明端口故障：服务器可能禁用了 ICMP，但仍接受业务连接。排查时先确认目标公网 IP、端口号、TCP/UDP 类型和客户端所在网络，并记录报错是“连接被拒绝”还是“超时”。

建议按低风险到高风险的顺序检查：先从客户端验证目标和端口，再确认服务器是否监听、应用是否绑定正确地址，然后依次核对主机防火墙、云平台安全组、NAT 或端口映射。每改一处就重新测试一次，避免同时调整多层规则，导致无法判断真正原因。

第一步：确认目标地址、端口和协议

核对客户端使用的地址是否为日本服务器当前对外提供服务的公网 IP，端口是否与应用实际配置一致。域名解析结果也要确认：域名可能指向旧地址，或者解析到了与预期不同的 IPv4、IPv6 地址。

TCP 和 UDP 不能混为一谈。网页、SSH 等常见服务通常使用 TCP；语音、实时通信等应用可能使用 UDP，也可能同时依赖多个端口。仅测试 TCP 成功，不能证明 UDP 服务正常。

在 Windows 客户端上，可用 PowerShell 检查 TCP 连接：

Test-NetConnection -ComputerName 203.0.113.10 -Port 443 -InformationLevel Detailed

将示例地址和端口替换为实际目标。TcpTestSucceeded : True 表示这次 TCP 握手成功，不代表应用功能一定正常；结果为 False 时，再结合服务器侧检查定位原因。若通过域名访问，也可以先检查解析结果：

Resolve-DnsName example.com

常见现象可作初步判断，但不能单独作为结论：

第二步：确认服务器确实在监听

在 Linux 服务器上，先查询目标端口的监听情况：

sudo ss -lntp
sudo ss -lnup

-t 查看 TCP，-u 查看 UDP，-l 仅显示监听项，-p 尝试显示关联进程。若只关心某个 TCP 端口，例如 443：

sudo ss -lntp 'sport = :443'

若命令没有输出，通常表示当前没有进程监听该端口。此时应检查应用是否启动、是否启动失败，以及应用配置中的端口是否与客户端访问的端口一致。可通过系统服务状态和应用日志确认原因；服务名称由实际安装的软件决定，不要直接照搬示例名称。

如果有监听记录，重点看本地地址：

• 127.0.0.1:443：仅接受本机回环地址上的连接，外部设备通常无法直接连接。
• 0.0.0.0:443：监听所有 IPv4 网卡地址，但仍可能被防火墙或上游规则拦截。
• [::]:443：表示 IPv6 通配监听；是否同时接受 IPv4 连接，取决于系统和应用设置，不能仅凭这一项推断。
• 某个具体内网地址：应用只绑定在该地址上。若公网流量经 NAT 转发到另一个内网地址，绑定地址不匹配也会导致连接失败。

若服务器使用 Windows，可在管理员 PowerShell 中查询 TCP 监听端口：

Get-NetTCPConnection -State Listen -LocalPort 443

如果没有结果，检查应用服务状态及其监听配置；如果有结果，可进一步根据 OwningProcess 查看对应进程。TCP 和 UDP 的监听检查方式不同，不能用 TCP 查询结果判断 UDP 服务状态。

第三步：检查应用绑定与本机连通性

监听端口存在，不代表应用绑定正确或服务可正常处理请求。确认应用配置的地址、端口和协议与实际访问方式一致，尤其注意应用是否只绑定在 localhost 或 127.0.0.1。修改绑定地址可能使服务暴露到更多网卡，应先确认访问范围，并按实际需要限制来源。

在服务器本机测试 TCP 端口，可以帮助区分应用问题与外部网络问题：

nc -vz 127.0.0.1 443

若应用绑定在某个服务器地址，也应测试该地址：

nc -vz 192.0.2.10 443

nc 未安装时，不要为了单次检测随意安装来源不明的软件；可使用系统已有的网络诊断工具，或根据发行版的包管理方式确认是否安装。若本机回环测试失败，优先检查应用状态、端口配置和本机安全规则；若回环成功而外部失败，继续检查监听地址和网络过滤层。

如果应用运行在容器中，还要核对容器端口是否发布到宿主机，以及发布地址是否限制在回环接口。容器内服务监听正常，并不自动意味着宿主机公网端口已开放；应分别检查容器内监听、宿主机端口映射和宿主机防火墙。

第四步：检查日本服务器的主机防火墙

先识别服务器实际使用的防火墙管理工具和规则，不要在未确认环境时混用命令。查看规则通常比直接修改安全得多。

使用 UFW 的系统可先检查状态和规则：

sudo ufw status verbose

使用 firewalld 的系统可查看运行状态、活动区域和已开放端口：

sudo firewall-cmd --state
sudo firewall-cmd --get-active-zones
sudo firewall-cmd --list-all

也可以检查当前内核规则，但输出较长，且不同系统的规则管理方式可能不同：

sudo nft list ruleset

重点核对规则是否匹配正确的协议、目标端口、网卡或来源地址。仅看到某端口出现在规则里，还要确认规则所在区域或链确实适用于接收流量的接口，并检查是否存在更早执行的拒绝规则。

需要放行时，应先备份当前配置或记录现有规则，确认影响范围，再只增加所需端口和协议，尽量限制允许访问的来源地址。不要为了排查而关闭整台服务器的防火墙，也不要无差别开放所有端口。

例如，只有在确认系统使用 UFW、业务确实需要 TCP 443，且允许来源符合安全要求时，才考虑添加规则：

sudo ufw allow from 198.51.100.25 to any port 443 proto tcp

以上命令仅允许示例来源地址访问，不应原样套用。调整前保存现有规则状态；若结果不符合预期，可按实际规则编号删除刚添加的规则：

sudo ufw status numbered
sudo ufw delete <规则编号>

删除编号前再次核对规则内容，避免移除其他业务规则。若服务器使用 firewalld，应依据实际活动区域配置，并在变更前保存现有规则；永久规则与当前运行规则可能不同。没有把握时先由管理人员确认规则管理方式，不要直接复制其他发行版的命令。

第五步：核对云平台安全组或网络访问规则

日本服务器即使本机正在监听，云平台侧的安全组、网络访问控制列表或实例防护规则仍可能拦截入站流量。登录实例所在平台的管理界面，确认规则应用到了正确实例或网卡，并逐项核对：

• 入站方向，而非仅出站方向；
• 目标端口和 TCP/UDP 协议与应用一致；
• 来源地址范围包含当前客户端出口地址，或符合业务所需范围；
• 规则处于启用状态，且没有更高优先级的拒绝规则；
• 访问的是规则所关联的公网 IP 和实例。

安全组调整也属于对外开放范围变更。修改前记录原规则，新增时优先限定来源；验证失败或出现非预期访问后，删除本次新增规则并恢复原状态。不要为了快速测试长期使用全网可访问的宽泛规则。

第六步：检查 NAT、端口映射与公网地址

如果应用部署在内网地址后面，外部连接需要经过正确的端口映射：公网地址上的目标端口应转发到正确的内网主机、内网端口和协议。常见错误包括公网端口与内网端口填反、映射协议选错、目标内网地址已变化，或映射指向了另一台设备。

还要确认客户端连接的公网 IP 确实属于该服务器或其前置网关。若实例只有内网地址，不能仅凭服务器本机存在监听就推断外网可访问；需检查平台提供的公网地址绑定方式或上游网络设备的映射配置。若流量经过多层 NAT，每一层都需要有匹配的转发规则。

NAT 场景下可按顺序验证：先从服务器本机连接应用端口，再从同一内网的另一台设备连接服务器内网地址，最后从外部网络连接公网地址。第一步失败多指向应用或本机问题；内网可通而外部不通时，重点转向公网映射、安全组和上游防火墙。内网设备从内网访问公网地址的结果可能受网关配置影响，不能代替真正的外部测试。

第七步：结合抓包判断数据停在哪一层

前述检查仍无法定位时，可在服务器上观察目标端口是否收到连接请求。Linux 可使用 tcpdump，前提是系统已安装并允许管理员执行抓包：

sudo tcpdump -ni any 'tcp port 443'

命令只观察流量，不应在未授权的服务器上抓取数据。按实际端口和协议修改过滤条件，并避免将抓包文件或输出中的敏感信息公开。

• 客户端发起连接时服务器完全看不到相关数据：优先检查目标 IP、路由、安全组、上游防火墙及 NAT。
• 能看到客户端发来的 TCP SYN，但服务器没有正常回应：检查主机防火墙、监听地址和系统网络规则。
• 能看到连接建立，但应用没有正确响应：重点查看应用日志、应用协议和后端处理。
• 服务器发出回应，但客户端仍超时：检查返回路径、上游过滤及客户端网络环境是否允许响应返回。

抓包只能说明数据包在观察点的表现，不一定能直接指出是哪台设备丢弃了流量。应与客户端测试时间、服务器日志和规则变更记录对应分析。

修复后怎样确认问题已解决

每次只调整一个层面的规则或配置，随后从原客户端重新测试目标地址、端口和协议；必要时再从另一网络进行对照。TCP 端口可再次运行 Test-NetConnection，并确认服务器端能看到连接、应用日志中出现对应请求。若服务需要应用层请求，还要实际访问对应功能，而不只看端口握手成功。

UDP 不存在与 TCP 相同的握手过程，单次端口探测结果不能可靠证明服务正常。应使用应用自身的健康检查、客户端实际请求和服务器日志交叉验证。若端口只能在某个来源网络访问，需进一步核对安全组与主机规则的来源范围；若修改规则后故障仍在，也应撤回无效变更，避免留下不必要的开放端口。

端口排查的判断边界很重要：监听成功只说明本机有进程接收，主机防火墙放行只说明本机规则允许，安全组放行也不代表应用已可用。只有目标地址、监听与绑定、各层过滤、必要的映射以及应用响应都与实际访问路径一致，才能确认连接问题已经解决。