首次部署香港服务器搭配CN2线路，目标不是先追求复杂优化，而是先让服务器具备清晰、可回退、可验证的基础状态：拥有正确的公网地址和默认路由，能够通过管理入口登录，DNS解析正常，必要端口已按最小范围放行，并能从实际业务网络验证TCP连通性。

以下示例以使用systemd的Ubuntu Server为例，假设服务器已经分配公网IPv4地址，并且可以通过服务商控制台或远程控制台进入系统。若服务商同时提供IPv6，应单独检查IPv6地址、路由和防火墙规则，不要因为IPv4测试通过就直接关闭IPv6。

准备条件与验收范围

首次操作前，至少确认以下信息：

“CN2”属于线路或路由服务的描述，不能仅凭IP归属地、反向解析名称或某一次路由结果认定。验证时应同时参考服务商的线路说明，并从实际使用网络对服务器公网地址进行TCP测试。路由可能随时间、目的端口和来源网络变化，单次测试只能说明当时的路径状态。

1. 首次登录后保存现状

不要一登录就修改网络配置。先记录当前状态，后续出现断连时可以判断是配置变化导致，还是原本就存在问题。

以下命令适用于Ubuntu Server。备份目录只保存网络和服务状态，不要把密码、私钥或应用密钥写入其中。

sudo install -d -m 700 /root/net-baseline

date -Is | sudo tee /root/net-baseline/checked-at.txt
cat /etc/os-release | sudo tee /root/net-baseline/os-release.txt
ip -br link | sudo tee /root/net-baseline/link.txt
ip -br addr | sudo tee /root/net-baseline/address.txt
ip route show table main | sudo tee /root/net-baseline/route.txt
sudo ss -lntup | tee /root/net-baseline/listeners.txt

如果系统使用systemd-resolved，继续记录DNS状态：

resolvectl status | sudo tee /root/net-baseline/resolved-status.txt
ls -l /etc/resolv.conf | sudo tee /root/net-baseline/resolv-conf-link.txt

检查网络管理方式：

systemctl is-active systemd-networkd || true
systemctl is-active NetworkManager || true
command -v netplan || true

这里的重点不是要求某个服务必须处于运行状态，而是确定当前系统由谁管理网络。已经正常工作的服务器，不应在没有确认管理方式的情况下同时使用多套网络配置工具。

2. 检查公网地址、默认路由和DNS

先查看网卡和地址：

ip -br addr
ip route

正常的IPv4服务器通常可以看到：

• 网卡处于UP状态；
• 公网IPv4地址绑定在正确网卡上；
• 主路由表中存在default via ...默认路由；
• 默认路由使用的网卡与公网地址对应。

不要把示例中的网卡名、网关或地址直接复制到生产系统。云服务器常见网卡名包括ens3、eth0等，必须以ip -br link的实际结果为准。

检查指定目标会使用哪条路由：

ip route get 1.1.1.1

这条命令主要用于确认内核选择的出口网卡和下一跳，不代表一定要使用该地址作为业务测试目标。若输出中没有默认出口，优先检查服务商侧网络分配、网卡配置和网关参数，不要先修改防火墙。

检查DNS：

resolvectl status
resolvectl query example.com
getent ahostsv4 example.com

如果resolvectl不可用，可以先查看：

cat /etc/resolv.conf

/etc/resolv.conf经常是指向系统解析服务的符号链接，不能在不了解管理方式的情况下直接覆盖。DNS地址应优先使用服务商提供的解析地址，或者使用企业明确批准的解析服务。修改后要同时验证“服务器能解析域名”和“业务应用能访问目标域名”，两者不一定完全等价。

3. 仅在必要时调整基础网络配置

如果公网IPv4、默认路由和DNS已经正常，首次部署不建议为了“重新配置一次”而覆盖现有网络文件。对远程服务器来说，网络配置改错可能立即中断SSH连接。

DHCP配置场景

如果服务商明确要求通过DHCP获取IPv4，且系统使用Netplan，可以参考以下结构。网卡名必须替换成实际名称；仅适用于IPv4-only场景，已有IPv6配置时不要照此关闭IPv6。

network:
  version: 2
  ethernets:
    ens3:
      dhcp4: true
      dhcp6: false

保存前先备份原有配置：

