#27 华为手机 v2rayNG 连接不上节点

2026-06-14

在一台华为 Nova 9 手机上研究新版本 v2rayNG 运行原理 🐶。
可以正常启动,也能成功更新订阅,但点击连接后没有任何反应,连接按钮状态不会切换。

同一份订阅在另一台华为 Mate 30 手机上运行正常,因此最初怀疑是系统兼容性问题。

查看 v2rayNG 日志后发现报错:

config error: infra/conf/serial: failed to parse json config > infra/conf: failed to build outbound config with tag proxy > infra/conf: failed to build stream settings for outbound detour > infra/conf: Failed to build TLS config. > common/errors: The feature "allowInsecure" has been removed and migrated to "pinnedPeerCertSha256". Please update your config(s) according to release note and documentation.

从错误信息判断,Xray Core 在加载配置时失败,原因是配置中包含已废弃的 allowInsecure 选项。

最初怀疑是两台手机使用了不同版本的 Xray Core,但检查后发现 Core 版本完全一致。

随后分别导出两台设备的完整配置进行对比,发现:

Mate 30:
allowInsecure = false

Nova 9:
allowInsecure = true

虽然订阅来源相同,但本地配置并不一致。

进入 Nova 9 的 v2rayNG 设置后,关闭 allowInsecure 选项,再次更新订阅,问题立即解决。

原因分析

早期 Xray/V2Ray 配置允许使用:

{
  "allowInsecure": true
}

表示跳过 TLS 证书校验。

新版 Xray Core 已移除此配置项,因此当配置中仍包含该字段时,会直接报错并拒绝启动代理核心。

由于核心启动失败,用户看到的现象就是:

  • App 可以正常打开;
  • 节点列表正常显示;
  • 点击连接无任何反应;
  • VPN 不会启动;
  • 状态栏没有连接图标。

#26 网络代理与隧道技术的本质关系

2026-05-11

网络代理、反向代理、负载均衡、SSH 隧道、VPN 以及各类加密代理协议,本质上都属于同一类问题:如何在不同网络约束下转发通信流量。其差异主要来自工作层级与封装方式不同。

代理(HTTP Proxy、SOCKS5)运行在应用层,客户端显式通过代理发起请求,由代理服务器代为连接目标。它解决的是“替我访问目标”的问题,典型特点是协议感知强、应用可控性高,但覆盖范围有限。

反向代理(如 Nginx、HAProxy)则站在服务端入口,接收外部请求后分发到内部服务,核心价值是负载均衡、安全隔离、缓存与流量治理,本质是“统一入口调度后端资源”。

隧道技术(SSH Tunnel、VLESS、OpenVPN、WireGuard 等)则更抽象,其核心是将一种网络流量封装进另一种连接中传输,在另一端解封还原通信。它强调“透明传输”,不关心上层协议内容,目标是穿越网络限制或构建虚拟通道。

VPN 属于隧道的系统级实现,在网络层建立虚拟网卡,使所有流量透明进入远端网络;而 SSH、TLS-based proxy、V2Ray/Xray 等属于应用或传输层隧道实现,通过不同协议组合增强隐蔽性与适应性。

现代代理体系(如 sing-box、Xray)本质是“协议编排框架”,将代理、隧道、加密、传输层解耦组合,实现灵活网络接入能力。

总体来看:代理强调“代为连接”,反向代理强调“流量治理”,隧道强调“封装传输”,VPN强调“网络重构”。它们共同构成从应用层到网络层的完整通信抽象体系。

#23 Wi-Fi 6 还没用上,Wi-Fi 7 又来了

