最近一台 CentOS 7 服务器出现了一个很奇怪的问题：

• SSH 登录偶尔会卡 5 秒或 10 秒；
• 同一台服务器，大多数时候又完全正常；
• 更奇怪的是，只要客户端使用 ssh -vvv 登录，就几乎不会出现卡顿。

最开始一直怀疑是 SSH 本身的问题，结果最后发现根本不是。

故障现象

普通登录：

1

ssh [email protected]

偶尔停顿：

1
2

Connecting...
（等待约 5 秒）

或者

1

（等待约 10 秒）

但是开启调试：

1

ssh -vvv [email protected]

几乎每次都是秒连。

由于 -vvv 只是增加调试输出，并不会修改 SSH 协议，因此可以判断：

问题不是 SSH 协议本身，而是某个时序相关的问题。

首轮排查

检查 sshd_config：

1
2

UseDNS no
GSSAPIAuthentication no

这些常见导致登录变慢的配置都已经关闭。

服务器也没有：

• nscd
• systemd-resolved

因此基本可以排除 SSH 配置导致的问题。

抓包发现

抓 DNS：

1

tcpdump -ni ens192 port 53

登录卡顿期间，可以看到服务器不断查询：

1

PTR? 209.1.168.192.in-addr.arpa

返回：

1

NXDOMAIN

说明 SSH 登录过程中确实发生了反向 DNS 查询。

奇异之处

直接测试：

1

dig -x 192.168.1.209

查询时间始终只有：

1

Query time: 8 ms

连续测试上百次都正常。

但是：

1

getent hosts 192.168.1.209

却偶尔出现：

1

real    0m5.013s

甚至：

1

real    0m10.020s

说明：

DNS 服务器本身没有慢。

真正慢的是 glibc 的名称解析（getaddrinfo/gethostbyaddr）。

Python 同样能复现：

1

socket.getaddrinfo("www.baidu.com",80)

有时直接等待 10 秒后报：

1

socket.gaierror

进一步证明问题发生在系统解析库，而不是 SSH。

最终定位

后来发现，公司出口实际上有三条公网线路：

• A
• B
• C

205 服务器当时一直走 C 线路。

当出口切换到 A/B 后：

• getent 不再出现 5 秒或 10 秒等待；
• SSH 登录恢复正常；
• ssh -vvv 与普通 SSH 都没有任何区别。

而走 C 线路时：

• 普通 SSH 偶尔卡顿；
• ssh -vvv 基本正常；
• DNS 查询 (dig) 很快；
• glibc 名称解析 (getent) 却偶尔超时。

目前推测是 C 出口上的 UDP/DNS 通信存在偶发异常或丢包，导致 glibc 重试，从而出现 5 秒、10 秒的等待；而开启 -vvv 后，由于客户端和服务端交互时序发生变化，这个问题反而难以触发，因此表现为“加 -vvv 就正常”。

结论

这次问题最大的收获有两点：

1. SSH 卡顿，不一定是 SSH 的问题。
2. 如果 ssh -vvv 能恢复正常，往往说明问题与时序、DNS 或网络环境有关，而不是 SSH 配置本身。

以后再遇到 SSH 登录随机卡 5 秒、10 秒的情况，除了检查 sshd_config 外，也建议同步检查：

• DNS 正向/反向解析
• getent hosts
• getent ahosts
• dig
• tcpdump port 53
• 出口线路或 NAT 是否存在异常

很多时候，真正的问题并不在 SSH，而是在系统名称解析或网络出口。

在学习 BGP 的过程中，经常会看到 Transit（中转）、Peering（对等互联）、Upstream（上游） 等术语。

很多资料都会解释它们的定义，但对于刚接触 BGP 的人来说，仍然容易混淆。

本文结合实际例子，介绍它们之间的区别，以及互联网为什么需要这两种互联方式。

什么是 Transit？

Transit 可以理解为：

花钱购买互联网接入服务。

例如，我们申请了自己的自治系统：

1

AS402309

如果想让自己的网络能够访问整个互联网，就必须找一家运营商作为自己的 Transit Provider（中转提供商）。