sudo install -d -m 700 /root/net-baseline/netplan-backup
sudo cp -a /etc/netplan/. /root/net-baseline/netplan-backup/

检查语法并生成配置：

sudo netplan generate

远程操作时优先使用带自动回退机制的测试应用：

sudo netplan try

执行后不要立即关闭当前SSH窗口。先从另一台设备重新建立SSH连接，确认新配置可用，再在提示中确认。如果没有确认，Netplan通常会回退到原配置；不同发行版和镜像的行为可能存在差异，因此仍应保留服务商控制台入口。

静态地址配置场景

只有在服务商明确提供公网地址、前缀、网关和DNS时，才使用静态配置。下面是格式示例，尖括号内容必须替换为服务商给出的真实参数，不能直接粘贴执行：

network:
  version: 2
  ethernets:
    ens3:
      dhcp4: false
      addresses:
        - /
      routes:
        - to: default
          via: 
      nameservers:
        addresses:
          - 
          - 

修改前执行：

sudo install -d -m 700 /root/net-baseline/netplan-backup
sudo cp -a /etc/netplan/. /root/net-baseline/netplan-backup/

修改后先检查：

sudo netplan generate

没有报错后再执行：

sudo netplan try

如果远程连接中断，应通过服务商控制台恢复备份文件，而不是反复尝试不同网关。静态地址最常见的错误包括前缀填写错误、网关不属于服务商分配的网络、网卡名称写错，以及把云平台提供的额外地址误当成主地址。

4. 确认SSH服务和管理入口

在调整防火墙之前，先确定SSH实际监听的地址和端口：

sudo sshd -T | grep -E '^(port|listenaddress) '
sudo ss -lntp | grep -E 'sshd|:22[[:space:]]'
sudo systemctl status ssh --no-pager

Ubuntu通常使用ssh服务名，其他发行版可能使用sshd。如果SSH端口不是22，后续测试和防火墙规则都要以实际端口为准。

如需修改SSH配置，先备份并检查语法：

sudo install -m 600 /etc/ssh/sshd_config \
  /root/net-baseline/sshd_config.$(date +%F-%H%M%S)

sudo sshd -t

不要在尚未验证密钥登录的情况下关闭密码登录，也不要在没有第二个测试会话时修改端口或限制管理员来源。正确顺序应是：

1. 保留当前SSH会话；
2. 使用新配置从另一台设备重新登录；
3. 确认新会话能够执行必要的管理操作；
4. 再考虑收紧登录策略；
5. 任何修改都先执行sshd -t，通过后再重新加载服务。

仅重载SSH服务不会中断已经建立的会话，但错误配置可能使新会话无法建立：

sudo systemctl reload ssh

如果重载后发现新连接失败，应通过当前会话或控制台恢复备份，检查语法后再重载。

5. 配置云侧和系统侧防火墙

防火墙应分为两层检查：

• 服务商控制台中的安全组或云防火墙；
• 服务器内部的UFW、nftables或其他主机防火墙。

两层中任何一层拒绝，外部连接都可能失败。先查看系统当前策略，不要直接执行清空或重置规则的命令：

sudo ufw status verbose
sudo nft list ruleset

如果使用UFW，并且确认当前没有需要保留的入站服务，可以按最小范围添加规则。以下示例假设SSH端口为22，替换为实际管理出口公网地址：

sudo ufw default deny incoming
sudo ufw default allow outgoing

sudo ufw allow from /32 to any port 22 proto tcp
sudo ufw allow 80/tcp
sudo ufw allow 443/tcp

只有在确认第二个SSH会话可以使用，并且云侧策略也已放行后，才执行：

sudo ufw enable
sudo ufw status numbered

上述操作会影响所有未明确允许的入站连接。若服务器已有数据库、监控、应用接口或其他业务端口，应先登记现有监听端口，再决定是否使用默认拒绝策略。没有HTTPS服务时，不必为了“测试方便”开放443；没有公网管理需求时，也不要把SSH管理端口开放给所有来源。

云侧规则至少要与主机规则保持一致：

• SSH只允许实际管理来源；
• HTTP仅在提供明文网站或健康检查时开放；
• HTTPS仅在服务器确实监听并提供TLS服务时开放；
• 出方向DNS、软件更新和业务访问按实际需要确认；
• 如果启用了IPv6，IPv6规则要单独检查，不能只看IPv4规则。