2023-11-27
标准 名称 年份 频率(GHz) 理论最大速率 备注
IEEE 802.11 Wi-Fi 0 1997 2.4 2 Mbps
IEEE 802.11b Wi-Fi 1 1999 2.4 11 Mbps
IEEE 802.11a Wi-Fi 2 1999 5 54 Mbps 正交频分复用(OFDM)
IEEE 802.11g Wi-Fi 3 2003 2.4 54 Mbps 正交频分复用(OFDM),兼容 802.11b
IEEE 802.11i 草案 WPA 2003 -- --
IEEE 802.11i-2004 WPA 2 2004 -- --
IEEE 802.11n Wi-Fi 4 2009 2.4/5 600 Mbps 最多 4 个 MIMO
IEEE 802.11ac Wi-Fi 5 2014 5 最多 8 个 MIMO;下行 MU-MIMO (2016 Wave2)
IEEE 802.11i-2018 WPA 3 2018 -- --
IEEE 802.11ax Wi-Fi 6 2019 2.4/5 9.6 Gbps 上下行 MU-MIMO
Wi‑Fi 6E 2020 6
IEEE 802.11be Wi-Fi 7 2024 2.4/5/6 23 Gbps
  • 802.11a 其实早于 802.11b 提出,只是因为一些非技术原因,推广滞后
  • 2000 年,Wi-Fi 这个词被提出,无线以太网兼容性联盟(WECA)更名为 Wi-Fi 联盟(Wi-Fi Alliance,缩写 WFA)
  • Wi-Fi 一词,国内通常读作 歪fai,有一些人引经据典提出过不同看法引发争议
  • Wi-Fi 0、1、2、3 不是官方认定的名称
  • WEP:有线等效加密(Wired Equivalent Privacy),又称无线加密协议(Wireless Encryption Protocol)
  • WPA:Wi-Fi Protected Access (Wi-Fi 访问保护)

现状

市面上大部分路由器都是支持 Wi-Fi 1 - 5,常常可以在广告上看到 IEEE 802.11a/b/g/n/ac 字样。
旗舰型,贵一点的(至少 300+),支持 Wi-Fi 6。

我没有做过这方面研究和对比,只能说理论上:

  1. Wi-Fi 6 速率上限有了提升,网络质量也有优化,同时能耗降低(TWT),能够同时支持更多终端连接(OFDMA),同时支持更多并发数据传输(MU-MIMO)。
  2. Wi-Fi 6E 引入了 6GHz 频段,能支持更高的速度和更低的延迟。

目前我家的路由器,手机,其他设备大多还不支持 Wi-Fi 6。
我家的有线网络用的 5 类线,所以我家理论上最高网速也就 100Mbps(12MB/s)。

Wi-Fi 7

  1. 支持最大 320MHz 带宽(Wi-Fi 6 是 160MHz)
    新的带宽模式:连续 240MHz、非连续 160+80MHz、连续 320 MHz、非连续 160+160MHz
    主要作用是提升 QoS(减少延迟,降低丢包率)
  2. 支持 Multi-RU 机制
  3. 引入更高阶的 4096-QAM 调制技术(Wi-Fi 6 是 1024-QAM)
  4. 引入 Multi-Link 多链路机制
  5. 支持多 AP 间的协同调度
    网络漫游问题

我不太懂。
场景应该是一些工业和商业场景。家用的话,可能只有土豪的游戏设备(VR 游戏?)才能用得上,或者发烧友自己搭建的家庭网络设施。
想必和 Wi-Fi 6 / 5G 一样,对绝大多数普通人来说,只是一个新的营销噱头。

参考资料与拓展阅读

Wi-Fi(发音: /ˈwaɪfaɪ/),又称“无线网络”,是 Wi-Fi 联盟的商标,一个基于 IEEE 802.11 标准的无线局域网技术。“Wi-Fi”常写作“WiFi”或“Wifi”,但是这些写法并没有被 Wi-Fi 联盟认可。

1999 年,几家富有远见的公司联合起来组成了一个全球性非营利性协会——无线以太网兼容性联盟(Wireless Ethernet Compatibility Alliance, WECA),其目标是使用一种新的无线网络技术,无论品牌如何,都能带来最佳的用户体验。在 2000 年,该小组采用术语“Wi-Fi”作为其技术工作的专有名称,并宣布了正式名称:Wi-Fi Alliance。

第七代 WiFi 无线网络,速度可高达 30Gbps,是 WiFi 6 最高 9.6Gbps 速率的三倍之多。相比于 Wi-Fi 6,WiFi 7 将引入 CMU-MIMO 技术最多可支持 16 条数据流,8 车道变 16 车道,妥妥的星际高速公路,其次 WiFi 7 除传统的 2.4GHz 和 5GHz 两个频段,还将新增支持 6 GHz 频段,并且三个频段能同时工作。
2021 年 12 月,联发科宣布 2022 年初将推出 WiFi 7 网络,此前数据显示其网速是 Wi-Fi 6 的 3 倍多。在 2022 年世界移动通信大会(MWC 2022)上,中兴推出 WiFi 7 标准的产品。

#20 ping github.com 得到 127.0.0.1 问题

2022-10-27
git clone git@github.com:tornado/tornado
Cloning into 'tornado'...
ssh: connect to host github.com port 22: Connection refused
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.
ping github.com