例如：

1
2
3
4
5
6

 Internet
      │
Transit Provider
   AS17476
      │
  AS402309

这里：

• AS17476 就是 AS402309 的上游（Upstream）
• AS402309 每月支付 Transit 费用
• AS17476 负责把整个互联网的路由提供给 AS402309

也就是说：

Transit Provider 会告诉你：”整个互联网我都能带你去。”

因此：

• 可以访问 Google
• 可以访问 Cloudflare
• 可以访问 AWS
• 可以访问世界上几乎所有网络

这就是 Transit。

什么是 Peering？

Peering 中文通常翻译为：

对等互联

假设：

1

AS402309  <------->  AS216458

双方建立了 BGP Peering。

它们约定：

• 我告诉你我的网络
• 你告诉我你的网络

双方互相访问彼此的网络。

但是：

不会帮对方访问整个互联网。

例如：

AS216458 可以访问：

1

AS402309

AS402309 也可以访问：

1

AS216458

但是：

1
2
3
4
5

AS216458
    │
AS402309
    │
Google

这种情况通常是不允许的。

因为：

AS402309 并不会把自己购买的 Transit 服务免费分享给 Peer。

为什么 Peer 不提供互联网中转？

原因其实很简单。

假设：

1
2
3
4
5
6
7

Google
   │
AS17476
   │
AS402309
   │
AS216458

如果允许：

1
2
3
4
5
6
7

AS216458
    │
AS402309
    │
AS17476
    │
Internet

那么：

AS216458 就不用购买 Transit 了。

所有互联网流量都走 AS402309。

最终：

• AS402309 支付 Transit 费用
• AS216458 免费使用

显然，这种商业模式无法成立。

因此互联网形成了一条经典规则：

Peer 不会免费提供 Transit。

Transit 与 Peering 的关系

很多人认为：

Peering 就是不转发流量。

其实这种说法并不准确。

更准确的说法应该是：

Peering 会转发流量，但只转发属于自己网络及客户网络的流量，而不会提供整个互联网的中转服务。

因此：

Peer 可以访问：

• 对方自己的网络
• 对方客户(Customer)的网络

但是：

不会访问：

• 对方 Transit 学到的互联网路由

一个生活中的例子

其实 Transit 和 Peering 很像家庭宽带。

假设：

• 我家 = AS402309
• 邻居 = AS216458
• 中国电信 = AS17476

那么：

1
2
3
4
5
6
7
8
9

  中国电信
     │
 （Transit）
     │
   我家
     │
（Peering）
     │
   邻居家

Transit

我向中国电信办理宽带。

每个月交宽带费。

电信承诺：

全世界的网站都可以访问。

这就是 Transit。

Peering

后来：

我和邻居之间拉了一根网线。

双方约定：

• 可以互相访问 NAS
• 可以互相访问局域网资源

但是：

我不会说：

“以后你上互联网都走我家的宽带。”

邻居也不会说：

“以后你走我家的宽带。”

这就是 Peering。

也就是说：

Peering 是资源共享，而不是互联网共享。

为什么互联网需要 Peering？

如果没有 Peering：

访问邻居：

1
2
3
4
5
6
7
8
9

我家
 │
电信
 │
互联网
 │
联通
 │
邻居

可能需要绕很远。

如果双方直接建立 Peering：

1
2
3
4
5

我家
 │
────────────
 │
邻居

访问速度明显更快。

现实中：

Cloudflare、Google、Meta、Netflix 等大型网络都会在全球 Internet Exchange（IX）建立大量 Peering，就是为了降低延迟、减少 Transit 成本。

Transit 与 Peering 的区别

为什么说所有 ISP 都离不开 Transit？

理论上：

如果一个新的 ASN：

1

AS65000

没有任何 Transit：

那么它只能访问：

1

自己

即使建立很多 Peer：

1
2
3
4
5

AS65000
   │
Peer
   │
很多网络

仍然无法访问整个互联网。

因此：

几乎所有小型 ISP 都至少拥有一个 Transit Provider。

