东北亚用户访问日本服务器上的业务端口时，可能遇到连接超时、立即拒绝，或只有部分用户无法访问。相同的“端口不通”表象，可能来自服务未监听、监听地址不对、主机防火墙或云安全组拦截，也可能是公网入口到服务器之间的 NAT 转发不匹配。先确认哪些用户、通过什么地址和协议访问失败，再根据服务器是否收到请求逐层缩小范围；不要仅凭一次超时就直接开放所有端口。

建议按以下顺序排查：核对用户访问的地址、端口和协议；检查服务器是否有对应监听；分别核实主机防火墙和云平台安全组；确认公网入口经过 NAT 时转发目标正确；最后结合应用配置和日志检查绑定与处理状态。通常，本机连接成功但外部失败，应优先检查入站规则和转发路径；本机连接也失败，则先检查服务状态、监听和应用配置。每一步都应记录测试结果，避免把多个配置同时改动后无法判断根因。

先界定失败范围：地址、端口、协议和报错

开始操作前，记录用户实际使用的域名或公网 IP、端口、TCP 或 UDP 协议、失败时间，以及报错内容。还要确认该地址确实指向当前日本服务器的公网入口；如果域名解析到了其他地址，检查服务器本身的端口并不能解释用户访问失败。

不同报错只能提供排查线索，不能单独确定根因：

• 连接被拒绝：常见于目标地址可达但没有服务接受该端口连接，也可能是中间设备主动拒绝。先确认服务监听和监听地址，再检查拒绝规则。
• 连接超时：可能是数据包被防火墙、安全组或转发设备丢弃，也可能是访问地址不正确。需要结合服务器抓包、规则和其他来源的测试判断。
• 域名无法解析或解析地址异常：先核对域名解析结果与预期公网入口是否一致。此时还不能据此判断端口是否开放。
• 只有部分用户失败：记录失败用户的公网出口地址、网络环境和测试时间，并请其在条件允许时用另一种独立网络复测。若失败仅集中在特定来源，检查规则的来源范围；不能仅凭用户所在地区直接断定是服务器或线路问题。

协议也必须匹配。TCP 有连接建立过程，可通过连接测试和抓包观察；UDP 没有相同的握手过程，客户端超时不能单独证明端口关闭，应结合服务器侧数据包和应用日志判断。非标准端口还需确认客户端填写的端口与应用实际配置完全一致。

第一步：从外部确认请求有没有到达服务器

若服务端口本机测试正常、外部仍无法访问，可以在复测同时观察服务器网卡是否收到对应请求。以下命令适用于常见 Linux 系统，要求服务器已安装 tcpdump；它只观察数据包，不修改网络规则。把示例端口替换为实际端口：

sudo tcpdump -ni any 'tcp port 8443'

让失败用户在记录的时间重新测试，并观察输出：

• 能看到来自用户侧的 TCP 请求：流量至少到达了服务器网卡。接下来检查主机防火墙、监听地址、服务响应和返回流量。
• 看不到请求：不能立即认定是云安全组问题。先核对抓包接口、端口、协议和测试时间，再检查公网地址指向、云安全组及 NAT 转发路径。
• 能看到请求但没有正常建立连接：结合监听状态和主机规则继续定位；如果服务已监听且规则允许，再检查应用日志及返回方向是否正常。

抓包只能证明观察接口上是否出现符合过滤条件的数据包，不能单独证明所有上游设备的状态。抓包内容可能包含来源地址等网络信息，应限制命令执行权限，不要无必要地长期保存输出。若故障涉及 UDP，应将过滤条件改为相应 UDP 端口，例如 udp port 8443，并结合应用侧日志判断是否收到和处理请求。

第二步：确认目标端口是否正在监听

以下命令适用于常见 Linux 系统。第一条查看 TCP 监听，第二条查看 UDP 监听：

sudo ss -lntp
sudo ss -lnup

检查输出中的端口、本地地址和进程信息。若需查看示例端口 8443，可使用：

sudo ss -lntp | grep ':8443'
sudo ss -lnup | grep ':8443'

重点按本地地址判断：

• 127.0.0.1:8443：只监听本机回环地址。服务器本机访问可能成功，但外部用户通常无法直接连接。
• 0.0.0.0:8443：监听所有 IPv4 网卡地址；这只说明存在 IPv4 监听，不代表防火墙、安全组或公网路径已经放行。
• [::]:8443：监听 IPv6 通配地址。它是否同时接受 IPv4 连接，取决于系统设置和应用行为，不能只凭这一项认定 IPv4 可用。
• 没有目标端口记录：当前未发现相应监听。检查服务是否启动、实际端口与协议是否一致，以及应用是否因配置错误启动失败。

如果服务由 systemd 管理，可查看状态和近期日志。将示例服务名替换为实际服务名称：

sudo systemctl status example.service --no-pager
sudo journalctl -u example.service -n 100 --no-pager

如果服务未运行或反复退出，先根据日志处理启动错误，再复查监听。防火墙放行规则不会自动启动服务；没有进程监听时，单纯开放端口不能解决问题。

第三步：核对应用绑定，并做本机连接测试