正在 Ping github.com [::1] 具有 32 字节的数据:
来自 ::1 的回复: 时间<1ms
来自 ::1 的回复: 时间<1ms
来自 ::1 的回复: 时间<1ms

::1 的 Ping 统计信息:
    数据包: 已发送 = 3,已接收 = 3,丢失 = 0 (0% 丢失),
往返行程的估计时间(以毫秒为单位):
    最短 = 0ms,最长 = 0ms,平均 = 0ms
Control-C
ping -4 github.com

正在 Ping github.com [127.0.0.1] 具有 32 字节的数据:
来自 127.0.0.1 的回复: 字节=32 时间<1ms TTL=64
来自 127.0.0.1 的回复: 字节=32 时间<1ms TTL=64
来自 127.0.0.1 的回复: 字节=32 时间<1ms TTL=64

127.0.0.1 的 Ping 统计信息:
    数据包: 已发送 = 3,已接收 = 3,丢失 = 0 (0% 丢失),
往返行程的估计时间(以毫秒为单位):
    最短 = 0ms,最长 = 0ms,平均 = 0ms
Control-C
nslookup github.com
Server:         192.168.31.1
Address:        192.168.31.1#53

Non-authoritative answer:
Name:   github.com
Address: 127.0.0.1
Name:   github.com
Address: ::1

配置 DNS 为 AliDNS 223.5.5.5233.6.6.6

nslookup github.com
Server:         223.5.5.5
Address:        223.5.5.5#53

Non-authoritative answer:
Name:   github.com
Address: 20.205.243.166

问题依旧。

ping 20.205.243.166

正在 Ping 20.205.243.166 具有 32 字节的数据:
请求超时。
请求超时。
请求超时。

20.205.243.166 的 Ping 统计信息:
    数据包: 已发送 = 3,已接收 = 0,丢失 = 3 (100% 丢失),
Control-C
ping baidu.com

正在 Ping baidu.com [39.156.66.10] 具有 32 字节的数据:
来自 39.156.66.10 的回复: 字节=32 时间=23ms TTL=52
来自 39.156.66.10 的回复: 字节=32 时间=24ms TTL=52
来自 39.156.66.10 的回复: 字节=32 时间=23ms TTL=52

39.156.66.10 的 Ping 统计信息:
    数据包: 已发送 = 3,已接收 = 3,丢失 = 0 (0% 丢失),
往返行程的估计时间(以毫秒为单位):
    最短 = 23ms,最长 = 24ms,平均 = 23ms
Control-C

总结

  1. hosts 没有特殊配置
  2. 改成可用 DNS,问题没有修复
  3. ipconfig /flushdns 也不管用
  4. 重启也没有好

那就奇怪了,这个 ping 里面的本地回环地址是哪里来的呢?

最后,

ipconfig /displaydns 可以看到,还是用的回环地址
ipconfig /all 发现还有一个 DNSv6 配置。。。

DNSv6 设置成 AliDNS 的 IPv6 地址:2400:3200::12400:3200:baba::1 再试,

ping github.com

正在 Ping github.com [20.205.243.166] 具有 32 字节的数据:
请求超时。
请求超时。
请求超时。
请求超时。

20.205.243.166 的 Ping 统计信息:
    数据包: 已发送 = 4,已接收 = 0,丢失 = 4 (100% 丢失),

终于好了。😂

事情的起源是 git clone 失败,最后 git clone 可以了。
ping 不通,可能是网络问题,也可能是 github 网络配置。
这就不管了。

#19 办公网络中的安全问题

2022-04-14

同事发来消息,说是我的电脑经过安全扫描,判断有风险。提了以下几条改进意见:

  1. SMB 共享,风险高,希望限制访问,并强制执行消息签名。
    改进:其实现在我很少使用 SMB 共享了,直接关闭了事。
    PS: 其实在用 SMB 共享,所以重新开启 smbd 并禁止匿名访问。

  2. 开启了 IP 转发,风险中,建议关闭。
    IP 转发功能对我的工作是非常必要的,不能关闭
    之前的文章, 2021/05/09, VPN 与 NAT 有讲过这个问题。
    改进:调整 iptables 规则,only ACCEPT 指定链路 FORWARD

  3. 3Proxy HTTP 代理(端口 10809)只做透明请求远程溢出,风险高,建议升级 3Proxy 版本。
    我没有安装什么 3Proxy, 这个端口是其他 HTTP 代理服务的端口(不排除底层使用了 3Proxy)
    改进:我直接将其改成监听 127.0.0.1 了事