而大型运营商则通常拥有：

• 多个 Transit
• 大量 Peering
• 多个 Internet Exchange

共同组成自己的全球网络。

总结

可以把互联网理解成这样：

1
2
3
4
5
6
7
8

         整个互联网
              │
        Transit（上游）
              │
          你的 ASN
         /         \
  Peering         Peering
Cloudflare        Google

其中：

• Transit 保证”哪里都能去”；
• Peering 保证”常去的地方走最近的路”。

两者缺一不可。

也正是 Transit 与 Peering 的共同作用，构成了今天全球互联网复杂而高效的互联体系。

在维修独立显卡时，PCIe 金手指各信号的对地阻值（或二极管压降）能够快速判断供电、时钟、复位以及 PCIe 总线是否存在异常。

测量方式：

• 万用表二极管档（推荐）
• 红表笔接地（GND）
• 黑表笔测量对应测试点

PCIe 金手指关键测试点

各测试点说明

12V 主供电（B1～B12）

• 为显卡核心供电输入。
• 对地阻值明显偏低时，应优先检查：
  • 输入 MOS 管
  • 供电 PWM
  • 显存或 GPU 是否短路

参考值：

约 400

3.3V 电源（B8）

主要为 PCIe 接口逻辑供电。

参考值：

约 400

若接近 0，则需要检查：

• PCIe 电源滤波电容
• 3.3V 电源转换电路

3.3V AUX（B10）

属于待机供电，在部分显卡上可能测得：

• OL（开路）
• 约 400

不同品牌和型号存在一定差异，属于正常现象。

REFCLK 时钟（A13 / A14）

PCIe 100MHz 差分参考时钟。

参考值：

约 800

若数值明显异常，可能存在：

• 时钟发生器故障
• 时钟线路断线
• GPU 内部异常

PERST# 复位（A11）

PCIe 总线复位信号。

参考值：

约 500

若接近 0 或完全开路，应进一步检查：

• 主板复位控制
• GPU
• 上拉电阻

PCIe 数据总线

PCIe x16 接口共有：

• A 面：32 条高速信号
• B 面：32 条高速信号

正常参考值：

• A 面约 200
• B 面约 300

若某一路明显偏离其它信号（例如为 0、OL 或差异很大），需重点排查：

• 金手指损坏
• PCB 断线
• GPU PCIe PHY 损坏
• ESD 保护器件异常

注意事项

1. 不同品牌、不同 GPU（NVIDIA、AMD、Intel）以及不同 PCB 设计，测试值会存在一定差异。
2. 本文数据主要用于快速判断是否存在异常，不应作为唯一维修依据。
3. 建议结合供电时序、示波器波形、阻值测量及故障现象综合分析。
4. 若某一路数据与同类信号相比差异明显，应优先排查该线路。

总结

显卡维修中，PCIe 金手指是最重要的检测位置之一。通常只需测量 12V、3.3V、3.3V AUX、REFCLK、PERST# 以及 64 条 PCIe 数据线 的对地值，就能够快速判断是否存在短路、断线或芯片异常，大幅提高故障定位效率。

本文记录在 Hyper-V 宿主机上开启远程管理的标准配置流程，适用于非域环境、跨网段远程访问Hyper-V 管理场景。

一、启用 WinRM（核心入口）

在宿主机执行：

1

winrm quickconfig -Force

作用说明
启动 WinRM 服务
开启 5985 端口监听
自动配置基础防火墙规则
自动设置 LocalAccountTokenFilterPolicy（关键权限项）

这是远程管理的基础步骤，必须先执行。

二、设置 TrustedHosts（跨网段或非域环境必做）

1

Set-Item WSMan:\localhost\Client\TrustedHosts -Value "192.168.1.27" -Force

作用说明
允许指定主机 192.168.1.27 连接本机
解决非域环境下 Kerberos 认证不可用问题
支持 IP 级别的信任连接

多客户端情况下可以使用多个 IP 或通配配置。

三、启用 CredSSP（解决凭据传递问题）

1