6. 启动一个可重复验证的服务

如果服务器已经运行实际业务，应直接验证业务监听端口，不必额外安装服务。若还没有业务，为了验证公网入站能力，可以临时安装Nginx作为HTTP测试服务。

安装软件会修改系统软件包和服务状态，建议在控制台可用、网络状态已记录的前提下执行：

sudo apt-get update
sudo apt-get install -y nginx

检查配置并启动：

sudo nginx -t
sudo systemctl enable --now nginx
sudo systemctl status nginx --no-pager
sudo ss -lntp | grep -E ':(80|443)[[:space:]]'

先在服务器本机测试HTTP服务：

curl -4 -I --connect-timeout 5 http://127.0.0.1/

返回HTTP响应，说明Nginx进程、监听端口和本机处理链路基本正常。如果本机访问失败，应先查看：

sudo journalctl -u nginx --since "-15 min" --no-pager
sudo nginx -t

本机测试成功并不等于公网可访问，还必须从服务器外部网络测试公网IPv4地址。

7. 分层验证服务器连通性

服务器到外部网络

先确认路由选择：

ip route get 1.1.1.1

再测试DNS和HTTPS出站能力：

getent ahostsv4 example.com
curl -4 -I --connect-timeout 5 https://example.com

如果DNS能解析但HTTPS失败，可能是出方向策略、目标站点策略、系统时间或证书环境问题。不要把一次外部站点访问失败直接归因于香港服务器搭配CN2线路本身，应该换成企业自有测试目标，或者使用服务商提供的测试地址。

网关是否响应ICMP取决于服务商策略，因此下面的测试只能作为辅助：

ping -4 -c 4 

网关不响应不一定表示网关不可用；更有价值的是检查默认路由，以及对实际业务目标的TCP访问。

外部网络到服务器

从实际办公网络、业务访问网络或指定的大陆测试网络执行以下测试。Linux或macOS可以使用：

ping -4 -c 4 
nc -4 -vz -w 5  22
curl -4 -I --connect-timeout 5 http:///

Windows PowerShell可以使用：

Test-NetConnection  -Port 22
Test-NetConnection  -Port 80
tracert -4 

判断时优先看TCP结果：

• ping失败但Test-NetConnection或nc成功，通常说明ICMP被限制，不能据此判定业务不可用；
• TCP连接失败但本机服务正常，优先检查云侧安全组、UFW和监听地址；
• TCP连接成功但HTTP返回错误，问题更可能在Nginx、应用配置或请求处理，而不是基础网络；
• SSH成功而HTTP失败，说明管理端口和Web端口的规则或服务状态不同。

验证CN2线路相关路径

线路验证需要使用服务商给出的正式测试目标，或者直接使用服务器公网IPv4地址，并从实际业务来源网络执行。Linux客户端可以使用：

traceroute -4 -T -p 80 

如果客户端安装了MTR，可使用TCP方式观察多次结果：

mtr -4 -r -w -c 20 -T -P 80 

实际业务使用HTTPS时，将端口替换为443；使用SSH管理时，可测试实际SSH端口。TCP测试比单纯ICMP或UDP路由跟踪更接近真实服务访问，但仍可能受到中间设备限速、隐藏响应或策略过滤影响。

验证结果应关注以下几点：

1. 测试来源是否就是实际用户或办公网络；
2. 测试目标是否为服务器真实公网地址；
3. 目的端口是否与实际服务一致；
4. 多次测试的最终地址是否稳定可达；
5. 中间某一跳丢包是否同时影响最终目标；
6. 服务商提供的线路说明是否明确适用方向和测试条件。

中间某一跳显示丢包，但最终服务器没有丢包，通常可能只是该设备限制路由探测响应，不能直接判定业务丢包。只有当最终目标的TCP连接也持续失败，且从多个有效来源复现，才需要将结果提交给服务商进一步核查。

8. 成功标准

完成首次部署后，可以用下面的表格逐项验收：

9. 常见失败处理

能进入控制台，但SSH无法连接

先在控制台执行：