端口有监听仍不代表应用能从预期入口接收连接。检查应用配置中的监听地址、端口和协议是否与部署方式一致。若应用仅绑定 127.0.0.1，外部用户通常无法直接通过服务器网卡访问；如需调整，应根据实际网络结构选择适当的绑定地址，并避免将仅供管理使用的端口暴露给不需要访问的来源。

可以先测试服务器本机回环地址：

nc -vz 127.0.0.1 8443

若服务应监听某个服务器内网地址，也可测试该地址：

nc -vz 服务器内网地址 8443

这两条命令用于 TCP 连接测试，不适用于判断 UDP 服务是否正常。结果可按以下方式解释：

• 回环地址成功，内网地址失败：优先检查应用是否只绑定回环地址，或是否绑定了错误的网卡地址。
• 两种本机测试都失败：检查服务状态、实际端口、协议、应用配置和日志；同时确认测试地址确实是服务预期监听的地址。
• 本机测试成功，外部失败：说明本机路径上有进程接受 TCP 连接，但不能证明公网可达。继续核对入站规则、云安全组和 NAT。

修改应用配置前先备份原配置，并记录原监听地址和端口。一次只修改必要项，避免同时改变绑定范围、端口和访问控制。按服务支持的方式重载或重启后，复查服务状态与 ss 输出；如果配置错误导致服务无法启动，恢复备份并重新启动服务。

第四步：分别检查主机防火墙和云安全组

主机防火墙与云平台安全组是不同层级的访问控制：主机规则允许，不代表云安全组也放行；安全组允许，也不能覆盖主机本地的拒绝规则。两处都要确认协议、目标端口和来源范围。

先识别服务器实际使用的防火墙管理方式。以下是查询示例，不保证每台服务器都安装或启用了这些工具：

sudo ufw status verbose
sudo firewall-cmd --state
sudo firewall-cmd --list-all
sudo nft list ruleset

遇到命令不存在或服务未运行时，先确认系统和当前防火墙管理方式，不要为了排障直接安装、启用另一套规则工具。检查目标端口是否有允许规则、是否存在更早生效的拒绝规则，以及规则是否限制了来源地址。若只允许指定来源，服务器本机测试成功而外部用户失败并不矛盾。

在云平台控制台还要确认：

1. 检查的是当前日本服务器实际关联的安全组或访问策略，而不是其他实例的规则。
2. 规则为入站方向，协议和目标端口与服务一致。
3. 来源范围包含实际测试用户的公网出口地址。
4. 若修改过规则，确认变更已应用到当前实例，再安排外部复测。

只有在业务需要时才调整规则。先记录或导出原有规则，确认远程管理通道可用，并将变更限制在所需端口和来源范围。不要清空规则集，也不要为了排障长期对所有来源开放管理端口。具体修改命令取决于发行版、防火墙工具和现有规则；未确认环境前，不应照搬通用规则命令。调整后若影响其他服务或远程管理，应按变更前记录及时回滚。

第五步：公网入口经过 NAT 时核对端口映射

如果公网地址不直接配置在这台服务器上，而是经过网关或其他设备转发，需要核对完整映射关系：

• 用户连接的公网地址和公网端口是否正确；
• 转发规则的协议是 TCP 还是 UDP，是否与应用一致；
• 目标内网地址是否仍指向这台服务器；
• 内网目标端口是否与服务器实际监听端口一致；
• 承担转发的设备是否允许该入站流量。

公网端口和服务器监听端口可以不同。例如公网端口转发到另一个内网端口时，用户访问公网端口，应用则应监听映射指向的内网端口。若服务器直接拥有公网地址且没有中间转发环节，就不应为了排障额外添加 NAT 配置。

修改映射前记录原规则和目标地址，并确认变更影响范围。调整后从外部使用用户实际访问的公网地址、端口和协议复测；若访问异常扩大或影响其他业务，恢复原映射。若请求没有到达服务器，且映射规则看似正确，应进一步确认规则关联的公网入口和目标设备是否确为当前业务路径，不能仅凭控制台中存在一条规则判断转发已生效。

按测试结果定位更可能的故障层

这些结果表示排查优先级，不是单项证据就能确定根因。例如，抓包没有看到请求，只有在过滤端口、协议、接口和复测时间都正确时，才有助于把排查重点移向服务器之前的路径；TCP 建连成功也不能证明应用层业务已经正常。

修复后验证并留意复发条件

修复后应从外部网络重新测试用户实际使用的域名或公网地址、端口和协议，同时在服务器复查监听状态。TCP 服务可用以下命令做连接测试：

nc -vz 公网地址 8443

随后还要通过客户端实际使用的业务方式确认应用响应符合预期。若公网 IP 测试成功、域名访问失败，继续核对域名解析；若 TCP 可连但页面或业务请求失败，检查应用日志和应用层配置。端口能够建立连接，不等于业务功能已经恢复。UDP 服务则应通过实际业务请求、服务日志或服务器侧数据包确认，不能用 TCP 测试替代。

记录每次验证的时间、测试来源、目标地址、端口、协议和结果，并在服务重启、配置重载或规则持久化后再次确认。若问题复发，优先比较监听地址和端口、主机规则、安全组关联关系、公网地址指向及 NAT 目标是否发生变化；若失败只发生在部分用户侧，则同时记录来源地址和失败时段。这样可以区分应用监听问题与网络入口问题，也能减少未确认根因前反复放行端口的风险。