Enable-WSManCredSSP -Role Server -Force

作用说明
启用 CredSSP 凭据委派机制
解决远程再跳转（double-hop）权限问题
适用于 Hyper-V 远程管理场景

四、设置网络类型为 Private

1

Set-NetConnectionProfile -NetworkCategory Private

作用说明
Windows 在 Public 网络模式下会限制远程访问
设置为 Private 后允许远程管理规则生效
确保 WinRM 正常通信

五、确认并启用远程管理

1
2

winrm quickconfig -force
Enable-PSRemoting -Force

作用说明
确保 WinRM 配置生效
启用 PowerShell Remoting 功能
修复部分策略未完全应用的问题

六、启用 WinRM 防火墙规则（兼容性处理）

1
2
3

Get-NetFirewallRule |
Where-Object DisplayName -like "*WinRM*" |
Enable-NetFirewallRule

作用说明
统一放行 WinRM 相关防火墙规则
避免不同 Windows 版本规则名称不一致的问题
确保 5985 端口通信正常

电脑主板“不触发（按开机键没反应）”是维修中最常见的故障之一。

很多初学者一上来就怀疑南桥（PCH）损坏，实际上，大部分问题都出在：

• 待机条件异常
• I/O（Super I/O）未工作
• 时钟或复位缺失
• 电源触发线路断线

本文整理一套较为通用的 ATX 主板触发电路维修思路，通过几个关键控制信号，快速判断故障位置。

一、理解主板的触发流程

在维修之前，首先要知道主板是如何“开机”的。

典型 Intel 平台 ATX 主板的开机流程如下：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

5VSB 待机电压正常
        ↓
I/O 获得待机条件
        ↓
按下开机键
        ↓
PWRBTN# 送入 PCH
        ↓
PCH 输出 SLP_S4# / SLP_S3#
        ↓
I/O 输出 PS_ON#
        ↓
ATX 电源启动
        ↓
各路主供电建立

简单来说：

• 前半部分属于“待机判断”
• 后半部分属于“执行触发”

因此，维修时必须按顺序排查，而不是盲目更换芯片。

二、第一步：检查待机条件

所有触发电路的前提，都是待机系统正常。

重点检查：

如果待机电压都不正常，那么后面的 PWRBTN#、SLP_S3# 等信号全部没有意义。

三、PWRBTN#：判断按键信号是否进入 PCH

PWRBTN# 是主板最重要的触发信号之一。

它的本质：

1

“用户按下了开机键”

正常波形

按下开机键时：

1

3.3V → 0V → 3.3V

说明：

• 开机按键正常
• I/O 已工作
• I/O 已将按键信号送到 PCH

情况一：PWRBTN# 有跳变，但主板不触发

这说明：

1
2

I/O 基本正常
但 PCH 没有响应

通常代表：

• PCH 待机条件不满足
• PCH 未进入工作状态
• PCH 本身损坏

重点检查：

• RSMRST#
• SUSCLK
• 32K 时钟
• RTC
• PCH 供电

情况二：PWRBTN# 没有跳变

如果按下开机键后完全没有变化：

1

PWRBTN# 始终固定不变

说明：

1

I/O 本身没有进入待机工作状态

即：

1

I/O 待机条件不满足

重点检查：

• I/O 供电
• 3VSB
• LPC 时钟
• BIOS
• RSMRST#
• I/O 芯片本身

四、SLP_S4# / SLP_S3#：判断 PCH 是否真正响应

这两个信号非常关键。

它们代表：

1

PCH 是否开始执行开机流程

正常现象

按下开机键时：

1
2
3
4
5
6

SLP_S4#
SLP_S3#

出现：

3.3V ↔ 0V

说明：

1

PCH 的触发逻辑正常

即：

• PCH 已工作
• PCH 已开始控制系统电源状态

如果完全没有变化

说明：

1

PCH 根本没有执行开机动作

常见原因：

• PCH 损坏
• BIOS 异常
• 32K 时钟缺失
• PCH 待机条件异常

五、PS_ON#：判断电源启动命令是否送出