sudo systemctl status ssh --no-pager
sudo ss -lntp | grep -E 'sshd|:22[[:space:]]'
sudo sshd -t
sudo journalctl -u ssh --since "-15 min" --no-pager

如果没有监听端口，检查SSH服务配置和服务状态；如果服务器有监听但外部连接失败，检查云侧规则和UFW；如果只有特定来源失败，检查管理来源地址是否变化。

本机服务正常，外部TCP连接失败

按顺序检查：

1. Nginx或实际应用是否监听公网地址，而不是只监听127.0.0.1；
2. 云侧安全组是否放行实际端口；
3. UFW是否存在拒绝规则；
4. 测试端口是否与监听端口一致；
5. 外部网络是否本身限制了该端口。

查看监听地址：

sudo ss -lntp

如果显示服务只监听127.0.0.1:80，外部无法直接访问，需要修改应用或Nginx监听配置。修改前先备份配置，修改后执行nginx -t，确认无误再重载。

能访问IP，但域名访问失败

先确认域名解析到的地址是否就是当前服务器：

getent ahostsv4 

再确认服务器本机服务和外部IP访问均正常。如果IP访问成功、域名解析错误，问题在DNS记录或缓存；如果解析正确但域名请求失败，再检查应用的虚拟主机配置、TLS配置和Host处理。

路由跟踪中出现超时

不要只看中间跳。分别进行以下判断：

• 最终TCP端口可以连接：中间设备可能只是限制探测响应；
• 最终TCP端口无法连接，但服务器本机服务正常：检查云防火墙和来源网络；
• 多个实际来源都无法连接：记录时间、源地址、目的地址、端口和测试结果，提交服务商；
• 只有某一个来源失败：优先检查该来源网络出口或本地安全策略。

路由结果与线路说明不一致

不要自行根据某几个地址或跳数给线路下结论。先确认测试工具使用的是IPv4还是IPv6、TCP还是ICMP/UDP，确认目的端口和测试来源，再向服务商索取与当前实例对应的线路说明、测试地址和适用方向。线路名称、IP注册信息和单次路由结果应作为不同证据分别记录。

10. 失败时的回滚方法

网络配置回滚

如果使用了netplan try，应优先等待其自动回退，或通过服务商控制台操作。若需要手工恢复，只在控制台中使用已经确认的备份文件：

sudo cp -a /root/net-baseline/netplan-backup/ \
  /etc/netplan/
sudo netplan generate
sudo netplan apply

和必须替换为真实文件名。不要使用不确定的通配符覆盖整个/etc/netplan目录。恢复后重新检查：

ip -br addr
ip route
resolvectl status

防火墙回滚

先查看编号，避免删除错误规则：

sudo ufw status numbered

删除刚刚添加的规则时，优先使用显示出的规则编号。若已经无法通过SSH进入，只能通过服务商控制台处理。紧急执行ufw disable会暂时取消主机防火墙保护，影响范围是所有入站流量，因此只能作为恢复入口，完成登录后应立即重新建立正确的最小规则。

Nginx测试服务回滚

如果Nginx只是临时验证服务，可以停止并取消开机启动：

sudo systemctl disable --now nginx

这会立即停止80端口上的Nginx，若该端口已承载真实业务，不要执行。真实业务配置修改必须先备份，恢复后执行：

sudo nginx -t
sudo systemctl reload nginx

上线前验收检查清单

• [ ] 已记录操作系统、网卡、地址、路由、DNS和监听端口。
• [ ] 公网IPv4、前缀、网关和DNS均来自服务商或网络管理员提供的信息。
• [ ] SSH已通过第二个会话验证，当前会话未在测试完成前关闭。
• [ ] 云侧安全组与服务器内部防火墙规则一致。
• [ ] 只开放实际需要的SSH、HTTP或HTTPS端口。
• [ ] 本机服务测试成功，外部TCP测试也成功。
• [ ] DNS解析结果指向当前服务器，业务域名验证通过。
• [ ] 已从实际业务来源网络执行TCP路径和连通性测试。
• [ ] 没有把单次路由跟踪、中间跳丢包或IP归属信息单独当作CN2线路证明。
• [ ] 网络文件、SSH配置和必要的防火墙状态均有可用备份。
• [ ] 失败时可以通过服务商控制台恢复网络或防火墙配置。