PS_ON# 是：

1

主板通知 ATX 电源启动的控制信号

通常由 I/O 输出。

正常现象

触发后：

1
2

PS_ON#
高电平 → 低电平

ATX 电源开始启动。

如果 PS_ON# 已经拉低，但仍不启动

说明：

1

I/O 已经发出了开机命令

故障点通常位于：

1

I/O → 电源接口绿线

之间。

例如：

• 线路断线
• 电阻损坏
• 接口虚焊
• ATX 插座故障

也就是说：

1

触发命令没有真正送到电源

六、待机条件都正常但仍不触发怎么办？

如果：

• 待机正常
• PWRBTN# 正常
• SLP_S3#/SLP_S4# 正常

但仍无法触发：

维修经验通常是：

1
2

先换 I/O
再换 PCH

原因：

• I/O 损坏概率更高
• 更换难度更低
• 风险更小

七、华硕主板的特殊情况：SKTOCC

部分 ASUS 主板会检测：

1
2

SKTOCC
(Socket Occupied)

即：

1

CPU 是否已安装

现象

如果没有安装 CPU：

1

主板完全不触发

这是正常设计。

因此维修华硕主板时：

1

必须安装 CPU 再测试

否则容易误判主板故障。

八、推荐的维修排查顺序

实际维修中，建议按照以下顺序检查：

1
2
3
4
5
6
7
8
9
10
11
12
13

① 待机电压
        ↓
② PWRBTN#
        ↓
③ SLP_S4# / SLP_S3#
        ↓
④ PS_ON#
        ↓
⑤ 时钟 / 复位
        ↓
⑥ I/O
        ↓
⑦ PCH

这样能够避免大量无意义的拆焊。

九、这些信号的本质是什么？

可以简单理解为：

十、总结

主板“不触发”故障，本质上就是：

1

“开机命令没有成功走完整个触发链路”

维修时不要一开始就怀疑 PCH。

正确的方法应该是：

1
2
3

先看按键有没有送到 PCH，
再看 PCH 有没有响应，
最后看 I/O 有没有通知电源启动。

只要理解了这条逻辑链，大部分不触发故障都能快速定位。

在实际使用 Hyper-V 的过程中，很多人都会遇到一个典型问题：

为什么在 Windows Server 上可以轻松进行“实时迁移（Live Migration）”，而在 Windows 10/11（Client版）上却连入口都看不到？

本文将从架构、功能、配置以及实战角度，系统整理 Server版 Hyper-V 与 Client版 Hyper-V 在虚拟机迁移方面的核心区别，并给出可落地的解决方案。

一、两种 Hyper-V 的本质区别

1. Server版 Hyper-V（Windows Server）

特点：

• 完整的 服务器角色（Role-based）架构
• 默认支持：
  • Live Migration（实时迁移）
  • Storage Migration（存储迁移）
  • Hyper-V Replica（复制）
  • Failover Cluster（集群）
• 设计目标：数据中心 / 虚拟化平台

👉 可以理解为：
“企业级虚拟化基础设施”

2. Client版 Hyper-V（Windows 10 / 11 Pro）

特点：

• 精简版 Hyper-V（客户端功能）
• 默认支持：
  • 本地虚拟化
  • 基础管理
• 限制：
  • 无完整迁移角色模型
  • UI功能受限
  • 非域环境支持较弱

👉 可以理解为：
“开发/测试用虚拟化工具”

二、虚拟机迁移能力对比

三、最容易踩的坑：为什么看不到“迁移虚拟机”？

在 Client 版 Hyper-V 中，很多人会发现：

👉 右键虚拟机只有：

• “移动存储”
• 没有“移动虚拟机”

原因不是版本低，而是“条件未满足”

Hyper-V Manager 的逻辑是：

满足迁移条件 → 显示 Live Migration
不满足 → 隐藏入口，仅保留存储迁移

必须满足的条件（非域环境）

1. 启用 WinRM
2. 配置 TrustedHosts
3. 启用 CredSSP
4. 目标主机允许接收迁移
5. 网络连通正常
6. 虚拟交换机一致

👉 少一个条件，UI直接降级

四、Shared-Nothing Live Migration（无共享存储迁移）

Server版

• 完整支持
• GUI直接可用
• 体验接近“无感迁移”

Client版

• 技术上支持
• 但：
  • UI不显示
  • PowerShell能力受限
  • 稳定性依赖环境

👉 本质是：

“能用，但不鼓励你用”

五、PowerShell 支持差异（关键点）

Server版支持：

1
2

Set-VMHost -VirtualMachineMigrationEnabled $true
Set-VMHost -VirtualMachineMigrationAuthenticationType CredSSP

Client版表现：

1

找不到参数 VirtualMachineMigrationEnabled

👉 原因：

• Hyper-V PowerShell 模块被裁剪
• 部分服务器级参数不可用

六、GUI行为差异（非常关键）

Server版

• 始终显示：
  • 移动虚拟机
  • 实时迁移
  • 目标主机选择

Client版

• 动态UI策略：
  • 条件不满足 → 隐藏功能
  • 只保留 Storage Migration

👉 很多人误以为“功能不存在”，其实只是被隐藏

七、实际迁移流程差异

Server版（标准流程）

1. 选择“移动虚拟机”
2. 选择 Live Migration
3. 自动处理：
   • 内存
   • 磁盘
   • 网络

👉 基本无感切换

Client版（现实流程）

1. UI可能无法操作
2. 需要：
   • 手动配置 WinRM / CredSSP
   • 或使用 PowerShell
3. 常见替代方案：
   • Export / Import
   • Storage Migration

八、实战建议（非常重要）

场景一：纯 Windows Server 环境

👉 推荐：

• 直接使用 Live Migration
• 可结合集群实现高可用

场景二：Windows 10 / 11 多宿主机

👉 推荐：

• 使用 Storage Migration 或 Export/Import
• Live Migration 仅用于测试

场景三：混合环境（Server + Client）

👉 最优方案：

• 使用 Server 作为“控制中心”
• 通过 PowerShell 发起迁移：

1

Move-VM -Name "VM名称" -DestinationHost "目标IP" -IncludeStorage

九、关于“检查（Inspect）按钮”的补充

在 GUI 中：

• 磁盘信息默认不加载
• 点击“检查”才读取 VHDX

原因：

• 延迟加载
• 降低系统负载
• 避免远程卡顿

👉 等价于 PowerShell 的：

1

Get-VHD

十、总结

Server版 Hyper-V 是完整虚拟化平台，而 Client版 Hyper-V 更像是开发工具，两者在迁移能力上存在“设计级差异”。

某坛里发现一个比较有意思的案例：

从绿云 JP（三网 IIJ 优化）线路机 向 DMIT 传输文件时速度明显偏慢。

原本以为是带宽或磁盘性能问题，但通过 traceroute 排查后发现：

不仅没有走传统的日美直连路径，反而先进入中国骨干网，并在国内跨运营商后再出海到美国。

一、先说结论

通过两组 traceroute 可以总结出实际路径：

1

绿云JP → IIJ → 联通4837 → 电信163 → CN2 → DMIT（洛杉矶）

以及另一组软银优化线路：

1

日本VPS → 联通4837 → 电信CN2 → DMIT（洛杉矶）

最终都指向同一个事实：

日本 → 中国 → 美国

而不是：

日本 → 太平洋直连 → 美国

二、实测一：三网 IIJ 优化（绿云 JP）

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20

traceroute to x.x.x.x, 30 hops max, 52 bytes packets
1   x.x.x.x   AS23959  [OWL-JP]         日本 东京都 东京  owl.net
                                              6.87 ms / 19.83 ms / 15.67 ms
2   *
3   211.14.4.221    AS9607   [JPNIC-NET]      日本 东京都 东京  bbtower.co.jp
4   211.14.4.222    AS9607   [JPNIC-NET]      日本 东京都 东京  bbtower.ad.jp
5   172.29.0.10     *                         RFC1918
6   210.138.130.225 AS2497   [IIJ]            日本 东京 iij.ad.jp
7   58.138.98.73    AS2497   [IIJ]            日本 东京 IIJ
8   58.138.112.38   AS2497   [IIJ]            日本 东京 IIJ
9   202.232.1.158   AS2497   [IIJ]            日本 东京 IIJ
10  219.158.30.69   AS4837   [CU169]          中国上海 联通
11  219.158.19.86   AS4837   [CU169]          中国上海 联通
12  219.158.19.81   AS4837   [CU169]          中国上海 联通
13  219.158.8.250   AS4837   [CU169]          中国上海 联通
14  *
15  202.97.62.117   AS4134   [CHINANET]       中国上海 电信
16  *
17  *
22  x.x.x.x         AS906    DMIT 洛杉矶

三、实测二：三网软银优化机器

1
2
3
4
5
6
7
8
9
10
11
12
13

traceroute to x.x.x.x, 30 hops max, 52 bytes packets
1   x.x.x.x    AS147293 日本东京 nearoute.io
2   10.50.1.1
3   *
9   219.158.16.249  AS4837 中国上海 联通
10  219.158.6.185   AS4837 中国上海 联通
11  *
12  219.158.117.14  AS4837 中国上海 联通
15  59.43.80.146    CN2 中国电信
16  59.43.159.98    CN2 中国电信
17  59.43.39.206    CN2 中国北京 电信
19  193.41.248.129  DMIT 洛杉矶
21  x.x.x.x         DMIT 洛杉矶

四、关键现象总结

两条线路呈现出高度一致的路径结构：

1
2
3
4

日本出口
→ 中国联通（4837）
→ 中国电信（163 / CN2）
→ 美国洛杉矶

并且在第二条线路中还出现了：

联通到电信 CN2 的跨运营商切换。

五、本质：国际流量“国内中转化”

这类线路的本质并不是传统意义上的日美直连优化，而是：

将中国骨干网作为国际流量中转节点使用。

换句话说：

表面是“日本到美国线路”，实际是“日本 → 中国 → 美国”的三段式路径。

六、为什么会出现这种路径？

1. 成本驱动

相比日本直连美国海底光缆：

• 中国国际出口带宽更便宜
• 运营商可以降低上游成本
• 更容易做高性价比产品

本质是用更低成本换取可接受体验。

2. 中国骨干网具备中转能力

中国三大运营商：

中国联通（AS4837）
中国电信（AS4134 / CN2）

具备：

• 大带宽国际出口
• 稳定中美链路
• 成熟骨干调度体系

因此被部分线路作为中转枢纽。

3. 回国体验优化的副作用

这种路径还有一个明显附带收益：

回中国访问速度非常快。

因为流量本身就在中国骨干网中流转。

七、为什么你会感觉变慢？

问题主要集中在三个方面：

1. 路径变长

日本 → 美国（理论最短路径）
变成 日本 → 中国 → 美国。

2. 跨运营商切换

联通 → 电信（163 / CN2）之间的切换
容易带来调度延迟与拥塞风险。

3. 国际优化方向不一致

这类线路的优化重点通常是中国用户体验，而不是国际低延迟。

八、为什么仍然被称为“优化线路”？

因为优化的目标不同。

商家优化的是：

• 中国方向访问体验
• 回国链路质量
• 成本控制与稳定性

但并不等同于：

• 日本到美国的直连优化
• 国际路径纯净性
• 低延迟跨洲通信

九、适用与不适用场景

适合

• 面向中国用户的业务
• 回国访问占比高
• 建站、下载、代理用途

不适合

• 游戏服务器
• 金融或交易系统
• 低延迟国际通信
• 对路径稳定性要求极高的业务

十、一句话总结

所谓“三网优化日美线路”，本质是：

日本入口 + 中国中转 + 美国落地。

十一、结语

这类案例说明一个关键点：

优化线路不等于直连线路，必须通过实际 traceroute 才能判断真实路径。

否则很容易出现误判：

以为是国际直连，实际是在中国骨干网绕了一圈再出海。

一、背景

这台小米电视原本通过插在背面的 U 盘，在局域网中共享图片进行展示。但由于 U 盘损坏，而电视机经已嵌入墙体不方便拆卸，更换存储设备成本较高。

因此，改为采用一种更灵活的方式：

👉 通过 ADB（Android Debug Bridge）直接将图片传输到电视本地存储目录

二、方案原理

小米电视基于 Android 系统，可以通过 ADB 进行远程管理。

核心思路：

• 通过 ADB 连接电视（局域网）
• 将图片推送到系统截图目录 /sdcard/ScreenCapture/
• 使用系统相册或应用读取该目录进行展示

三、环境准备

1. 开启电视 ADB 调试

在电视上开启：

• 开发者选项
• USB 调试 / 网络调试（ADB over TCP）

2. 获取电视 IP 地址

例如：

1

192.168.8.87

四、操作步骤

1️⃣ 连接电视

1

adb connect 192.168.8.87

首次连接会看到：

1
2
3

* daemon not running; starting now at tcp:5037
* daemon started successfully
connected to 192.168.8.87:5555

说明连接成功。

2️⃣ 查看目标目录

1

adb shell ls -l /sdcard/ScreenCapture

作用：

• 确认目录存在
• 查看已有图片
• 避免文件重复

3️⃣ 上传图片（核心步骤）

1

adb push "C:\Users\Administrator\test.png" /sdcard/ScreenCapture/

示例：

1

adb push "C:\Users\Administrator\2026.3.27.png" /sdcard/ScreenCapture/

成功提示：

1

1 file pushed

4️⃣ 确认上传结果

1

adb shell ls -l /sdcard/ScreenCapture

示例输出：

1

-rw-rw---- 1 root sdcard_rw 21751005 2026-03-27 14:27 2026.3.27.png

5️⃣ 删除旧图片

为了避免目录堆积，可以删除旧文件：

1

adb shell rm /sdcard/ScreenCapture/old.png

示例：

1

adb shell rm /sdcard/ScreenCapture/2025.12.26.png

本文整理了香港及国际主要运营商的骨干网测试 IP，适用于：

• 网络延迟测试
• 路由质量分析
• 回程线路判断
• 机房 / VPS 网络对比
• BGP 线路研究

🌍 国际 Tier-1 骨干运营商

🇨🇳 中国大陆运营商骨干网

🇭🇰 香港本地运营商

☁️ 云服务与 CDN 厂商

在网络排障、代理分流、路由健康检测、mwan3 线路监测等场景中，
使用 HTTP 204 (No Content) 作为连通性判断是最干净可靠的方式。

HTTP 204 特点：

• 无正文内容
• 无跳转
• 成功即代表网络畅通
• 适合脚本自动化检测

下面整理目前常用且稳定的 204 服务。

一、国际 204 连通性服务

二、非 204 常用的联网检测地址

⚠ 以下返回 200，但常用于系统检测

三、使用场景

1️⃣ 测试是否成功出国

推荐：

1

http://connectivitycheck.gstatic.com/generate_204

如果失败，说明：

• DNS 被污染
• 代理未生效
• 分流规则错误

2️⃣ 测试是否走 Cloudflare 网络

1

https://cp.cloudflare.com/generate_204

可用于：

• 测试 CDN 是否可达
• 测试代理是否能正常访问 CF

3️⃣ OpenWrt / mwan3 线路健康检测

推荐搭配：

四、命令行测试示例

1

curl -I http://connectivitycheck.gstatic.com/generate_204

成功返回：

1

HTTP/1.1 204 No Content

设置超时：

1

curl -I --max-time 5 http://connectivitycheck.gstatic.com/generate_204

五、自建 204 服务

如果你有 VPS / 家宽服务器，建议自建 204：

Nginx 示例：

1
2
3

location = /generate_204 {
    return 204;
}

访问：

1

https://yourdomain.com/generate_204

优点：

• 不依赖外部服务
• 可用于代理出口检测
• 可用于分流测试
• 不会被墙或被限速影响

六、如何选择 204 服务？