Posts on 猫猫鱼的小窝

阿里云 ECS 控制台远程连接失败、云助手不响应、OSS 内网超时——Tailscale 与阿里云 100.x 段冲突排查全过程

xxx@example.com (catcatyu) — Wed, 10 Jun 2026 12:40:15 +0800

阿里云 ECS 控制台远程连接失败、云助手不响应、OSS 内网超时——Tailscale 与阿里云 100.x 段冲突排查全过程

作者：catcatyu（xxx@example.com）

一、现象：从控制台远程连接打不开开始

某天准备登一台跑在杭州地域的阿里云 ECS 改点东西，结果发现三件事同时挂了：

阿里云控制台的「远程连接」（Workbench / VNC）打不开，点击之后转圈，最后报 “连接失败”；
「云助手」（Cloud Assistant / ECS Run Command）也不响应，下发任何命令都一直显示「执行中」，永远不返回结果；
业务侧报错：访问 oss-cn-hangzhou-internal.aliyuncs.com（OSS 内网域名）超时，对象读写全部 hang 住。

但是奇怪的是：

SSH（外网公网 IP）还能正常登录；
ping 8.8.8.8、ping baidu.com 都通；
业务里访问外网 API 也都正常。

这就说明 ECS 本身和外网都没问题，坏的是阿里云自己的内网链路——控制台远程连接、云助手、OSS 内网域名，全都走阿里云内网 100.x 段。

这台机器装了 Tailscale 自建 Headscale，这是个非常重要的伏笔。

二、最小化复现：定位到内网域名超时

先确认 OSS 内网到底是 DNS 挂了还是网络挂了：

1
2
3
4


$ nslookup oss-cn-hangzhou-internal.aliyuncs.com
Name:   oss-cn-hangzhou-internal.aliyuncs.com
Address: 100.118.28.52
Address: 100.118.28.43

DNS 没问题，解析出来两个 100.118.x.x 的地址。

1
2
3


$ timeout 10 telnet 100.118.28.52 443
Trying 100.118.28.52...
（10 秒之后超时）

TCP 不通。再 ping 一下 ECS metadata 服务器（这也是阿里云内部接口）：

1
2


$ ping -c 3 100.100.2.136
3 packets transmitted, 0 received, 100% packet loss

也不通。再试一下 metadata HTTP 接口：

1
2


$ curl --connect-timeout 5 http://100.100.100.200/latest/meta-data/region-id
（超时，无输出）

也不通。结论：凡是阿里云内网 100.x.x.x 段，全部访问不到。

到这里就明确了：阿里云控制台远程连接挂掉、云助手不响应，本质上跟 OSS 内网挂掉是同一个问题——它们都需要走 ECS 到 100.x 阿里云内网管控面的链路。

三、排查防火墙

第一反应是 ufw 或者 iptables 把内网段拦了。

1
2


$ sudo ufw status verbose
Status: inactive

ufw 是关的。再看 iptables：

1
2
3
4
5
6
7
8
9


$ sudo iptables -L -v -n
...
Chain ts-input (1 references)
 pkts bytes target  prot opt in        out  source            destination
    0     0 ACCEPT  0   --  lo         *    100.64.0.1        0.0.0.0/0
    0     0 RETURN  0   --  !tailscale0 *   100.115.92.0/23   0.0.0.0/0
 113K 5983K DROP    0   --  !tailscale0 *   100.64.0.0/10     0.0.0.0/0
 189K   26M ACCEPT  0   --  tailscale0  *   0.0.0.0/0         0.0.0.0/0
...

罪魁祸首找到了。

ts-input 是 Tailscale 自己装的 iptables 链，最关键的是这条：

DROP  !tailscale0  100.64.0.0/10  0.0.0.0/0

翻译一下：从不是 tailscale0 的网卡进来的包，只要源地址在 100.64.0.0/10 这个段里，全部丢掉。

而这条 DROP 已经累积了 113000+ 个被丢的包，将近 6MB 流量——所有访问阿里云内网失败的包，都被这条规则吞了。

四、根因：CGNAT 段撞车

为啥 Tailscale 要装这条 DROP？

Tailscale（包括自建 Headscale）默认使用 100.64.0.0/10 这个 CGNAT（运营商级 NAT）地址段给 tailnet 里的节点分配虚拟 IP。这条 DROP 是 Tailscale 的反伪造防御：从外部网卡进来的包，源 IP 不可能是 tailnet 内部地址，如果有那就是欺骗，丢掉。

但是！ 阿里云华东 1（杭州）的内网管控面，也用了 100.x 段：

资源	地址段
Tailscale CGNAT（虚拟）	`100.64.0.0/10`（即 `100.64.0.0` ～ `100.127.255.255`）
阿里云 ECS metadata	`100.100.100.200`、`100.100.2.136`
阿里云 OSS 内网（杭州）	`100.118.28.0/24` 等
阿里云云助手/Workbench 回调	部分 100.x 段

它们全在 100.64.0.0/10 区间内。

链路是这样的：

ECS 发起对 100.118.28.52（OSS 内网）的连接，包从 eth0 出去，OSS 服务回包；
回包从 eth0 进来，源 IP 是 100.118.28.52；
进了 INPUT 链 → ts-input 链；
源 IP 在 100.64.0.0/10 里 + 进来的网卡不是 tailscale0 → DROP；
应用层看到的就是连接超时。

控制台远程连接打不开、云助手不响应，也是同样的机制：阿里云管控面发到这台 ECS 的回调走的就是这条链路，全被丢了。

五、修复方案

方案 A：关掉 Tailscale 的 netfilter 接管（推荐）

最干净的办法是让 Tailscale 不要再托管 iptables，让默认 ACCEPT 策略接管。

1
2


$ sudo tailscale set --netfilter-mode=off
Warning: netfilter=off; configure iptables yourself.

这条命令告诉 tailscaled：「我不要你的 iptables 规则」。之后 tailscaled 会把它自己加的 ts-input、ts-forward 等链清掉。

立刻验证：

1
2


$ curl --connect-timeout 5 http://100.100.100.200/latest/meta-data/region-id
cn-hangzhou

通了！再试 OSS：

1
2
3


$ curl -sI http://oss-cn-hangzhou-internal.aliyuncs.com
HTTP/1.1 404 Not Found
Server: AliyunOSS

Server: AliyunOSS 头就证明已经打到 OSS 了（404 是因为我们没指定 bucket，正常）。同时阿里云控制台的远程连接和云助手也都恢复。

代价：失去了 Tailscale 自己装的「外部网卡上源 IP 伪造成 CGNAT 段的包丢掉」这条防御。但是在阿里云 VPC 内部，攻击者要伪造这种源 IP 包到你的 ECS，几乎做不到（VPC 自身的 underlay 会先把它清掉）。所以这个防御在 VPC 场景下几乎没有实际作用，关掉是安全的。

而且对 Tailscale 的实际功能没有影响：

tailscale0 接口还在；
节点间互相访问还能走；
路由还是好的；
唯一不工作的就是那条没意义的 DROP。

方案 B：保留 netfilter，加豁免规则（不推荐）

如果非要保留 Tailscale 的完整 iptables 规则，可以加一条豁免，让阿里云 OSS 段不被 DROP：

1
2


# 在 ts-input 链的 DROP 规则之前插入豁免
sudo iptables -I ts-input 3 -s 100.118.0.0/16 -j RETURN

但是这条规则不持久：

tailscaled 重启时会重建 ts-input 链，豁免被冲掉；
tailscaled 运行时如果对账（比如对端变化、ACL 推送），也可能重建。

要让它持久得写 systemd drop-in：

1
2
3
4
5
6
7
8
9


sudo mkdir -p /etc/systemd/system/tailscaled.service.d/
sudo tee /etc/systemd/system/tailscaled.service.d/aliyun-exception.conf > /dev/null <<'EOF'
[Service]
ExecStartPost=/bin/sh -c 'sleep 3 && \
  /usr/sbin/iptables -C ts-input -s 100.118.0.0/16 -j RETURN 2>/dev/null || \
  /usr/sbin/iptables -I ts-input 3 -s 100.118.0.0/16 -j RETURN'
EOF
sudo systemctl daemon-reload
sudo systemctl restart tailscaled

但是 tailscaled 启动到 ExecStartPost 跑完之间仍然有几秒的窗口期，OSS 会短暂断连。所以一般场景下我还是推荐方案 A。

还要注意：上面的豁免段 100.118.0.0/16 只覆盖了杭州地域的 OSS。如果你的 ECS 在别的地域、或者要访问别的内网服务（如 RDS、Redis 内网），需要查到对应的 100.x 段一起豁免。最稳的查法是直接 nslookup 对应内网域名拿 IP，再确定它的 /16 或 /24。

方案 C：换 Tailscale 的 IP 段（理论上可行，但复杂）

Headscale 配置文件里可以改 prefixes.v4：

1
2


prefixes:
  v4: 100.64.0.0/10  # 默认

如果改成不和阿里云冲突的段（比如自建一个 RFC1918 段），就能彻底避开。但是：

所有已注册节点都要重新分配 IP；
部分 Tailscale 客户端对非 CGNAT 段的支持有限制；
改完 ACL、DNS 都要重写。

对于个人/小团队的 Tailscale 部署，这个改动成本远大于方案 A。不推荐。

六、为什么阿里云控制台和云助手也会挂

很多人不理解：我自己访问 OSS 失败可以理解，控制台远程连接、云助手为什么会跟着挂？

是因为这两个东西的工作机制：

云助手（Cloud Assistant）：ECS 里跑了一个 AliyunAssistClient 守护进程，它需要主动连接阿里云内网的管控接口拉取要执行的命令。这个接口的接入点同样是 100.x 内网地址，被 DROP 之后客户端连不上服务器，控制台下发的命令就永远是「执行中」。
控制台远程连接（Workbench/VNC）：浏览器走的是阿里云控制台 → 阿里云内网中转 → ECS metadata/agent 通道。中转回来的握手包源 IP 在 100.x 段，被同一条 DROP 吞掉。

所以这是个典型的「打开了 Tailscale 之后阿里云任何依赖内网管控的功能都坏」综合症，看到一个症状要联想到一片。

七、检查清单

如果你在阿里云上跑了 Tailscale / Headscale 并且遇到下面任何一个症状，都先去看 iptables -L ts-input -n -v 那条 DROP 的 pkts 计数：

控制台「远程连接」打不开；
「云助手」下发的命令永远不返回；
curl http://100.100.100.200/latest/meta-data/ 超时（元数据服务）；
OSS 内网域名 oss-*-internal.aliyuncs.com 超时；
RDS、Redis 内网连接超时；
SLS 日志服务内网接口超时；
系统初始化时 cloud-init 卡很久；
ECS 自动续费、自动伸缩等管控操作异常。

如果 DROP 计数在涨，基本就是这个问题，按方案 A 关掉 netfilter 即可。

八、复盘

这个坑挺典型，关键学习点：

DROP 链的统计计数是最快的指纹。iptables -L -v -n 看到一条 DROP 规则上有大量 pkts/bytes 累积，就要立刻怀疑它。
CGNAT 段 100.64.0.0/10 是公开标准段（RFC 6598），任何使用方都不能假定自己独占。阿里云、Tailscale、容器网络、Kubernetes 的 Cilium 等等都可能占用这个段，多个一起装就容易撞车。
「我看到的症状」和「真正的根因」之间通常隔了几层。最初看到的是控制台远程连接失败，最后定位到的是 Tailscale 的 iptables 规则——中间隔着 OSS 超时、metadata 超时、DROP 计数三层证据。
本地 SSH 还能用的时候不要急着重启。这种 iptables 规则问题，重启不会修，只会让你失去能继续排查的入口。

排查工具备忘：

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


# DNS
nslookup oss-cn-hangzhou-internal.aliyuncs.com

# TCP 探测
timeout 10 telnet  

# 看防火墙状态
sudo ufw status verbose
sudo iptables -L -v -n
sudo iptables -L ts-input -v -n   # 直接看 Tailscale 链

# Tailscale 状态
tailscale debug prefs | grep -i netfilter
tailscale status

# Aliyun metadata 自检
curl --connect-timeout 5 http://100.100.100.200/latest/meta-data/region-id

# 关 Tailscale netfilter（修复）
sudo tailscale set --netfilter-mode=off

本文2026-06-10首发于猫猫鱼的小窝，最后修改于2026-06-10

Xray 新版 VLESS Reverse Proxy 单隧道承载多端口内网穿透

xxx@example.com (catcatyu) — Mon, 08 Jun 2026 14:20:46 +0800

Xray 新版 VLESS Reverse Proxy 单隧道承载多端口内网穿透

作者：catcatyu（xxx@example.com）

前言

之前写过一篇 Xray 反向代理多端口内网穿透配置，当时使用的是旧版顶层 reverse.portals / reverse.bridges 写法。那套方案能跑，但每暴露一个服务就要维护一组 portal/bridge tag 和一组 .internal 域名，服务数量多了以后配置会变得很长。

这次把同类场景更新为新版 VLESS reverse proxy 写法，并且没有继续采用“一项服务一条反向隧道”的保守迁移方式，而是改成 一条 VLESS reverse 隧道承载多个公网端口。

为了避免泄露真实环境，本文中的域名、IP、UUID、服务名、密码、密钥均已脱敏。直接复制配置前需要替换占位符。

迁移目标

原来的旧结构大概是这样：

1
2
3
4


公网 80   -> external-web     -> portal-web     -> bridge-web     -> 127.0.0.1:80
公网 8081 -> external-api     -> portal-api     -> bridge-api     -> 127.0.0.1:8001
公网 8082 -> external-admin   -> portal-admin   -> bridge-admin   -> 127.0.0.1:8002
公网 2222 -> external-ssh     -> portal-ssh     -> bridge-ssh     -> 127.0.0.1:22

每一行都要在公网端写 portal，在桥接端写 bridge，还要维护一条用于注册隧道的 .internal 域名路由。

更新后的结构：

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


公网 80
公网 8081
公网 8082
公网 2222
公网 8083
公网 8084
公网 8085
    |
    v
同一个 reverse-out
    |
    v
同一个 reverse-in
    |
    +-- 目标端口 80   -> 127.0.0.1:80
    +-- 目标端口 8081 -> 127.0.0.1:8001
    +-- 目标端口 8082 -> 127.0.0.1:8002
    +-- 目标端口 2222 -> 127.0.0.1:22

公网端只负责把外部入口全部转进同一个 reverse-out，桥接端再根据请求保留下来的目标端口做二次分流。

为什么可以这么做

dokodemo-door 入站可以把公网端口上的连接包装成一个带目标地址和目标端口的请求。公网端把这些请求交给 VLESS reverse proxy 后，桥接端的 reverse-in 仍然可以基于 port 做路由匹配。

所以我们不再需要：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
  "reverse": {
    "portals": [
      {
        "tag": "portal-web",
        "domain": "tunnel-web.internal"
      }
    ]
  }
}

也不再需要桥接端的：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
  "reverse": {
    "bridges": [
      {
        "tag": "bridge-web",
        "domain": "tunnel-web.internal"
      }
    ]
  }
}

新版写法把反向代理关系直接写在 VLESS client/outbound 里。

公网服务器侧：

1
2
3
4
5
6
7
8


{
  "id": "",
  "flow": "xtls-rprx-vision",
  "email": "bridge-single@example",
  "reverse": {
    "tag": "reverse-out"
  }
}

桥接端侧：

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


{
  "protocol": "vless",
  "tag": "interconn",
  "settings": {
    "address": "proxy.example.com",
    "port": 443,
    "encryption": "none",
    "id": "",
    "flow": "xtls-rprx-vision",
    "reverse": {
      "tag": "reverse-in"
    }
  }
}

注意桥接端 outbound 必须使用 simplified outbound config style，也就是把 address、port、id、flow、reverse 直接写在 settings 下面。不要再写成旧的 vnext.users 结构，否则新版 reverse 会报错。

公网服务器配置

下面只展示核心配置。假设公网服务器原来已经有一个 VLESS + REALITY + Vision 入站，tag 为 interconn。

VLESS 入站

保留原有普通客户端，同时新增一个专门给桥接端使用的 reverse client：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


{
  "tag": "interconn",
  "listen": "0.0.0.0",
  "port": 443,
  "protocol": "vless",
  "settings": {
    "clients": [
      {
        "id": "",
        "flow": "xtls-rprx-vision"
      },
      {
        "id": "",
        "flow": "xtls-rprx-vision",
        "email": "bridge-single@example",
        "reverse": {
          "tag": "reverse-out"
        }
      }
    ],
    "decryption": "none"
  },
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "show": false,
      "dest": "www.example.com:443",
      "xver": 0,
      "serverNames": ["www.example.com"],
      "privateKey": "",
      "shortIds": [""]
    }
  },
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls", "quic"]
  }
}

如果你的入口是普通 TLS，就保留原来的 tlsSettings。这里的重点是 clients 里新增了带 reverse.tag 的桥接客户端。

公网入口

公网端仍然用 dokodemo-door 暴露多个端口：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


[
  {
    "tag": "external-web",
    "listen": "0.0.0.0",
    "port": 80,
    "protocol": "dokodemo-door",
    "settings": {
      "address": "0.0.0.0",
      "port": 80,
      "network": "tcp"
    }
  },
  {
    "tag": "external-api",
    "listen": "0.0.0.0",
    "port": 8081,
    "protocol": "dokodemo-door",
    "settings": {
      "address": "0.0.0.0",
      "port": 8081,
      "network": "tcp"
    }
  },
  {
    "tag": "external-ssh",
    "listen": "0.0.0.0",
    "port": 2222,
    "protocol": "dokodemo-door",
    "settings": {
      "address": "0.0.0.0",
      "port": 2222,
      "network": "tcp"
    }
  }
]

settings.port 要保留和公网入口一致，因为桥接端后面会靠这个目标端口分流。

路由规则

旧配置通常会写成多条：

1
2
3
4


{
  "inboundTag": ["external-web"],
  "outboundTag": "portal-web"
}

新版单隧道可以合并为一条：

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


{
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "external-web",
          "external-api",
          "external-admin",
          "external-ssh",
          "external-service-a",
          "external-service-b"
        ],
        "outboundTag": "reverse-out"
      },
      {
        "type": "field",
        "inboundTag": ["interconn"],
        "outboundTag": "direct"
      }
    ]
  }
}

reverse-out 不需要出现在 outbounds 数组里。它来自 VLESS client 的：

1
2
3


"reverse": {
  "tag": "reverse-out"
}

outbounds 里保留默认出口即可：

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


{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

桥接端配置

桥接端不再需要顶层 reverse.bridges。它只需要一个主动连接公网服务器的 VLESS outbound。

单 reverse outbound

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


{
  "protocol": "vless",
  "tag": "interconn",
  "settings": {
    "address": "proxy.example.com",
    "port": 443,
    "encryption": "none",
    "id": "",
    "flow": "xtls-rprx-vision",
    "reverse": {
      "tag": "reverse-in"
    }
  },
  "streamSettings": {
    "network": "tcp",
    "security": "reality",
    "realitySettings": {
      "fingerprint": "chrome",
      "serverName": "www.example.com",
      "publicKey": "",
      "shortId": "",
      "spiderX": "/"
    }
  }
}

如果公网端是普通 TLS，桥接端就改成：

1
2
3
4
5
6
7
8


{
  "network": "tcp",
  "security": "tls",
  "tlsSettings": {
    "serverName": "proxy.example.com",
    "fingerprint": "chrome"
  }
}

本地服务出口

每个本地服务仍然用 freedom.redirect：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47


[
  {
    "tag": "out-web",
    "protocol": "freedom",
    "settings": {
      "redirect": "127.0.0.1:80",
      "finalRules": [
        {
          "action": "allow",
          "network": "tcp",
          "ip": ["127.0.0.1"],
          "port": "80"
        }
      ]
    }
  },
  {
    "tag": "out-api",
    "protocol": "freedom",
    "settings": {
      "redirect": "127.0.0.1:8001",
      "finalRules": [
        {
          "action": "allow",
          "network": "tcp",
          "ip": ["127.0.0.1"],
          "port": "8001"
        }
      ]
    }
  },
  {
    "tag": "out-ssh",
    "protocol": "freedom",
    "settings": {
      "redirect": "127.0.0.1:22",
      "finalRules": [
        {
          "action": "allow",
          "network": "tcp",
          "ip": ["127.0.0.1"],
          "port": "22"
        }
      ]
    }
  }
]

finalRules 不是必须在所有旧配置里都出现，但新版配置里建议显式写上，只允许 reverse 流量访问需要暴露的本地端口。

按目标端口分流

这是单隧道方案的关键：

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


{
  "routing": {
    "rules": [
      {
        "type": "field",
        "inboundTag": ["reverse-in"],
        "port": "80",
        "outboundTag": "out-web"
      },
      {
        "type": "field",
        "inboundTag": ["reverse-in"],
        "port": "8081",
        "outboundTag": "out-api"
      },
      {
        "type": "field",
        "inboundTag": ["reverse-in"],
        "port": "2222",
        "outboundTag": "out-ssh"
      }
    ]
  }
}

这里匹配的是公网 dokodemo-door 保留下来的目标端口，不是桥接端本地服务的端口。例如公网 8081 最后可以转发到桥接端本机 127.0.0.1:8001。

验证流程

先在两端验证配置语法：

1
2


xray run -test -config /usr/local/etc/xray/config.json
xray run -test -config /usr/local/etc/xray/bridge-config.json

确认通过后再重启：

1
2


systemctl restart xray
systemctl restart xray-bridge

公网端看日志，应该能看到外部入口进入同一个 reverse-out：

1
2
3


external-web -> reverse-out
external-api -> reverse-out
external-ssh -> reverse-out

桥接端看配置摘要，应该没有顶层 reverse，并且 VLESS outbound 带有 reverse：

1
2


has_top_reverse false
reverse_outbounds [('interconn', 'vless', true)]

最后逐个测公网端口：

1
2
3


curl -I http://proxy.example.com/
curl -I http://proxy.example.com:8081/
ssh -p 2222 root@proxy.example.com

如果 SSH 能返回 banner，HTTP 服务能返回对应后端响应，说明公网入口、VLESS reverse 隧道和桥接端本地 redirect 都已经打通。

回滚

迁移前建议在两端都做备份：

1
2


cp /usr/local/etc/xray/config.json /usr/local/etc/xray/config.json.bak-before-single-vless-reverse
cp /usr/local/etc/xray/bridge-config.json /usr/local/etc/xray/bridge-config.json.bak-before-single-vless-reverse

如果切换后发现某个端口异常，可以直接恢复旧配置：

1
2


cp /usr/local/etc/xray/config.json.bak-before-single-vless-reverse /usr/local/etc/xray/config.json
systemctl restart xray

桥接端同理：

1
2


cp /usr/local/etc/xray/bridge-config.json.bak-before-single-vless-reverse /usr/local/etc/xray/bridge-config.json
systemctl restart xray-bridge

取舍

单隧道方案的优点：

配置明显更短；
不需要维护多组 .internal 域名；
只需要一个 bridge UUID；
多端口入口的流量都走同一条 reverse 通道，管理成本低；
从旧 reverse.portals/bridges 迁移到新版 VLESS reverse proxy 后，结构更贴近 Xray 当前推荐写法。

缺点也很明确：

所有服务共用一条 reverse 通道，故障影响面更大；
桥接端依赖目标端口路由，如果公网端 dokodemo-door 的目标端口写错，分流会错；
迁移时必须两端同时切换，不能只改公网端或只改桥接端。

如果是生产环境，保守做法是一项服务一条 reverse 隧道，出错时只影响单个服务。如果是在维护窗口内追求配置简洁和更少的连接管理开销，单隧道方案更合适。

本文2026-06-08首发于猫猫鱼的小窝，最后修改于2026-06-08

使用新版 VLESS Reverse Proxy 实现海外入口回国内出口

xxx@example.com (catcatyu) — Mon, 08 Jun 2026 14:00:17 +0800

使用新版 VLESS Reverse Proxy 实现海外入口回国内出口

作者：catcatyu（xxx@example.com）

前言

这篇记录一次比较典型的“回国出口”配置：公网服务器在海外，朋友仍然连接这台海外服务器的 VLESS/XTLS 入口，但访问国内网站时，流量会通过一条反向隧道转回国内机器，再从国内宽带出口访问目标网站。

整体目标是：

朋友继续使用公网服务器原来的 443 VLESS 入口；
国内机器不需要公网 IP，也不需要在路由器上做端口转发；
只把国内域名和国内 IP 转回国内出口，其他流量仍走海外服务器原来的出口；
使用 Xray 新版 VLESS reverse proxy 写法，不再使用旧的 reverse.portals / reverse.bridges。

为了避免泄露真实环境，本文中的域名、UUID、证书路径、用户标识都已经脱敏。直接复制前需要把占位符替换成自己的值。

架构

朋友客户端
    |
    | VLESS + TLS/REALITY + Vision
    v
海外公网服务器
    |
    | 命中 geosite:cn / geoip:cn
    | 转入 VLESS reverse proxy
    v
国内出口机器
    |
    | freedom 直连
    v
国内网站

反向连接由国内出口机器主动发起到海外服务器。海外服务器只需要保留原来的公网 443 入站，国内机器不暴露任何公网端口。

新旧写法区别

旧写法通常会在配置顶层写：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


{
  "reverse": {
    "portals": [
      {
        "tag": "portal",
        "domain": "tunnel.internal"
      }
    ]
  }
}

新版 VLESS reverse proxy 不再依赖顶层 reverse.portals / reverse.bridges。它把 reverse 写进 VLESS client 或 VLESS outbound：

公网服务器侧：

1
2
3
4
5
6
7
8


{
  "id": "",
  "flow": "xtls-rprx-vision",
  "email": "cn-bridge@example",
  "reverse": {
    "tag": "cn-reverse-out"
  }
}

国内出口机器侧：

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


{
  "protocol": "vless",
  "settings": {
    "address": "proxy.example.com",
    "port": 443,
    "encryption": "none",
    "id": "",
    "flow": "xtls-rprx-vision",
    "reverse": {
      "tag": "cn-reverse-in"
    }
  }
}

公网服务器上的 cn-reverse-out 会表现为一个可路由的 outbound；国内出口机器上的 cn-reverse-in 会表现为一个可匹配的 inbound。

公网服务器配置

下面只展示关键片段。假设公网服务器原来已经有一个 VLESS + TLS/REALITY + Vision 入站，tag 为 vless-in。

入站新增两个用户

一个用户给国内机器建立反向隧道，一个用户给朋友使用。不要让朋友和自己共用同一个 UUID，否则服务端无法按用户分流。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


{
  "tag": "vless-in",
  "listen": "::",
  "port": 443,
  "protocol": "vless",
  "settings": {
    "clients": [
      {
        "id": "",
        "flow": "xtls-rprx-vision",
        "email": "self@example"
      },
      {
        "id": "",
        "flow": "xtls-rprx-vision",
        "email": "cn-bridge@example",
        "reverse": {
          "tag": "cn-reverse-out"
        }
      },
      {
        "id": "",
        "flow": "xtls-rprx-vision",
        "email": "cnfriend@example"
      }
    ],
    "decryption": "none"
  },
  "streamSettings": {
    "network": "tcp",
    "security": "tls"
  },
  "sniffing": {
    "enabled": true,
    "destOverride": ["http", "tls", "quic"],
    "routeOnly": true
  }
}

如果你的入口是 REALITY，就保留原来的 realitySettings；如果是普通 TLS 证书，就保留原来的 tlsSettings。这里的核心不是 TLS 还是 REALITY，而是新增的 reverse.tag 和朋友独立用户。

路由规则

只把朋友访问国内域名和国内 IP 的流量转进反向隧道：

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


{
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "user": ["cnfriend@example"],
        "domain": ["geosite:cn"],
        "outboundTag": "cn-reverse-out"
      },
      {
        "type": "field",
        "user": ["cnfriend@example"],
        "ip": ["geoip:cn"],
        "outboundTag": "cn-reverse-out"
      }
    ]
  }
}

如果原配置里有 geoip:cn 或 geosite:cn 走 block 的规则，上面两条规则要放在 block 规则之前，否则国内流量会先被拦截。

outbounds 里仍然要保留一个默认出口，比如：

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


{
  "outbounds": [
    {
      "tag": "direct",
      "protocol": "freedom"
    },
    {
      "tag": "block",
      "protocol": "blackhole"
    }
  ]
}

这样没有命中回国规则的流量不会误入反向隧道。

国内出口机器配置

国内机器负责主动连接海外服务器，并把反向进来的流量从本地网络发出去。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56


{
  "log": {
    "loglevel": "warning"
  },
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["cn-reverse-in"],
        "outboundTag": "cn-home-direct"
      }
    ]
  },
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "freedom",
      "tag": "cn-home-direct",
      "settings": {
        "finalRules": [
          {
            "action": "allow",
            "network": "tcp,udp",
            "ip": ["!geoip:private"]
          }
        ]
      }
    },
    {
      "protocol": "vless",
      "tag": "cn-reverse-bridge",
      "settings": {
        "address": "proxy.example.com",
        "port": 443,
        "encryption": "none",
        "id": "",
        "flow": "xtls-rprx-vision",
        "reverse": {
          "tag": "cn-reverse-in"
        }
      },
      "streamSettings": {
        "network": "tcp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "proxy.example.com",
          "fingerprint": "chrome"
        }
      }
    }
  ]
}

这里的 finalRules 只允许访问非私网地址，避免朋友通过这条反向隧道访问国内出口机器所在局域网的私有网段。如果你就是要访问内网 NAS、路由器后台等资源，再按需放开具体 IP 和端口，不建议直接放开整个私网。

如果海外入口是 REALITY，国内机器的 streamSettings 改成类似下面这样：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
  "network": "tcp",
  "security": "reality",
  "realitySettings": {
    "serverName": "www.example.com",
    "publicKey": "",
    "shortId": "",
    "fingerprint": "chrome",
    "spiderX": "/"
  }
}

systemd 用户服务

如果国内机器没有 root 权限，也可以用用户级 systemd 跑 Xray。示例：

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


[Unit]
Description=Xray CN reverse exit
After=network-online.target

[Service]
Type=simple
Environment=XRAY_LOCATION_ASSET=%h/.local/share/xray
ExecStart=%h/.local/xray/xray run -config %h/.config/xray-cn-exit/config.json
Restart=on-failure
RestartSec=5
NoNewPrivileges=true

[Install]
WantedBy=default.target

启动：

1
2
3


systemctl --user daemon-reload
systemctl --user enable --now xray-cn-exit.service
systemctl --user status xray-cn-exit.service --no-pager

如果要让用户退出登录后仍然保持运行，需要确认系统是否开启了 linger：

1

loginctl enable-linger "$USER"

这一步通常需要管理员权限。

朋友客户端配置

普通 TLS 入口的链接大概是：

1

vless://@proxy.example.com:443?encryption=none&security=tls&sni=proxy.example.com&fp=chrome&type=tcp&flow=xtls-rprx-vision#CN-Return

REALITY 入口的链接大概是：

1

vless://@proxy.example.com:443?encryption=none&security=reality&sni=www.example.com&fp=chrome&pbk=&sid=&type=tcp&flow=xtls-rprx-vision#CN-Return

关键是朋友使用独立的。服务端通过这个 UUID 对应的 email 识别出朋友，然后只把国内目标转进 cn-reverse-out。

验证

先分别测试配置语法：

1
2


xray run -test -config /usr/local/etc/xray/config.json
xray run -test -config ~/.config/xray-cn-exit/config.json

然后重启服务：

1
2


systemctl restart xray
systemctl --user restart xray-cn-exit.service

可以临时在本地起一个朋友客户端 SOCKS 入站测试：

1
2


curl -x socks5h://127.0.0.1:18088 -I https://www.baidu.com/
curl -x socks5h://127.0.0.1:18088 https://api.ipify.org

期望结果：

www.baidu.com 正常返回；
国内出口机器日志里能看到类似 cn-reverse-in -> cn-home-direct；
非国内目标仍显示海外服务器 IP，说明没有把所有流量都转回国内机器。

注意事项

朋友必须使用独立 UUID，不要复用自己的 UUID。
服务器上如果已有 geoip:cn / geosite:cn 拦截规则，回国规则要放在拦截规则之前。
不建议在公网服务器上额外开放无认证 SOCKS/HTTP 代理端口，朋友直接复用 VLESS 入口即可。
国内出口机器关机、断网或 Xray 服务停止后，朋友的国内分流会不可用。
国内出口侧建议默认禁止访问私网地址，只按需放开具体内网资源。

这套方案的核心是“公网服务器负责入口和分流，国内机器负责主动建立反向隧道和最终出口”。新版 VLESS reverse proxy 把反向代理关系收敛到 VLESS client/outbound 本身，配置比旧的 reverse.portals / reverse.bridges 更直观，也更适合和现有 XTLS/Vision 入口合并使用。

本文2026-06-08首发于猫猫鱼的小窝，最后修改于2026-06-08

解决 Google Play 在 v2rayNG 下卡在等待下载的问题

xxx@example.com (catcatyu) — Fri, 05 Jun 2026 20:30:00 +0800

解决 Google Play 在 v2rayNG 下卡在等待下载的问题

作者：catcatyu（xxx@example.com）

问题现象

一台 OnePlus / ColorOS 设备上，Google Play 可以打开，也能搜索应用，但是安装应用时一直显示“等待中”或者“正在等待下载”。设备已经 root，可以在 Termux 里使用 su 执行系统命令。

当时环境大致如下：

Android 16
Google Play 商店版本：40.1.20-23
Google Play 服务版本：26.19.34
v2rayNG：2.0.18
当前代理节点：TLS-Vision-Unlimited-IPv4

先排除常见问题

先看空间：

1

df -h /data /storage/emulated/0

结果 /data 可用空间还有几百 GB，所以不是空间不足。

再确认几个核心包是否存在：

1
2
3
4


pm path com.android.vending
pm path com.google.android.gms
pm path com.google.android.gsf
pm path com.android.providers.downloads

这些包都存在。root 下进一步看包状态：

1
2
3


su -c '/system/bin/dumpsys package com.android.vending | grep -E "versionName|lastUpdateTime|installerPackageName|User 0"'
su -c '/system/bin/dumpsys package com.google.android.gms | grep -E "versionName|lastUpdateTime|installerPackageName|User 0"'
su -c '/system/bin/dumpsys package com.android.providers.downloads | grep -E "versionName|User 0"'

结论：

Play 商店、Play 服务、GSF、下载管理器都没有被禁用。
Play 商店版本比较旧，最后更新时间停在 2025-03-12。
下载管理器正常启用。

清掉旧的卡死下载任务

一开始在下载管理器数据库里发现了一个旧的 Play 下载任务：

1

su -c 'content query --uri content://downloads/all_downloads'

其中有一条记录类似：

1
2
3
4
5


notificationpackage=com.android.vending
allowed_network_types=2
status=194
errorMsg=Binding socket to network 182 failed: EPERM (Operation not permitted)
uri=https://rr5---sn-a5mekn6r.gvt1.com/play-apps-download-default/download/by-id/...

这里有两个重点：

allowed_network_types=2 表示任务只允许 Wi-Fi。
Binding socket to network 182 failed 表示它还绑到了一个已经失效的网络。

删除这条旧任务：

1
2
3


su -c 'content delete --uri content://downloads/all_downloads/103519'
su -c 'am force-stop com.android.vending; am force-stop com.android.providers.downloads; am force-stop com.google.android.gms'
su -c 'cmd package clear --user 0 --cache-only com.android.providers.downloads; cmd package clear --user 0 --cache-only com.android.vending'

这一步可以解决旧任务残留导致的“等待中”，但本次问题还没有完全解决。

抓 Play 下载服务日志

重新点下载后，继续抓日志：

1

su -c 'logcat -d -t 3000 | grep -Ei "Finsky|DownloadService|CronetDownloader|CANNOT_CONNECT|ERR_QUIC|ERR_CONNECTION|WAITING_FOR_RETRY|RUNNING|QUEUED|gvt1|CronetUrlRequest"'

关键日志：

1
2
3
4


CronetDownloader: onFailed
Exception in CronetUrlRequest: net::ERR_CONNECTION_CLOSED
Download Service Error: CANNOT_CONNECT (8)
Updating listeners of <... QUEUED with WAITING_FOR_RETRY ...>

中间还出现过：

1

net::ERR_QUIC_PROTOCOL_ERROR

这说明 Play 不是真的单纯排队，而是下载服务连接失败后进入等待重试。

为了排除 QUIC/HTTP3 影响，我临时对 Play 和 GMS 禁了 UDP 443：

1
2


su -c 'iptables -I OUTPUT -p udp --dport 443 -m owner --uid-owner 10248 -j REJECT'
su -c 'iptables -I OUTPUT -p udp --dport 443 -m owner --uid-owner 10242 -j REJECT'

其中：

10248 是 Play 商店 UID。
10242 是 Google Play 服务 UID。

禁掉 UDP 443 后，QUIC 错误减少，但仍然出现 TCP 层的 ERR_CONNECTION_CLOSED，所以问题不只是 QUIC。

找到真正失败的域名

Play 的下载 URL 不一定直接出现在 logcat 里，可以复制它的本地数据库出来读：

1
2
3
4
5
6
7
8


su -c 'cp /data/data/com.android.vending/databases/download_service /tmp/play_download_service.db; chmod 644 /tmp/play_download_service.db'
python3 - <<'PY'
import pathlib, re
data = pathlib.Path('/tmp/play_download_service.db').read_bytes()
urls = sorted(set(m.decode('utf-8', 'ignore') for m in re.findall(rb'https?://[^\x00\s"\']+', data)))
for u in urls:
    print(u[:500])
PY

查到当前 Play 下载库里实际使用的是：

1

https://services.googleapis.cn/download/by-token/download?token=...

旧任务里还出现过：

1

https://rr5---sn-a5mekn6r.gvt1.com/play-apps-download-default/download/by-id/...

因此重点域名是：

1
2
3


services.googleapis.cn
redirector.gvt1.com
*.gvt1.com

本机连通性测试

直接在 Termux 里测试：

1
2
3
4


curl -I --connect-timeout 10 https://services.googleapis.cn
curl -I --connect-timeout 10 https://redirector.gvt1.com
curl -I --connect-timeout 10 https://rr5---sn-a5mekn6r.gvt1.com
curl -I --connect-timeout 10 https://play.googleapis.com

一开始结果是：

1
2
3
4


services.googleapis.cn      TLS connect error: unexpected eof while reading
redirector.gvt1.com         TLS connect error: unexpected eof while reading
rr5---sn-a5mekn6r.gvt1.com  HTTP/1.1 404 Not Found
play.googleapis.com         HTTP/2 404

404 在这里反而说明 TLS 和 HTTP 都是通的，只是访问根路径不是有效接口。真正有问题的是 unexpected eof while reading，也就是 TLS 握手阶段被断开。

为了判断是不是域名本身的问题，又用 check-host 从第三方节点测：

1
2


curl -s 'https://check-host.net/check-http?host=https://services.googleapis.cn&max_nodes=8' -H 'Accept: application/json'
curl -s 'https://check-host.net/check-http?host=https://redirector.gvt1.com&max_nodes=8' -H 'Accept: application/json'

外部节点访问 services.googleapis.cn 和 redirector.gvt1.com 基本都返回 404，说明域名本身没有挂，是本机当前代理线路有问题。

检查 v2rayNG 路由配置

v2rayNG 2.0.18 的配置存在 MMKV 里：

1

su -c 'strings /data/data/com.v2ray.ang/files/mmkv/SETTING | grep -Ei "routing|geosite|gvt1|googleapis|services.googleapis|direct|proxy" -C2'

当时配置里能看到类似规则：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


{
  "domain": [
    "services.googleapis.cn",
    "*.gvt1.com",
    "redirector.gvt1.com",
    "*.googleusercontent.com"
  ],
  "enabled": true,
  "outboundTag": "proxy",
  "remarks": "playstore"
}

而且它的位置在 geosite:cn -> direct 前面。分应用代理里也包含：

1
2
3
4


com.android.vending
com.google.android.gms
com.android.providers.downloads
com.termux

所以表面看路由顺序没问题。

为了进一步排除“VPN 路由没生效”，我直接强制使用 v2rayNG 的本地 socks 端口测试：

1
2


curl --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 https://services.googleapis.cn
curl --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 https://redirector.gvt1.com

如果强制 socks 也失败，说明不是路由规则顺序问题，而是当前节点或服务端出站本身连不上这些域名。

当时测试结果就是强制 socks 也失败：

1

TLS connect error: unexpected eof while reading

因此定位为当前节点对 services.googleapis.cn 和 redirector.gvt1.com 的 TLS 握手不正常。

修复办法

最终调整 v2rayNG 路由，让 Play 下载相关域名明确走代理，并确保规则在 geosite:cn 直连规则前面：

1
2
3
4
5
6


full:services.googleapis.cn
full:redirector.gvt1.com
domain:gvt1.com
domain:googleapis.cn
domain:googleusercontent.com
geosite:google

出站选择 proxy。

如果用的是简单路由界面，逻辑应该是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


代理：
full:services.googleapis.cn
full:redirector.gvt1.com
domain:gvt1.com
domain:googleapis.cn
domain:googleusercontent.com
geosite:google

直连：
geosite:cn
geoip:cn

注意：services.googleapis.cn 虽然是 .cn 域名，但它是 Google Play 下载入口，不能让它被 geosite:cn 提前命中走直连。

调整后重新测试：

1
2
3
4


curl -I --connect-timeout 10 https://services.googleapis.cn
curl -I --connect-timeout 10 https://redirector.gvt1.com
curl --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 https://services.googleapis.cn
curl --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 https://redirector.gvt1.com

正常结果：

1
2


services.googleapis.cn   HTTP/2 404
redirector.gvt1.com      HTTP/2 404

出现 404 没关系，说明 TLS/HTTPS 已经通了。

最后强停 Play 商店和下载管理器，再重新下载：

1

su -c 'am force-stop com.android.vending; am force-stop com.android.providers.downloads; am force-stop com.google.android.gms'

然后打开 Google Play，取消旧的等待任务，重新点安装。

总结

这次问题有三层：

下载管理器里曾经残留一个只允许 Wi-Fi 且绑定旧网络的 Play 下载任务，需要删除。
Play 下载服务使用 Cronet，失败时界面会显示“等待中”，日志里实际是 CANNOT_CONNECT (8)。
真正导致下载失败的域名是 services.googleapis.cn，它虽然属于 .cn，但应该走代理，不能被 geosite:cn 规则直连。

最有用的几条排查命令：

1
2
3
4


su -c 'content query --uri content://downloads/all_downloads'
su -c 'logcat -d -t 3000 | grep -Ei "Finsky|DownloadService|CronetDownloader|CANNOT_CONNECT|ERR_CONNECTION|ERR_QUIC"'
curl -I --connect-timeout 10 https://services.googleapis.cn
curl --socks5-hostname 127.0.0.1:10808 -I --connect-timeout 10 https://services.googleapis.cn

如果 curl --socks5-hostname 127.0.0.1:10808 都连不上，那就不是 v2rayNG 路由写法的问题，而是节点或服务端出站本身的问题。

本文2026-06-05首发于猫猫鱼的小窝，最后修改于2026-06-05

Claude Code与Codebuddy Code配置自动审批与无代理fetch全攻略

xxx@example.com (catcatyu) — Tue, 02 Jun 2026 12:00:00 +0800

Claude Code与Codebuddy Code配置自动审批与无代理fetch全攻略

作者：catcatyu（xxx@example.com）

用 AI 编程工具最烦的两件事：一是每次执行命令都要点"同意"，二是 WebFetch/WebSearch 在国内网络环境下动不动就超时。本文分别介绍 Claude Code 和 Codebuddy Code 如何配置自动审批权限，以及如何让 fetch 类命令在无代理（翻墙）情况下正常工作。

一、Claude Code 配置

Claude Code 的配置文件位于 ~/.claude/settings.json（Windows 为 %USERPROFILE%\.claude\settings.json）。

1.1 自动审批（无需手动确认）

Claude Code 的权限系统核心是 defaultMode，它决定了工具调用的默认审批行为。将其设为 bypassPermissions 即可跳过所有权限弹窗：

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


{
  "permissions": {
    "defaultMode": "bypassPermissions",
    "allow": [
      "Bash(*)",
      "WebFetch",
      "WebSearch",
      "Edit(*)",
      "Write(*)",
      "Read(*)",
      "NotebookEdit(*)"
    ]
  }
}

defaultMode 的可选值（这是 Claude Code 权限系统的关键，很多人只配了 allow 却没生效，就是缺了这个）：

模式	行为
`default`	标准行为：首次使用每个工具时弹窗确认
`acceptEdits`	自动接受文件编辑和常见文件操作（mkdir、touch、mv、cp 等）
`plan`	计划模式：只读，不编辑源文件
`auto`	自动审批工具调用，但有后台安全检查（研究预览功能）
`dontAsk`	未在 `allow` 中预审批的工具自动拒绝（而非弹窗询问）
`bypassPermissions`	跳过所有权限弹窗，仅保留 `rm -rf /` 和 `rm -rf ~` 的硬编码熔断保护

为什么 defaultMode 才是关键：只配 allow 列表而不设 defaultMode，Claude Code 仍然会对未匹配的工具弹出确认框。bypassPermissions 是全局开关，allow 列表则用于更细粒度的控制（如只允许特定命令 Bash(npm run *) 而非全部）。两者配合使用效果最佳。

⚠️ bypassPermissions 会跳过对 .git、.claude、.vscode 等目录的写入保护，建议仅在隔离环境（容器、虚拟机）中使用。

如果你还想跳过危险模式的二次确认提示，再加上：

1
2
3


{
  "skipDangerousModePermissionPrompt": true
}

1.2 让 Fetch 在国内网络下可用

Claude Code 的 WebFetch 和 WebSearch 需要访问外部 API，在国内直连经常超时。解决方法是配置 HTTP 代理环境变量，在 settings.json 的 env 字段中设置：

1
2
3
4
5
6


{
  "env": {
    "http_proxy": "http://127.0.0.1:10808",
    "https_proxy": "http://127.0.0.1:10808"
  }
}

其中 10808 是你本地代理客户端（如 Clash/V2Ray）的 HTTP 代理端口，请按实际情况修改。

另外，如果你使用的代理存在自签证书，还需要设置跳过 TLS 验证（启动 Claude Code 前在终端执行）：

1

$env:NODE_TLS_REJECT_UNAUTHORIZED = "0"

1.3 其他实用配置

1
2
3
4
5
6


{
  "model": "opus",
  "theme": "dark",
  "autoUpdates": false,
  "skipWebFetchPreflight": true
}

model：指定默认模型
skipWebFetchPreflight：跳过 WebFetch 的预检请求（OPTIONS），某些代理环境下 preflight 会被拦截，开启后直接发 GET 请求

1.4 Claude Code 完整配置参考

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


{
  "enabledPlugins": {
    "rust-analyzer-lsp@claude-plugins-official": true
  },
  "env": {
    "http_proxy": "http://127.0.0.1:10808",
    "https_proxy": "http://127.0.0.1:10808"
  },
  "model": "opus",
  "theme": "dark",
  "autoUpdates": false,
  "skipWebFetchPreflight": true,
  "skipDangerousModePermissionPrompt": true,
  "permissions": {
    "defaultMode": "bypassPermissions",
    "allow": [
      "Bash(*)",
      "WebFetch",
      "WebSearch",
      "Edit(*)",
      "Write(*)",
      "Read(*)",
      "NotebookEdit(*)"
    ]
  }
}

二、Codebuddy Code 配置

Codebuddy Code 的配置文件位于 ~/.codebuddy/config.json（Windows 为 %USERPROFILE%\.codebuddy\config.json）。

2.1 自动审批

Codebuddy Code 同样采用 defaultMode + allow 白名单的权限模型，配置方式与 Claude Code 一致：

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


{
  "permissions": {
    "defaultMode": "bypassPermissions",
    "allow": [
      "Bash(*)",
      "WebFetch",
      "WebSearch",
      "Edit(*)",
      "Write(*)",
      "Read(*)",
      "NotebookEdit(*)"
    ]
  }
}

defaultMode: "bypassPermissions" 是关键全局开关，跳过所有权限审批
allow 列表定义了具体允许的工具操作，与 Claude Code 的写法一致

2.2 让 Fetch 正常工作

和 Claude Code 类似，在 env 字段中配置代理：

1
2
3
4
5
6


{
  "env": {
    "http_proxy": "http://127.0.0.1:10808",
    "https_proxy": "http://127.0.0.1:10808"
  }
}

如果代理有自签证书问题，启动前同样需要设置：

1

$env:NODE_TLS_REJECT_UNAUTHORIZED = "0"

2.3 Codebuddy Code 完整配置参考

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


{
  "env": {
    "http_proxy": "http://127.0.0.1:10808",
    "https_proxy": "http://127.0.0.1:10808"
  },
  "permissions": {
    "defaultMode": "bypassPermissions",
    "allow": [
      "Bash(*)",
      "WebFetch",
      "WebSearch",
      "Edit(*)",
      "Write(*)",
      "Read(*)",
      "NotebookEdit(*)"
    ]
  }
}

三、无代理环境下的替代方案

如果你没有本地代理客户端，还有几种方式让 Fetch 生效：

方案 A：使用系统代理

如果公司/学校网络有统一代理，直接把代理地址填入 env 即可：

1
2
3
4
5
6


{
  "env": {
    "http_proxy": "http://proxy.company.com:8080",
    "https_proxy": "http://proxy.company.com:8080"
  }
}

方案 B：Cloudflare Worker 反代

对于 WebFetch 抓取特定网站的场景，可以部署一个 Cloudflare Worker 作为反向代理，然后在工具中直接访问 Worker 地址，无需翻墙。具体方法参考之前的文章。

方案 C：跳过 Preflight 请求

部分代理环境会拦截 OPTIONS 预检请求导致 WebFetch 失败。Claude Code 可设置：

1
2
3


{
  "skipWebFetchPreflight": true
}

Codebuddy Code 中同样有类似配置项，开启后直接发送 GET 请求，绕过 preflight。

四、安全提醒

自动审批模式虽然方便，但也意味着 AI 工具可以不经确认地执行任何命令、读写任何文件。建议：

仅在受控环境中使用，不要在生产服务器上开启
定期检查操作日志，确认没有误操作

敏感目录可以用 deny 列表排除，例如：

1
2
3
4
5
6
7


{
  "permissions": {
    "defaultMode": "bypassPermissions",
    "allow": ["Bash(*)", "Read(*)"],
    "deny": ["Bash(rm -rf /*)"]
  }
}

配置完成后，AI 编程助手就能丝滑地自动执行命令和访问网络了，再也不用频繁点确认了。

本文2026-06-02首发于猫猫鱼的小窝，最后修改于2026-06-02

记录一次因 Nginx 转发 H3 速度慢而改用 Envoy 前置 Xray XHTTP

xxx@example.com (catcatyu) — Sat, 23 May 2026 21:56:28 +0800

记录一次因 Nginx 转发 H3 速度慢而改用 Envoy 前置 Xray XHTTP

作者：catcatyu（xxx@example.com）

前言

这次记录的是一套代理服务端配置的调整过程：最开始尝试用 Nginx 做前置转发 Xray XHTTP，但 H3/UDP 下行经过 Nginx 后速度明显偏低；同样的 Xray 直连 H3 诊断入口可以跑满，所以瓶颈基本可以定位在前置层。最后把公网入口改成 Envoy，由 Envoy 接管 TCP/443 的 HTTPS/H2 和 UDP/443 的 HTTP/3，再把 XHTTP 流量转发给本机 Xray，把普通网页流量转发给本机 Nginx 伪装站。

简单对比一下当时的测试结果：

方案	下行表现	说明
XHTTP H2 上行 + H2 下行	约 334-339 Mbps	不走 H3 下行时基本正常
XHTTP H2 上行 + H3 下行，经 Nginx 前置	约 7-15 Mbps	主要瓶颈出现在 Nginx 前置转发 H3
XHTTP H3 直连 Xray 9443 诊断口	约 367 Mbps	说明 Xray 自身和线路并不是主要瓶颈
Caddy 前置 H3	约 41 Mbps	比 Nginx 好，但仍不理想
Envoy 前置 H3	作为最终方案	用 Envoy 替代 Nginx 做公网 H3 入口

为了避免泄露真实信息，本文里的域名、UUID、密码、统计密钥、XHTTP 路径 token 都已经脱敏。直接复制前需要把占位符替换成自己的值。

当前架构

调整后的架构里，Nginx 不再作为公网 443 前置，只保留为本机静态伪装站后端；公网 TCP/80、TCP/443、UDP/443 都交给 Envoy。

公网入口：

端口	协议	服务	作用
TCP/80	HTTP	Envoy	HTTP 跳转 HTTPS，ACME challenge 转发到 Nginx
TCP/443	HTTPS/H2	Envoy	XHTTP 上行、普通 HTTPS 伪装站
UDP/443	HTTP/3	Envoy	XHTTP H3 下行、普通 H3 入口
UDP/9443	Xray	XHTTP/H3 诊断入口	绕过前置的测试入口，不作为常规使用

本机后端：

地址	服务	作用
127.0.0.1:10000	Xray	Envoy 转发过来的 XHTTP 后端
127.0.0.1:10085	Xray API	stats、在线用户、限额脚本
127.0.0.1:18080	Nginx	伪装站和 ACME challenge
127.0.0.1:9901	Envoy admin	Envoy 本机管理接口

软件版本：

1
2
3


Xray 26.3.27
Envoy 1.32.2
nginx 1.31.1

Xray 配置

配置文件路径：

1

/usr/local/etc/xray/config.json

这里 Xray 只监听本机 XHTTP 后端和 API，TLS/H2/H3 由 Envoy 在公网侧处理。diag-xhttp-h3-direct 是直连 H3 诊断入口，用来判断瓶颈是否来自前置代理。

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203


{
  "log": {
    "loglevel": "warning",
    "access": "/var/log/xray/access.log",
    "error": "/var/log/xray/error.log"
  },
  "api": {
    "tag": "api",
    "services": ["HandlerService", "StatsService"]
  },
  "stats": {},
  "policy": {
    "levels": {
      "0": {
        "statsUserUplink": true,
        "statsUserDownlink": true,
        "statsUserOnline": true
      }
    },
    "system": {
      "statsInboundUplink": true,
      "statsInboundDownlink": true,
      "statsOutboundUplink": true,
      "statsOutboundDownlink": true
    }
  },
  "inbounds": [
    {
      "tag": "api-in",
      "listen": "127.0.0.1",
      "port": 10085,
      "protocol": "dokodemo-door",
      "settings": {
        "address": "127.0.0.1"
      }
    },
    {
      "tag": "reality-in",
      "listen": "/dev/shm/xrxh.socket,0666",
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "",
            "flow": "",
            "email": "client-50g@local"
          },
          {
            "id": "",
            "flow": "",
            "email": "client-unlimited@local"
          },
          {
            "id": "",
            "flow": "",
            "email": "client-unlimited2@local"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "xhttpSettings": {
          "mode": "stream-up",
          "path": "/api/v1/"
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls", "quic"],
        "routeOnly": true
      }
    },
    {
      "tag": "xhttp-caddy-backend",
      "listen": "127.0.0.1",
      "port": 10000,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "",
            "flow": "",
            "email": "client-50g@local"
          },
          {
            "id": "",
            "flow": "",
            "email": "client-unlimited@local"
          },
          {
            "id": "",
            "flow": "",
            "email": "client-unlimited2@local"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "xhttpSettings": {
          "mode": "stream-up",
          "path": "/api/v1/"
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls", "quic"],
        "routeOnly": true
      }
    },
    {
      "tag": "diag-xhttp-h3-direct",
      "listen": "::",
      "port": 9443,
      "protocol": "vless",
      "settings": {
        "clients": [
          {
            "id": "",
            "flow": "",
            "email": "client-50g@local"
          },
          {
            "id": "",
            "flow": "",
            "email": "client-unlimited@local"
          },
          {
            "id": "",
            "flow": "",
            "email": "client-unlimited2@local"
          }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "xhttp",
        "security": "tls",
        "tlsSettings": {
          "serverName": "",
          "alpn": ["h3"],
          "minVersion": "1.2",
          "certificates": [
            {
              "certificateFile": "/usr/local/etc/xray/certs/fullchain.pem",
              "keyFile": "/usr/local/etc/xray/certs/privkey.pem"
            }
          ]
        },
        "xhttpSettings": {
          "mode": "auto",
          "path": "/api/v1/"
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls", "quic"],
        "routeOnly": true
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "tag": "direct"
    },
    {
      "protocol": "blackhole",
      "tag": "blocked"
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": ["api-in"],
        "outboundTag": "api"
      },
      {
        "type": "field",
        "ip": ["geoip:cn"],
        "outboundTag": "blocked"
      },
      {
        "type": "field",
        "domain": ["geosite:cn"],
        "outboundTag": "blocked"
      },
      {
        "type": "field",
        "ip": ["geoip:private"],
        "outboundTag": "blocked"
      },
      {
        "type": "field",
        "protocol": ["bittorrent"],
        "outboundTag": "blocked"
      }
    ]
  }
}

这里有两个关键点：

policy 里开启了用户上行、下行和在线统计，所以 xray api statsquery、statsonline、statsonlineiplist 可以正常使用。
路由里拒绝了中国 IP、中国域名、私网地址和 BitTorrent，避免节点被拿来访问国内或跑 BT。

Envoy 配置

配置文件路径：

1

/etc/envoy/envoy.yaml

Envoy 的作用是统一接管公网 TCP/80、TCP/443、UDP/443。TCP/443 提供 H2，UDP/443 提供 H3；命中 XHTTP 随机路径的请求转给 Xray，其他请求转给 Nginx 伪装站。

之所以让 Envoy 接管公网入口，是因为 Nginx 做 H3/UDP 前置时下行速度明显掉到十几 Mbps，和 Xray 直连 H3 的三百多 Mbps 不在一个量级。Envoy 的 HTTP/3 支持更适合这个场景，也方便同时保留 HTTP 跳转、ACME challenge 和普通伪装站路由。

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385


admin:
  address:
    socket_address:
      address: 127.0.0.1
      port_value: 9901

static_resources:
  listeners:
  - name: listener_http_redirect_v6
    address:
      socket_address:
        address: "::"
        port_value: 80
        ipv4_compat: false
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: http_redirect_v6
          route_config:
            name: http_redirect_route_v6
            virtual_hosts:
            - name: redirect_all_v6
              domains: ["*"]
              routes:
              - match:
                  prefix: "/.well-known/acme-challenge/"
                route:
                  cluster: nginx_site
              - match:
                  prefix: "/"
                redirect:
                  https_redirect: true
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

  - name: listener_http_redirect
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 80
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          stat_prefix: http_redirect
          route_config:
            name: http_redirect_route
            virtual_hosts:
            - name: redirect_all
              domains: ["*"]
              routes:
              - match:
                  prefix: "/.well-known/acme-challenge/"
                route:
                  cluster: nginx_site
              - match:
                  prefix: "/"
                redirect:
                  https_redirect: true
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router

  - name: listener_https_tcp
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 443
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          codec_type: AUTO
          stat_prefix: https_tcp_ingress
          stream_idle_timeout: 3600s
          request_timeout: 3600s
          common_http_protocol_options:
            idle_timeout: 3600s
          http2_protocol_options:
            max_concurrent_streams: 1024
            initial_stream_window_size: 1048576
            initial_connection_window_size: 16777216
          upgrade_configs:
          - upgrade_type: CONNECT
          route_config:
            name: https_route
            virtual_hosts:
            - name: xhttp_hosts
              domains: ["", ""]
              response_headers_to_add:
              - header:
                  key: alt-svc
                  value: h3=":443"; ma=86400
                append_action: OVERWRITE_IF_EXISTS_OR_ADD
              - header:
                  key: x-content-type-options
                  value: nosniff
              - header:
                  key: referrer-policy
                  value: strict-origin-when-cross-origin
              routes:
              - match:
                  prefix: "/api/v1/"
                route:
                  cluster: xray_xhttp
                  timeout: 0s
                  idle_timeout: 3600s
                  prefix_rewrite: "/api/v1/"
              - match:
                  prefix: "/"
                route:
                  cluster: nginx_site
                  timeout: 60s
            - name: default_host
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: nginx_site
                  timeout: 60s
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
      transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
          common_tls_context:
            alpn_protocols: ["h2", "http/1.1"]
            tls_certificates:
            - certificate_chain:
                filename: /etc/envoy/certs/fullchain.pem
              private_key:
                filename: /etc/envoy/certs/privkey.pem

  - name: listener_https_tcp_v6
    address:
      socket_address:
        address: "::"
        port_value: 443
        ipv4_compat: false
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          codec_type: AUTO
          stat_prefix: https_tcp_ingress_v6
          stream_idle_timeout: 3600s
          request_timeout: 3600s
          common_http_protocol_options:
            idle_timeout: 3600s
          http2_protocol_options:
            max_concurrent_streams: 1024
            initial_stream_window_size: 1048576
            initial_connection_window_size: 16777216
          route_config:
            name: https_route_v6
            virtual_hosts:
            - name: xhttp_hosts_v6
              domains: ["", ""]
              response_headers_to_add:
              - header:
                  key: alt-svc
                  value: h3=":443"; ma=86400
                append_action: OVERWRITE_IF_EXISTS_OR_ADD
              routes:
              - match:
                  prefix: "/api/v1/"
                route:
                  cluster: xray_xhttp
                  timeout: 0s
                  idle_timeout: 3600s
              - match:
                  prefix: "/"
                route:
                  cluster: nginx_site
                  timeout: 60s
            - name: default_host_v6
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: nginx_site
                  timeout: 60s
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
      transport_socket:
        name: envoy.transport_sockets.tls
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.DownstreamTlsContext
          common_tls_context:
            alpn_protocols: ["h2", "http/1.1"]
            tls_certificates:
            - certificate_chain:
                filename: /etc/envoy/certs/fullchain.pem
              private_key:
                filename: /etc/envoy/certs/privkey.pem

  - name: listener_https_quic_v6
    address:
      socket_address:
        protocol: UDP
        address: "::"
        port_value: 443
        ipv4_compat: false
    udp_listener_config:
      quic_options: {}
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          codec_type: HTTP3
          stat_prefix: https_quic_ingress_v6
          stream_idle_timeout: 3600s
          request_timeout: 3600s
          common_http_protocol_options:
            idle_timeout: 3600s
          http3_protocol_options:
            quic_protocol_options:
              max_concurrent_streams: 1024
              initial_stream_window_size: 1048576
              initial_connection_window_size: 16777216
          route_config:
            name: https_quic_route_v6
            virtual_hosts:
            - name: xhttp_hosts_v6
              domains: ["", ""]
              response_headers_to_add:
              - header:
                  key: alt-svc
                  value: h3=":443"; ma=86400
                append_action: OVERWRITE_IF_EXISTS_OR_ADD
              routes:
              - match:
                  prefix: "/api/v1/"
                route:
                  cluster: xray_xhttp
                  timeout: 0s
                  idle_timeout: 3600s
              - match:
                  prefix: "/"
                route:
                  cluster: nginx_site
                  timeout: 60s
            - name: default_host_v6
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: nginx_site
                  timeout: 60s
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
      transport_socket:
        name: envoy.transport_sockets.quic
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.quic.v3.QuicDownstreamTransport
          downstream_tls_context:
            common_tls_context:
              alpn_protocols: ["h3"]
              tls_certificates:
              - certificate_chain:
                  filename: /etc/envoy/certs/fullchain.pem
                private_key:
                  filename: /etc/envoy/certs/privkey.pem

  - name: listener_https_quic
    address:
      socket_address:
        protocol: UDP
        address: 0.0.0.0
        port_value: 443
    udp_listener_config:
      quic_options: {}
    filter_chains:
    - filters:
      - name: envoy.filters.network.http_connection_manager
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManager
          codec_type: HTTP3
          stat_prefix: https_quic_ingress
          stream_idle_timeout: 3600s
          request_timeout: 3600s
          common_http_protocol_options:
            idle_timeout: 3600s
          http3_protocol_options:
            quic_protocol_options:
              max_concurrent_streams: 1024
              initial_stream_window_size: 1048576
              initial_connection_window_size: 16777216
          route_config:
            name: https_quic_route
            virtual_hosts:
            - name: xhttp_hosts
              domains: ["", ""]
              response_headers_to_add:
              - header:
                  key: alt-svc
                  value: h3=":443"; ma=86400
                append_action: OVERWRITE_IF_EXISTS_OR_ADD
              routes:
              - match:
                  prefix: "/api/v1/"
                route:
                  cluster: xray_xhttp
                  timeout: 0s
                  idle_timeout: 3600s
              - match:
                  prefix: "/"
                route:
                  cluster: nginx_site
                  timeout: 60s
            - name: default_host
              domains: ["*"]
              routes:
              - match:
                  prefix: "/"
                route:
                  cluster: nginx_site
                  timeout: 60s
          http_filters:
          - name: envoy.filters.http.router
            typed_config:
              "@type": type.googleapis.com/envoy.extensions.filters.http.router.v3.Router
      transport_socket:
        name: envoy.transport_sockets.quic
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.transport_sockets.quic.v3.QuicDownstreamTransport
          downstream_tls_context:
            common_tls_context:
              alpn_protocols: ["h3"]
              tls_certificates:
              - certificate_chain:
                  filename: /etc/envoy/certs/fullchain.pem
                private_key:
                  filename: /etc/envoy/certs/privkey.pem

  clusters:
  - name: xray_xhttp
    connect_timeout: 5s
    type: STATIC
    lb_policy: ROUND_ROBIN
    http2_protocol_options:
      initial_stream_window_size: 1048576
      initial_connection_window_size: 16777216
    load_assignment:
      cluster_name: xray_xhttp
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 10000

  - name: nginx_site
    connect_timeout: 5s
    type: STATIC
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: nginx_site
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: 127.0.0.1
                port_value: 18080

当时测试过几种前置方式，H3 经过 Nginx Stream 时下行明显掉速，Caddy 有改善但仍不理想，最后切到 Envoy 做 HTTP/3 入口。实际环境里建议保留一个 Xray 直连 H3 诊断端口，用来判断是 Xray 自身、前置代理还是网络路径造成的瓶颈。

Nginx 伪装站配置

Nginx 不再监听公网 80/443，也不再承担 H3/UDP 前置转发。它只监听本机端口，作为 Envoy 的静态伪装站后端。这样既保留 Nginx 处理静态文件的简单性，又避开了它在这次 H3 转发测试中的速度瓶颈。

主配置：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


user  nginx;
worker_processes  auto;
worker_rlimit_nofile  200000;

error_log  /var/log/nginx/error.log notice;
pid        /run/nginx.pid;

events {
    worker_connections  8192;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    keepalive_timeout  65;
    keepalive_requests 10000;
    client_body_buffer_size 32m;
    client_body_timeout 5m;
    send_timeout 5m;
    proxy_buffering off;

    include /etc/nginx/conf.d/*.conf;
}

伪装站配置：

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


server {
    listen 127.0.0.1:18080;
    server_name  ;
    root /var/www/fjh-site;
    index index.html;

    location /.well-known/acme-challenge/ {
        root /var/www/letsencrypt;
    }

    location / {
        try_files $uri $uri/ /index.html;
    }
}

默认站也改成本机监听，避免和 Envoy 的公网端口冲突：

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


server {
    listen 127.0.0.1:18081;
    server_name localhost;

    location / {
        root /usr/share/nginx/html;
        index index.html index.htm;
    }

    error_page 500 502 503 504 /50x.html;
    location = /50x.html {
        root /usr/share/nginx/html;
    }
}

Caddy 备用配置

当前 Caddy 是 disabled，不参与公网入口。机器上仍保留过一版 Caddyfile，方便后续需要时切回 Caddy 前置。这里同样做了脱敏：

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


{
    servers {
        protocols h1 h2 h3
    }
}

,  {
    tls /etc/caddy/certs/fullchain.pem /etc/caddy/certs/privkey.pem
    root * /var/www/fjh-site

    @acme path /.well-known/acme-challenge/*
    handle @acme {
        root * /var/www/letsencrypt
        file_server
    }

    @xhttp path /api/v1/*
    reverse_proxy @xhttp h2c://127.0.0.1:10000 {
        header_up Host {host}
        flush_interval -1
    }

    file_server
}

证书部署 Hook

证书由 Let’s Encrypt 生成后，通过 deploy hook 同步到 Envoy、Xray 等服务目录，并重载或重启相关服务。

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


#!/usr/bin/env sh
set -eu

install -d -o root -g caddy -m 750 /etc/caddy/certs
install -o root -g caddy -m 640 /etc/letsencrypt/live//fullchain.pem /etc/caddy/certs/fullchain.pem
install -o root -g caddy -m 640 /etc/letsencrypt/live//privkey.pem /etc/caddy/certs/privkey.pem

install -d -o root -g envoy -m 750 /etc/envoy/certs
install -o root -g envoy -m 640 /etc/letsencrypt/live//fullchain.pem /etc/envoy/certs/fullchain.pem
install -o root -g envoy -m 640 /etc/letsencrypt/live//privkey.pem /etc/envoy/certs/privkey.pem

install -d -o root -g nogroup -m 750 /usr/local/etc/xray/certs
install -o root -g nogroup -m 640 /etc/letsencrypt/live//fullchain.pem /usr/local/etc/xray/certs/fullchain.pem
install -o root -g nogroup -m 640 /etc/letsencrypt/live//privkey.pem /usr/local/etc/xray/certs/privkey.pem

if systemctl is-active --quiet nginx; then
    systemctl reload nginx >/dev/null 2>&1 || systemctl restart nginx >/dev/null 2>&1 || true
fi
if systemctl is-active --quiet caddy; then
    systemctl reload caddy >/dev/null 2>&1 || systemctl restart caddy >/dev/null 2>&1 || true
fi
if systemctl is-active --quiet envoy; then
    systemctl reload envoy >/dev/null 2>&1 || systemctl restart envoy >/dev/null 2>&1 || true
fi
systemctl restart xray >/dev/null 2>&1 || true

虽然当前入口已经换成 Envoy，hook 里仍然保留了 Caddy 证书同步和 reload 逻辑，是为了以后切换前置时少改一点东西。当前 Caddy 是 disabled，不参与公网入口。

证书私钥文件、证书链文件、历史备份配置和临时诊断客户端配置不适合原样贴到博客里。本文只记录路径和引用方式，不包含任何 PEM 私钥内容。

systemd 服务

Xray：

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


[Unit]
Description=Xray Service
Documentation=https://github.com/xtls
After=network.target nss-lookup.target

[Service]
User=nobody
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_BIND_SERVICE
NoNewPrivileges=true
ExecStart=/usr/local/bin/xray run -config /usr/local/etc/xray/config.json
Restart=on-failure
RestartPreventExitStatus=23
LimitNPROC=10000
LimitNOFILE=1000000
RuntimeDirectory=xray
RuntimeDirectoryMode=0755

[Install]
WantedBy=multi-user.target

Envoy：

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


[Unit]
Description=Envoy Proxy
Documentation=https://www.envoyproxy.io/docs
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=envoy
Group=envoy
ExecStart=/usr/bin/envoy -c /etc/envoy/envoy.yaml --concurrency 1 --log-level warning
Restart=on-failure
RestartSec=3
LimitNOFILE=200000
AmbientCapabilities=CAP_NET_BIND_SERVICE
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
NoNewPrivileges=true

[Install]
WantedBy=multi-user.target

Xray 流量统计和 50GB 限额

Xray 通过 API 统计每个用户的上下行，并用 systemd timer 每分钟运行一次限额脚本。50GB 用户超过累计流量后，通过 Xray API 删除对应用户。

/etc/systemd/system/xray-traffic-limit.service：

1
2
3
4
5
6
7
8


[Unit]
Description=Xray per-user traffic quota enforcer
After=xray.service
Requires=xray.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/xray-traffic-limit.sh

/etc/systemd/system/xray-traffic-limit.timer：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


[Unit]
Description=Run xray traffic limiter every minute

[Timer]
OnBootSec=1min
OnUnitActiveSec=1min
AccuracySec=10s
Unit=xray-traffic-limit.service

[Install]
WantedBy=timers.target

限额脚本：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51


#!/usr/bin/env bash
set -euo pipefail

API_ADDR="127.0.0.1:10085"
EMAIL="client-50g@local"
LIMIT_BYTES=$((50 * 1024 * 1024 * 1024))
STATE_DIR="/var/lib/xray-limiter"
DISABLED_FLAG="$STATE_DIR/${EMAIL}.disabled"
CUM_FILE="$STATE_DIR/${EMAIL}.cum"
LOG_TAG="xray-limiter"

mkdir -p "$STATE_DIR"

get_counter() {
  local out
  out=$(xray api statsquery --server="$API_ADDR" -reset -pattern "$1" 2>/dev/null || true)
  [[ -z "$out" ]] && {
    echo 0
    return
  }
  echo "$out" | python3 -c '
import sys, json
try:
    d = json.load(sys.stdin)
    v = 0
    for s in d.get("stat", []):
        v += int(s.get("value", 0) or 0)
    print(v)
except Exception:
    print(0)
'
}

UP=$(get_counter "user>>>${EMAIL}>>>traffic>>>uplink")
DOWN=$(get_counter "user>>>${EMAIL}>>>traffic>>>downlink")
UP=${UP:-0}
DOWN=${DOWN:-0}
DELTA=$((UP + DOWN))

CUM=0
[[ -f "$CUM_FILE" ]] && CUM=$(cat "$CUM_FILE")
CUM=$((CUM + DELTA))
echo "$CUM" > "$CUM_FILE"

logger -t "$LOG_TAG" "email=$EMAIL delta=$DELTA cum=$CUM limit=$LIMIT_BYTES"

if (( CUM >= LIMIT_BYTES )) && [[ ! -f "$DISABLED_FLAG" ]]; then
  logger -t "$LOG_TAG" "limit exceeded, removing user $EMAIL"
  xray api rmu --server="$API_ADDR" -tag=reality-in "$EMAIL" >/dev/null 2>&1 || true
  touch "$DISABLED_FLAG"
fi

注意：如果 Xray 的入口 tag 改了，限额脚本里的 -tag=reality-in 也要同步修改，否则删除用户不会命中正确 inbound。当前配置里公网 XHTTP 实际走的是 xhttp-caddy-backend，如果需要同时封禁所有入口，脚本里应对相关 inbound tag 都执行一次 rmu。

分享链接模板

XHTTP 上下行分离的分享链接大致如下。这里把关键值都替换成了占位符：

1

vless://@:443?encryption=none&security=tls&sni=&fp=chrome&type=xhttp&host=&path=%2Fapi%2Fv1%2F&mode=stream-up&alpn=h2&extra=#TLS-XHTTP-H2up-H2down

extra 里可以放 padding、xmux 和 downloadSettings。例如下载侧使用另一个域名：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


{
  "xPaddingBytes": "100-1000",
  "xmux": {
    "maxConcurrency": "16-32",
    "hMaxRequestTimes": "600-900",
    "hMaxReusableSecs": "1800-3000"
  },
  "downloadSettings": {
    "address": "",
    "port": 443,
    "network": "xhttp",
    "security": "tls",
    "tlsSettings": {
      "serverName": "",
      "fingerprint": "chrome",
      "alpn": ["h2"]
    },
    "xhttpSettings": {
      "host": "",
      "path": "/api/v1/",
      "extra": {
        "xPaddingBytes": "100-1000"
      }
    }
  }
}

验证命令

看服务状态：

1

systemctl status xray envoy nginx --no-pager

看监听端口：

1

ss -lntup | grep -E '(:80|:443|:9443|:10000|:10085|:18080|:9901)'

验证 Envoy 配置：

1

envoy --mode validate -c /etc/envoy/envoy.yaml

看 Envoy H3 统计：

1

curl -s http://127.0.0.1:9901/stats | grep http3

看 Xray 用户统计：

1

xray api statsquery --server=127.0.0.1:10085 -pattern 'user>>>client-unlimited@local>>>traffic>>>'

结论

这套配置的核心是把入口层和代理层分开：Envoy 负责公网 HTTPS/H2/H3 和伪装站转发，Xray 专注处理 XHTTP，Nginx 只做本机静态站。改成 Envoy 的直接原因，是 Nginx 作为 H3 前置时下行速度明显偏低，而 Xray 直连 H3 诊断口能跑满，说明继续调 Xray 参数意义不大，应该替换前置层。

实际测试中，XHTTP H2/H2 可以跑满链路，H3 下行是否高性能和前置实现关系很大。Nginx Stream 转发 H3 时容易成为瓶颈，Caddy 有改善，Envoy 更适合做这类 HTTP/3 入口。如果遇到速度异常，建议保留一个 Xray 直连 H3 诊断入口，先确认 Xray 自身在当前线路下能否跑满。

本文2026-05-23首发于猫猫鱼的小窝，最后修改于2026-05-23

Headscale + Tailscale + sing-box for Android：利用家宽打洞实现公司环境安全“科学上网”

xxx@example.com (catcatyu) — Fri, 08 May 2026 17:10:00 +0800

Headscale + Tailscale + sing-box for Android：利用家宽打洞实现公司环境安全“科学上网”

作者：catcatyu（xxx@example.com）

背景

在当前的工作环境下，公司对网络合规和出口流量审计的要求日益严苛。办公网络不仅严查各类 VPN 协议，还会对所有通往境外的连接记录进行深度审计。为了在满足个人上网需求的同时，彻底避免将个人设备的代理链路暴露在办公网络出口上，我构建了一套基于“组网即代理”的方案。

核心思路是利用家里的宽带作为唯一的“科学上网”出口，而办公环境下的手机仅作为一个纯粹的内网接入点，通过自建的 Tailscale 网络连接回自家的电脑进行“打洞”。具体设计动机如下：

规避办公网审计：通过将真正的代理入口放在家里的 Windows 电脑上，手机在办公网环境下只产生与国内服务器（阿里云）或家宽公网 IP 的通信。所有对境外的访问流量均被封装在隧道内部，并最终在家宽出口解封，从而确保办公网出口没有任何境外 IP 的访问记录。
阿里云控制面（Headscale）：为了实现稳定且不经过境外的控制平面，我在国内的阿里云 ECS 上部署了 Headscale（Tailscale 的开源替代方案）。需要注意，阿里云在这里仅作为**控制面（Control Plane）**负责节点发现和 NAT 穿透握手，并不负责数据中转。流量最终是通过 P2P 打洞直连到家里的，这样既保证了低延迟，也避免了阿里云因流量中转产生高昂的带宽费用。
完全物理隔离：本方案实现了个人访问链路与办公网络的物理级隔离。办公网出口看到的只是前往阿里云的合规 HTTPS 流量，真正的互联网访问逻辑完全托管在自有设备和自有宽带上。

整体思路

阿里云 ECS 上部署 Headscale，作为 Tailscale 控制面（仅负责握手，记得关闭或不使用 DERP 中转，以节省阿里云流量）。
家里的 Windows 电脑 加入这个 tailnet，作为代理网关，获得内网 IP 100.64.0.2。
家里电脑 本地运行 SOCKS5 服务（如 Clash/v2ray），并监听 100.64.0.2:10808 端口。
Android 手机 使用 sing-box for Android，通过内置的 Tailscale endpoint 登录 Headscale。
手机流量路由：Android 的 TUN 流量通过 Tailscale 隧道转发到家里的 100.64.0.2:10808。

技术架构示意图：

  flowchart LR
  subgraph Phone["Android 手机"]
    App["App 流量"]
    Tun["sing-box TUN"]
    TsEndpoint["Tailscale endpoint
ts-ep"]
  end

  subgraph Cloud["阿里云 ECS"]
    Headscale["Headscale 控制面
:8443"]
  end

  subgraph Home["家里宽带"]
    Windows["Windows 网关
100.64.0.2"]
    Socks["SOCKS5 服务
100.64.0.2:10808"]
    HomeWan["家里宽带出口"]
  end

  App --> Tun --> TsEndpoint
  TsEndpoint -.->|登录 / 节点发现 / NAT 打洞| Headscale
  TsEndpoint ==>|加密 tailnet 连接| Socks
  Windows --- Socks
  Socks --> HomeWan

这样手机侧的链路是：

1
2
3
4
5
6


Android App 流量
  -> sing-box TUN
  -> sing-box 内置 Tailscale endpoint (通过阿里云 Headscale 握手)
  -> tailnet 内内的 100.64.0.2:10808 (加密隧道)
  -> 家里电脑上的 SOCKS5 代理
  -> 家里宽带出口 (真正的境外访问发生在这里)

注意：这只是个人设备访问个人授权网络的记录。实际使用时要严格遵守所在单位、学校和网络服务提供方的安全合规准则。

版本要求

Android 端需要使用支持 sing-box 1.14 新字段的 SFA/sing-box 版本。实测 sing-box for Android 1.14.0-alpha.21 以上可用。

低版本如果导入下面的配置，可能会报类似错误：

1

unknown field accept_search_domain

原因是 accept_search_domain、control_http_client、dns_mode、preferred_by 等字段属于较新的 sing-box 配置格式。

Headscale 服务端配置

服务端部署在阿里云 ECS，公网地址、域名和密钥在这里都做了脱敏。

采集到的版本：

1

headscale version v0.28.0

配置文件路径：

1

/etc/headscale/config.yaml

核心配置如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48


server_url: https://:8443
listen_addr: 0.0.0.0:8443
grpc_listen_addr: 127.0.0.1:50443
metrics_listen_addr: 127.0.0.1:9090

database:
  type: sqlite
  sqlite:
    path: /var/lib/headscale/db.sqlite
    write_ahead_log: true

prefixes:
  allocation: sequential
  v4: 100.64.0.0/10
  v6: fd7a:115c:a1e0::/48

dns:
  magic_dns: true
  base_domain: 
  override_local_dns: true
  nameservers:
    global:
      - 1.1.1.1
      - 1.0.0.1
      - 2606:4700:4700::1111
      - 2606:4700:4700::1001

derp:
  auto_update_enabled: false
  paths:
    - /etc/headscale/derp-stun-only.yaml
  server:
    enabled: true # 启用内置 STUN，继续监听 UDP 3478
    automatically_add_embedded_derp_region: false # 不把内置 DERP 加入 DERP map，避免客户端走 DERP 中转
    region_id: 999
    region_code: headscale
    region_name: Headscale Embedded DERP
    stun_listen_addr: 0.0.0.0:3478
    private_key_path: 
    verify_clients: true
  urls: []
  update_frequency: 3h

noise:
  private_key_path: 

tls_cert_path: /path/to/.cer
tls_key_path: /path/to/.key

同时创建 /etc/headscale/derp-stun-only.yaml，只下发 STUN，不提供可用 DERP 中继。这里可以配置多个 STUN 节点，让客户端在多出口网络里探测到更多 NAT 映射候选：

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178


regions:
  999:
    regionid: 999
    regioncode: stun-self
    regionname: Self STUN
    nodes:
      - name: 999a
        regionid: 999
        hostname: 
        ipv4: 
        stunport: 3478
        derpport: 1

  1000:
    regionid: 1000
    regioncode: stun-ali
    regionname: Public STUN 39.107
    nodes:
      - name: 1000a
        regionid: 1000
        hostname: 39.107.142.158
        ipv4: 39.107.142.158
        stunport: 3478
        derpport: 1

  1001:
    regionid: 1001
    regioncode: stun-hitv
    regionname: Public STUN HITV
    nodes:
      - name: 1001a
        regionid: 1001
        hostname: stun.hitv.com
        stunport: 3478
        derpport: 1

  1002:
    regionid: 1002
    regioncode: stun-miwifi
    regionname: Public STUN MiWiFi
    nodes:
      - name: 1002a
        regionid: 1002
        hostname: stun.miwifi.com
        stunport: 3478
        derpport: 1

  1003:
    regionid: 1003
    regioncode: stun-bilibili
    regionname: Public STUN Bilibili
    nodes:
      - name: 1003a
        regionid: 1003
        hostname: stun.chat.bilibili.com
        stunport: 3478
        derpport: 1

  1004:
    regionid: 1004
    regioncode: stun-cloudflare
    regionname: Public STUN Cloudflare
    nodes:
      - name: 1004a
        regionid: 1004
        hostname: stun.cloudflare.com
        stunport: 3478
        derpport: 1

  1005:
    regionid: 1005
    regioncode: stun-nextcloud
    regionname: Public STUN Nextcloud
    nodes:
      - name: 1005a
        regionid: 1005
        hostname: stun.nextcloud.com
        stunport: 3478
        derpport: 1

  1006:
    regionid: 1006
    regioncode: stun-nextcloud-443
    regionname: Public STUN Nextcloud 443
    nodes:
      - name: 1006a
        regionid: 1006
        hostname: stun.nextcloud.com
        stunport: 443
        derpport: 1

  1007:
    regionid: 1007
    regioncode: stun-google-1
    regionname: Public STUN Google 1
    nodes:
      - name: 1007a
        regionid: 1007
        hostname: stun1.l.google.com
        stunport: 19302
        derpport: 1

  1008:
    regionid: 1008
    regioncode: stun-google-3
    regionname: Public STUN Google 3
    nodes:
      - name: 1008a
        regionid: 1008
        hostname: stun3.l.google.com
        stunport: 19302
        derpport: 1

  1009:
    regionid: 1009
    regioncode: stun-google-4
    regionname: Public STUN Google 4
    nodes:
      - name: 1009a
        regionid: 1009
        hostname: stun4.l.google.com
        stunport: 19302
        derpport: 1

  1010:
    regionid: 1010
    regioncode: stun-voipbuster
    regionname: Public STUN Voipbuster
    nodes:
      - name: 1010a
        regionid: 1010
        hostname: stun.voipbuster.com
        stunport: 3478
        derpport: 1

  1011:
    regionid: 1011
    regioncode: stun-voipstunt
    regionname: Public STUN Voipstunt
    nodes:
      - name: 1011a
        regionid: 1011
        hostname: stun.voipstunt.com
        stunport: 3478
        derpport: 1

  1012:
    regionid: 1012
    regioncode: stun-sipnet
    regionname: Public STUN Sipnet
    nodes:
      - name: 1012a
        regionid: 1012
        hostname: stun.sipnet.net
        stunport: 3478
        derpport: 1

  1013:
    regionid: 1013
    regioncode: stun-telnyx
    regionname: Public STUN Telnyx
    nodes:
      - name: 1013a
        regionid: 1013
        hostname: stun.telnyx.com
        stunport: 3478
        derpport: 1

  1014:
    regionid: 1014
    regioncode: stun-twilio
    regionname: Public STUN Twilio
    nodes:
      - name: 1014a
        regionid: 1014
        hostname: global.stun.twilio.com
        stunport: 3478
        derpport: 1

这里的效果是：Headscale 继续提供 STUN 给 tailscale netcheck 和打洞探测使用，但 DERP 中继端口不可用，打洞失败时不会通过服务器中转流量。多 STUN 的意义是增加公网映射候选，尤其适合学校、公司这类可能按目标 IP 分配不同出口的网络；如果某个 STUN 服务器和真实 peer 目标走到同一个出口，直连打洞成功率会更高。

systemd 服务使用发行版默认的 headscale serve：

1
2
3
4
5
6
7
8


[Service]
User=headscale
Group=headscale
ExecStart=/usr/bin/headscale serve
Restart=always
WorkingDirectory=/var/lib/headscale
StateDirectory=headscale
RuntimeDirectory=headscale

节点列表脱敏后大概是这样：

1
2
3
4


100.64.0.1  headscale-server  linux
100.64.0.2  home-windows-pc   windows
100.64.0.3  other-windows-pc  windows
100.64.0.4  sfa-android       android

其中 100.64.0.2 是家里的 Windows 电脑，也是 Android 最终要访问的 SOCKS5 节点。

家里 Windows 电脑的 Tailscale 配置

Windows 端不需要额外写复杂配置，核心就是在 Headscale 服务端生成一个预授权 key，然后在 Windows 上用这个 key 加入自建控制面。

在 Headscale 服务端生成 Windows 节点使用的 key：

1

headscale preauthkeys create --user 1 --expiration 24h

如果希望这个 key 可以给多台设备重复使用，可以加 --reusable：

1

headscale preauthkeys create --user 1 --expiration 24h --reusable

然后在家里的 Windows 电脑上执行：

1

tailscale up --login-server https://<HEADSCALE_DOMAIN>:8443 --auth-key <WINDOWS_AUTH_KEY> --hostname home-windows-pc --accept-dns=true --accept-routes=true

这台电脑上需要有一个 SOCKS5 服务监听 10808。如果只监听 127.0.0.1:10808，tailnet 里的手机访问不到；需要确保它监听在 0.0.0.0:10808，或者至少监听到 Tailscale 网卡的 100.64.0.2:10808，同时 Windows 防火墙允许 tailnet 访问这个端口。

Android sing-box 配置

Android 端不要同时开官方 Tailscale App 的 VPN。Android 通常只能稳定运行一个 VPN，SFA 的 TUN 已经占用 VPN 入口，所以这里让 sing-box 自己内置一个 Tailscale endpoint。

Android 端同样需要先在 Headscale 服务端生成一个 auth key：

1

headscale preauthkeys create --user 1 --expiration 24h

如果只是给手机导入一次配置，建议使用一次性 key，不加 --reusable。生成出来的 key 填到下面 sing-box 配置的 auth_key 字段里。

完整配置如下，auth_key 已脱敏。这一份是基础版，默认最终出站都是家里电脑的 SOCKS5：

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128


{
  "log": {
    "level": "info"
  },
  "dns": {
    "servers": [
      {
        "type": "local",
        "tag": "local"
      },
      {
        "type": "https",
        "tag": "remote-dns",
        "server": "1.1.1.1",
        "server_port": 443,
        "path": "/dns-query",
        "tls": {
          "server_name": "cloudflare-dns.com"
        },
        "detour": "proxy"
      },
      {
        "type": "tailscale",
        "tag": "ts-dns",
        "endpoint": "ts-ep",
        "accept_default_resolvers": false,
        "accept_search_domain": true
      }
    ],
    "rules": [
      {
        "domain": [
          ""
        ],
        "action": "route",
        "server": "local"
      },
      {
        "preferred_by": [
          "ts-dns"
        ],
        "action": "route",
        "server": "ts-dns"
      }
    ],
    "final": "remote-dns",
    "strategy": "prefer_ipv4",
    "timeout": "10s"
  },
  "endpoints": [
    {
      "type": "tailscale",
      "tag": "ts-ep",
      "state_directory": "tailscale-home",
      "auth_key": "",
      "control_url": "https://:8443",
      "control_http_client": {
        "domain_resolver": "local"
      },
      "hostname": "sfa-android",
      "accept_routes": true,
      "udp_timeout": "5m"
    }
  ],
  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "address": [
        "172.19.0.1/30",
        "fdfe:dcba:9876::1/126"
      ],
      "auto_route": true,
      "strict_route": true,
      "dns_mode": "hijack",
      "stack": "mixed",
      "endpoint_independent_nat": true
    }
  ],
  "outbounds": [
    {
      "type": "socks",
      "tag": "proxy",
      "server": "100.64.0.2",
      "server_port": 10808,
      "version": "5",
      "network": [
        "tcp",
        "udp"
      ],
      "detour": "ts-ep"
    },
    {
      "type": "direct",
      "tag": "direct"
    },
    {
      "type": "block",
      "tag": "block"
    }
  ],
  "route": {
    "rules": [
      {
        "port": 53,
        "action": "hijack-dns"
      },
      {
        "action": "sniff"
      },
      {
        "preferred_by": [
          "ts-ep"
        ],
        "action": "route",
        "outbound": "ts-ep"
      },
      {
        "ip_is_private": true,
        "action": "route",
        "outbound": "direct"
      }
    ],
    "final": "proxy",
    "auto_detect_interface": true,
    "default_domain_resolver": "local"
  }
}

国内外分流版本

上面的基础版会把手机侧流量默认全部送到家里电脑的 100.64.0.2:10808。如果希望国内站点直连、国外站点仍然走家里 SOCKS5，可以使用下面这个分流版。它使用 geosite-cn、geoip-cn 做国内直连，使用 geosite-geolocation-!cn 做国外代理，国内 DNS 走 223.5.5.5，国外 DNS 走 Cloudflare DoH 并通过家里 SOCKS5 出口。没有命中规则的流量默认直连，避免微信这类国内 App 因规则缺失误走隧道。

这个版本会在首次启动时下载远程 .srs 规则集，后续由 cache_file 缓存。注意 cn-dns 这个 UDP DNS 服务器不要写 "detour": "direct"，新版 sing-box 会报 detour to an empty direct outbound makes no sense，因为 UDP DNS 默认就是直连。这里也不再全局阻断 UDP 443；阻断 QUIC 虽然能让部分连接回退到 TCP，但放在国内规则前面容易误伤微信、小程序和国内 App。

分流版完整配置如下，auth_key 和 Headscale 域名已脱敏：

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340


{
  "log": {
    "level": "info"
  },
  "dns": {
    "servers": [
      {
        "type": "local",
        "tag": "local"
      },
      {
        "type": "udp",
        "tag": "cn-dns",
        "server": "223.5.5.5",
        "server_port": 53
      },
      {
        "type": "https",
        "tag": "remote-dns",
        "server": "1.1.1.1",
        "server_port": 443,
        "path": "/dns-query",
        "tls": {
          "server_name": "cloudflare-dns.com"
        },
        "detour": "proxy"
      },
      {
        "type": "tailscale",
        "tag": "ts-dns",
        "endpoint": "ts-ep",
        "accept_default_resolvers": false,
        "accept_search_domain": true
      }
    ],
    "rules": [
      {
        "domain": [
          ""
        ],
        "action": "route",
        "server": "local"
      },
      {
        "preferred_by": [
          "ts-dns"
        ],
        "action": "route",
        "server": "ts-dns"
      },
      {
        "domain": [
          "googleapis.cn",
          "gstatic.com"
        ],
        "domain_suffix": [
          "googleapis.cn",
          "gstatic.com"
        ],
        "action": "route",
        "server": "remote-dns"
      },
      {
        "rule_set": [
          "geosite-geolocation-!cn"
        ],
        "action": "route",
        "server": "remote-dns"
      },
      {
        "rule_set": [
          "geosite-category-ads-all"
        ],
        "action": "predefined",
        "rcode": "NOERROR"
      },
      {
        "rule_set": [
          "geosite-private",
          "geosite-cn"
        ],
        "action": "route",
        "server": "cn-dns"
      }
    ],
    "final": "cn-dns",
    "strategy": "prefer_ipv4",
    "timeout": "10s"
  },
  "endpoints": [
    {
      "type": "tailscale",
      "tag": "ts-ep",
      "state_directory": "tailscale-home",
      "auth_key": "",
      "control_url": "https://:8443",
      "control_http_client": {
        "domain_resolver": "local"
      },
      "hostname": "sfa-android",
      "accept_routes": true,
      "udp_timeout": "5m"
    }
  ],
  "inbounds": [
    {
      "type": "tun",
      "tag": "tun-in",
      "address": [
        "172.19.0.1/30",
        "fdfe:dcba:9876::1/126"
      ],
      "auto_route": true,
      "strict_route": true,
      "dns_mode": "hijack",
      "stack": "mixed",
      "endpoint_independent_nat": true
    }
  ],
  "outbounds": [
    {
      "type": "socks",
      "tag": "proxy",
      "server": "100.64.0.2",
      "server_port": 10808,
      "version": "5",
      "network": [
        "tcp",
        "udp"
      ],
      "detour": "ts-ep"
    },
    {
      "type": "direct",
      "tag": "direct"
    },
    {
      "type": "block",
      "tag": "block"
    }
  ],
  "route": {
    "rules": [
      {
        "port": 53,
        "action": "hijack-dns"
      },
      {
        "action": "sniff"
      },
      {
        "preferred_by": [
          "ts-ep"
        ],
        "action": "route",
        "outbound": "ts-ep"
      },
      {
        "package_name": [
          "com.tencent.mm",
          "com.tencent.mobileqq"
        ],
        "action": "route",
        "outbound": "direct"
      },
      {
        "domain": [
          "googleapis.cn",
          "gstatic.com"
        ],
        "domain_suffix": [
          "googleapis.cn",
          "gstatic.com"
        ],
        "action": "route",
        "outbound": "proxy"
      },
      {
        "rule_set": [
          "geosite-category-ads-all"
        ],
        "action": "route",
        "outbound": "block"
      },
      {
        "rule_set": [
          "geosite-geolocation-!cn"
        ],
        "action": "route",
        "outbound": "proxy"
      },
      {
        "ip_is_private": true,
        "action": "route",
        "outbound": "direct"
      },
      {
        "rule_set": [
          "geosite-private"
        ],
        "action": "route",
        "outbound": "direct"
      },
      {
        "ip_cidr": [
          "223.5.5.5/32",
          "223.6.6.6/32",
          "2400:3200::1/128",
          "2400:3200:baba::1/128",
          "119.29.29.29/32",
          "1.12.12.12/32",
          "120.53.53.53/32",
          "2402:4e00::/128",
          "2402:4e00:1::/128",
          "180.76.76.76/32",
          "2400:da00::6666/128",
          "114.114.114.114/32",
          "114.114.115.115/32",
          "114.114.114.119/32",
          "114.114.115.119/32",
          "114.114.114.110/32",
          "114.114.115.110/32",
          "180.184.1.1/32",
          "180.184.2.2/32",
          "101.226.4.6/32",
          "218.30.118.6/32",
          "123.125.81.6/32",
          "140.207.198.6/32",
          "1.2.4.8/32",
          "210.2.4.8/32",
          "52.80.66.66/32",
          "117.50.22.22/32",
          "2400:7fc0:849e:200::4/128",
          "2404:c2c0:85d8:901::4/128",
          "117.50.10.10/32",
          "52.80.52.52/32",
          "2400:7fc0:849e:200::8/128",
          "2404:c2c0:85d8:901::8/128",
          "117.50.60.30/32",
          "52.80.60.30/32"
        ],
        "action": "route",
        "outbound": "direct"
      },
      {
        "domain": [
          "alidns.com",
          "doh.pub",
          "dot.pub",
          "360.cn",
          "onedns.net"
        ],
        "domain_suffix": [
          "alidns.com",
          "doh.pub",
          "dot.pub",
          "360.cn",
          "onedns.net"
        ],
        "action": "route",
        "outbound": "direct"
      },
      {
        "rule_set": [
          "geosite-cn"
        ],
        "action": "route",
        "outbound": "direct"
      },
      {
        "rule_set": [
          "geoip-cn"
        ],
        "action": "route",
        "outbound": "direct"
      }
    ],
    "rule_set": [
      {
        "type": "remote",
        "tag": "geosite-category-ads-all",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-category-ads-all.srs",
        "http_client": {
          "domain_resolver": "local"
        },
        "update_interval": "24h"
      },
      {
        "type": "remote",
        "tag": "geosite-geolocation-!cn",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-geolocation-!cn.srs",
        "http_client": {
          "domain_resolver": "local"
        },
        "update_interval": "24h"
      },
      {
        "type": "remote",
        "tag": "geosite-private",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-private.srs",
        "http_client": {
          "domain_resolver": "local"
        },
        "update_interval": "24h"
      },
      {
        "type": "remote",
        "tag": "geosite-cn",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/SagerNet/sing-geosite/rule-set/geosite-cn.srs",
        "http_client": {
          "domain_resolver": "local"
        },
        "update_interval": "24h"
      },
      {
        "type": "remote",
        "tag": "geoip-cn",
        "format": "binary",
        "url": "https://raw.githubusercontent.com/SagerNet/sing-geoip/rule-set/geoip-cn.srs",
        "http_client": {
          "domain_resolver": "local"
        },
        "update_interval": "24h"
      }
    ],
    "final": "direct",
    "auto_detect_interface": true,
    "default_domain_resolver": "local"
  },
  "experimental": {
    "cache_file": {
      "enabled": true,
      "store_dns": true
    }
  }
}

关键点是这个出站：

1
2
3
4
5
6
7


{
  "type": "socks",
  "tag": "proxy",
  "server": "100.64.0.2",
  "server_port": 10808,
  "detour": "ts-ep"
}

detour: ts-ep 表示连接 SOCKS5 服务本身时先走 Tailscale endpoint。没有这个字段，Android 的普通网络无法直接访问 100.64.0.2。

分流规则的关键点是：微信和 QQ 先按包名强制 direct，避免国内 IM 流量误走家里 SOCKS5；geosite-geolocation-!cn 明确送到 proxy，用于国外站点；final 保持 direct，让未知流量默认直连。不要把 UDP 443 阻断规则放在国内规则前面，否则微信、小程序或国内 App 的 QUIC/UDP 连接可能先被拦截，表现为发消息慢、加载卡顿。

启动顺序

Headscale 服务端先启动，确认 server_url 能访问。
家里 Windows 电脑登录 Headscale，确认拿到 100.64.0.2。
家里电脑启动 SOCKS5 服务，确认 100.64.0.2:10808 可访问。
Android 导入 sing-box 配置，启动 SFA。
在 Headscale 上查看 sfa-android 节点是否在线。

常用检查命令：

1

headscale nodes list

Windows 上检查：

1
2


tailscale status
tailscale debug prefs

NAT 类型也要检查一下。Tailscale 打洞最怕的是两端都是对称型 NAT；办公网这边是对称型 NAT 问题不大，只要家宽这一端不是对称型 NAT，通常仍然可以打出直连。如果两端都是对称型 NAT，P2P 直连大概率失败，最终会退回 DERP 中转。

在家里 Windows 电脑上跑：

1
2


tailscale netcheck
tailscale netcheck --format json

在办公网络侧也找一台同网段设备跑同样的命令：

1
2


tailscale netcheck
tailscale netcheck --format json

重点看输出里的 MappingVariesByDestIP。如果是 true，基本可以认为这一侧是对称型 NAT 或 hard NAT；如果是 false，打洞条件会好很多。本方案里最关键的是家宽侧尽量保持 MappingVariesByDestIP: false。

sing-box 配置可以先用本地源码检查：

1

go run -tags "with_gvisor,with_tailscale" ./cmd/sing-box check -c .\sing-box-android-tailscale.json

排错

如果 Android 报 unknown field accept_search_domain，升级 SFA/sing-box 到 1.14.0-alpha.21 以上。

如果 Android 能登录 Headscale 但不能访问 100.64.0.2:10808，先检查家里电脑上的 SOCKS5 是否监听在 Tailscale 可访问的地址上，再检查 Windows 防火墙。

如果 Headscale 控制面域名解析失败，确保 Android 配置里的 control_http_client.domain_resolver 指向 local，避免控制面解析也走还没建立起来的代理链路。

如果 DNS 查询异常，确认 dns_mode 是 hijack，并且 route.rules 里有 port: 53 的 hijack-dns 规则。

脱敏清单

这篇文章里隐藏了这些内容：

Headscale 服务器公网 IP。
Headscale 域名。
SSH 密码。
Tailscale auth key。
节点公钥、机器密钥和私钥路径。
证书文件真实路径。

真实环境里不要把 auth key、SSH 密码、私钥、节点 key 写进博客仓库。首次注册成功后，也建议把一次性 auth key 作废。

本文2026-05-08首发于猫猫鱼的小窝，最后修改于2026-05-08

Xray反向代理——多端口内网穿透绕过企业级防火墙兼容梯子配置方法

xxx@example.com (catcatyu) — Tue, 05 May 2026 20:00:00 +0800

Xray反向代理——多端口内网穿透绕过企业级防火墙兼容梯子配置方法

作者：catcatyu（xxx@example.com）

背景

在企业内网环境中部署服务时，经常会遇到这样的问题：

公司防火墙拦截了frp、rathole等常见内网穿透工具的协议特征
SSH隧道被DPI（深度包检测）识别并阻断
开放的端口有限，仅允许80/443等常见端口出站
传统穿透方案需要额外开放端口，增加了暴露面

我们需要一种方案：既能穿透内网暴露服务，又能伪装成正常HTTPS流量绕过防火墙检测，同时还能作为梯子使用。

方案对比

方案	性能	抗检测	备注
frp	高	差	自定义协议特征明显，容易被DPI识别和阻断
rathole	高	差	基于Noise协议，性能优秀但协议指纹已进入黑名单
SSH隧道	中	中	加密流量，但SSH握手特征明显，企业防火墙通常直接拦截
Xray VLESS+REALITY	高	强	流量与正常HTTPS访问完全一致，目前无已知检测手段

frp和rathole在性能上表现优秀，连接稳定、延迟低，但它们的协议特征已经被主流防火墙和DPI设备收录。在企业环境中，这些工具的连接往往在建立阶段就被拦截。

Xray的VLESS+REALITY+Vision组合完美解决了这个问题。REALITY协议不需要域名和证书，直接复用TLS握手，流量特征与访问正常HTTPS网站完全一致。配合反向代理功能，一个443端口同时承载多服务穿透和梯子。

架构说明

┌──────────────────┐                    ┌──────────────────┐
│   内网机器(A)     │                    │  公网服务器(B)    │
│                  │   vless+reality    │                  │
│  ┌────────────┐  │ ◄════════════════► │ ┌────────────┐  │
│  │ xray-bridge│  │    port 443        │ │xray-portal │  │
│  └────┬───────┘  │                    │ └────┬───────┘  │
│       │          │                    │      │          │
│  ┌────┴───────┐  │                    │ ┌────┴───────┐  │
│  │ 本地服务    │  │                    │ │ 80/8081/   │  │
│  │ :80        │  │                    │ │ 8082端口    │  │
│  │ :8001      │  │                    │ │ (公网访问)  │  │
│  │ :8002      │  │                    │ └────────────┘  │
│  └────────────┘  │                    │                  │
└──────────────────┘                    └──────────────────┘

流量走向

内网穿透：bridge用.internal域名连接portal → portal识别为隧道注册 → 外部HTTP流量通过dokodemo-door进入 → portal转发给bridge → bridge转发给本地服务
梯子：普通客户端用任意域名连接443 → portal识别为普通流量 → freedom直连出站

两种流量共用同一个vless+reality入站，portal通过域名自动区分。

关键配置

公网服务器（portal端）

/usr/local/etc/xray/config.json：

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112


{
  "log": {
    "loglevel": "warning"
  },
  "reverse": {
    "portals": [
      { "tag": "portal-ctfd",        "domain": "tunnel-ctfd.internal" },
      { "tag": "portal-param",       "domain": "tunnel-param.internal" },
      { "tag": "portal-unserialize", "domain": "tunnel-unserialize.internal" }
    ]
  },
  "inbounds": [
    {
      "tag": "interconn",
      "listen": "::",
      "port": 443,
      "protocol": "vless",
      "settings": {
        "clients": [
          { "id": "替换为你的UUID", "flow": "xtls-rprx-vision" }
        ],
        "decryption": "none"
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "show": false,
          "dest": "www.microsoft.com:443",
          "xver": 0,
          "serverNames": ["www.microsoft.com"],
          "privateKey": "替换为xray x25519生成的私钥",
          "shortIds": ["替换为openssl rand -hex 8生成的值"]
        }
      },
      "sniffing": {
        "enabled": true,
        "destOverride": ["http", "tls", "quic"]
      }
    },
    {
      "tag": "external-ctfd",
      "listen": "::",
      "port": 80,
      "protocol": "dokodemo-door",
      "settings": { "address": "0.0.0.0", "port": 80, "network": "tcp" }
    },
    {
      "tag": "external-param",
      "listen": "::",
      "port": 8081,
      "protocol": "dokodemo-door",
      "settings": { "address": "0.0.0.0", "port": 8081, "network": "tcp" }
    },
    {
      "tag": "external-unserialize",
      "listen": "::",
      "port": 8082,
      "protocol": "dokodemo-door",
      "settings": { "address": "0.0.0.0", "port": 8082, "network": "tcp" }
    }
  ],
  "outbounds": [
    { "tag": "direct", "protocol": "freedom" },
    { "tag": "block", "protocol": "blackhole" }
  ],
  "routing": {
    "rules": [
      {
        "comment": "公网 HTTP 流量 → 对应 portal",
        "type": "field",
        "inboundTag": ["external-ctfd"],
        "outboundTag": "portal-ctfd"
      },
      {
        "type": "field",
        "inboundTag": ["external-param"],
        "outboundTag": "portal-param"
      },
      {
        "type": "field",
        "inboundTag": ["external-unserialize"],
        "outboundTag": "portal-unserialize"
      },
      {
        "comment": "bridge 来的隧道注册请求 → 对应 portal",
        "type": "field",
        "inboundTag": ["interconn"],
        "domain": ["full:tunnel-ctfd.internal"],
        "outboundTag": "portal-ctfd"
      },
      {
        "type": "field",
        "inboundTag": ["interconn"],
        "domain": ["full:tunnel-param.internal"],
        "outboundTag": "portal-param"
      },
      {
        "type": "field",
        "inboundTag": ["interconn"],
        "domain": ["full:tunnel-unserialize.internal"],
        "outboundTag": "portal-unserialize"
      },
      {
        "comment": "梯子流量（非 .internal 流量）",
        "type": "field",
        "inboundTag": ["interconn"],
        "outboundTag": "direct"
      }
    ]
  }
}

内网机器（bridge端）

/usr/local/etc/xray/bridge-config.json：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88


{
  "log": {
    "loglevel": "warning"
  },
  "reverse": {
    "bridges": [
      { "tag": "bridge-ctfd",        "domain": "tunnel-ctfd.internal" },
      { "tag": "bridge-param",       "domain": "tunnel-param.internal" },
      { "tag": "bridge-unserialize", "domain": "tunnel-unserialize.internal" }
    ]
  },
  "outbounds": [
    {
      "tag": "interconn",
      "protocol": "vless",
      "settings": {
        "vnext": [{
          "address": "替换为公网服务器IP",
          "port": 443,
          "users": [{
            "id": "替换为你的UUID",
            "flow": "xtls-rprx-vision",
            "encryption": "none"
          }]
        }]
      },
      "streamSettings": {
        "network": "tcp",
        "security": "reality",
        "realitySettings": {
          "fingerprint": "chrome",
          "serverName": "www.microsoft.com",
          "publicKey": "替换为xray x25519生成的公钥",
          "shortId": "替换为openssl rand -hex 8生成的值",
          "spiderX": "/"
        }
      }
    },
    {
      "tag": "out-ctfd",
      "protocol": "freedom",
      "settings": { "redirect": "127.0.0.1:80" }
    },
    {
      "tag": "out-param",
      "protocol": "freedom",
      "settings": { "redirect": "127.0.0.1:8001" }
    },
    {
      "tag": "out-unserialize",
      "protocol": "freedom",
      "settings": { "redirect": "127.0.0.1:8002" }
    }
  ],
  "routing": {
    "rules": [
      {
        "comment": "bridge 注册握手 → 连接 portal",
        "inboundTag": ["bridge-ctfd"],
        "domain": ["full:tunnel-ctfd.internal"],
        "outboundTag": "interconn"
      },
      {
        "inboundTag": ["bridge-param"],
        "domain": ["full:tunnel-param.internal"],
        "outboundTag": "interconn"
      },
      {
        "inboundTag": ["bridge-unserialize"],
        "domain": ["full:tunnel-unserialize.internal"],
        "outboundTag": "interconn"
      },
      {
        "comment": "portal 转发来的实际流量 → 本地服务",
        "inboundTag": ["bridge-ctfd"],
        "outboundTag": "out-ctfd"
      },
      {
        "inboundTag": ["bridge-param"],
        "outboundTag": "out-param"
      },
      {
        "inboundTag": ["bridge-unserialize"],
        "outboundTag": "out-unserialize"
      }
    ]
  }
}

Systemd 服务配置

bridge端

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


# /etc/systemd/system/xray-bridge.service
[Unit]
Description=Xray Bridge (reverse proxy client)
After=network.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/xray run -config /usr/local/etc/xray/bridge-config.json
Restart=always
RestartSec=5
LimitNOFILE=1048576
User=root

[Install]
WantedBy=multi-user.target

portal端

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


# /etc/systemd/system/xray.service
[Unit]
Description=Xray Portal (reverse proxy server)
After=network.target
Wants=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/xray run -config /usr/local/etc/xray/config.json
Restart=always
RestartSec=5
LimitNOFILE=1048576
User=root

[Install]
WantedBy=multi-user.target

生成 Reality 密钥对

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


# 安装 xray
bash -c "$(curl -L https://github.com/XTLS/Xray-install/raw/main/install-release.sh)" @ install

# 生成密钥对（portal端用私钥，bridge端用公钥）
xray x25519

# 生成 shortId（两端保持一致）
openssl rand -hex 8

# 生成 UUID（两端保持一致）
xray uuid

作为梯子使用

portal的443端口同时支持梯子功能。任何支持VLESS的客户端都可以连接使用。

节点链接（可直接导入v2rayN/Clash）

vless://替换UUID@替换公网IP:443?encryption=none&flow=xtls-rprx-vision&security=reality&sni=www.microsoft.com&fp=chrome&pbk=替换公钥&sid=替换shortId&spx=%2F&type=tcp#节点名称

Clash配置示例

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


proxies:
  - name: "xray-reality"
    type: vless
    server: 替换公网IP
    port: 443
    uuid: 替换UUID
    network: tcp
    tls: true
    udp: true
    flow: xtls-rprx-vision
    servername: www.microsoft.com
    reality-opts:
      public-key: 替换公钥
      short-id: 替换shortId
    client-fingerprint: chrome

注意事项

版本一致性：bridge和portal必须使用相同版本的Xray
不要重复开启Mux：反向代理底层已使用Mux.cool，不要在interconn outbound上再次开启mux
启动顺序：建议先启动bridge，再启动portal
bridge端不需要inbound：reverse.bridges本身就是虚拟inbound，不需要额外配置dokodemo-door
域名路由规则顺序：.internal的规则必须放在direct规则之前
穿透服务数量：每增加一个穿透服务，需要在两端各加一组bridge/portal + 对应的路由规则

参考文档

本文2026-05-05首发于猫猫鱼的小窝，最后修改于2026-05-05

windows下安装openssh server卡顿的时候使用代理安装的方法

xxx@example.com (catcatyu) — Tue, 28 Apr 2026 23:55:00 +0800

windows下安装openssh server卡顿的时候使用代理安装的方法

作者：catcatyu（xxx@example.com）

问题现象

一开始我是从 Windows 的“设置 -> 系统 -> 可选功能 -> 查看功能”里添加 OpenSSH 服务器，界面一直停在“正在添加”，进度很慢：

后面不再等可选功能页面，改成用命令行安装和排查 OpenSSH Server：

1

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

命令执行很慢，长时间没有进度。即使给当前 PowerShell 加了代理，例如：

1
2


$env:http_proxy="http://127.0.0.1:10809"
$env:https_proxy="http://127.0.0.1:10809"

也不一定有用。

原因是 Add-WindowsCapability 背后不是简单的 PowerShell 下载，而是通过 Windows Update、BITS、CBS/TrustedInstaller 这些系统组件去获取 FoD（Features on Demand）内容。当前用户的环境变量代理不等于系统服务账户代理。

排查过程

先看 WinHTTP 代理：

1

netsh winhttp show proxy

再看代理端口是否真的在监听：

1

Get-NetTCPConnection -LocalAddress 127.0.0.1 -LocalPort 10809 -State Listen

如果使用 v2rayN/xray，通常 HTTP 代理端口是 127.0.0.1:10809；如果使用 Clash，常见端口是 127.0.0.1:7890。

然后看 CBS/DISM 日志：

1
2


Select-String -Path C:\Windows\Logs\CBS\CBS.log -Pattern "FCAcquirerWUClient|DownloadProgress|0x"
Select-String -Path C:\Windows\Logs\DISM\dism.log -Pattern "OpenSSH|Add-Capability|0x"

我这里看到的关键日志是：

1

FCAcquirerWUClient: WULib DownloadProgress: [0 / 100]

也就是卡在 Windows Update 下载阶段，并不是 OpenSSH 本身安装慢。

还要检查 CBS 是否有待重启事务：

1
2


Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending"
Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired"

如果返回 True，建议先重启。CBS 有 pending reboot 时，Add-WindowsCapability 很容易卡住、失败或重复下载。

正确的代理配置

以 127.0.0.1:10809 为例，管理员 PowerShell 执行：

1

netsh winhttp set proxy proxy-server="http=127.0.0.1:10809;https=127.0.0.1:10809" bypass-list="localhost;127.0.0.1;"

再给 BITS 的三个服务账户设置代理：

1
2
3


bitsadmin /util /setieproxy localsystem MANUAL_PROXY 127.0.0.1:10809 NULL
bitsadmin /util /setieproxy networkservice MANUAL_PROXY 127.0.0.1:10809 NULL
bitsadmin /util /setieproxy localservice MANUAL_PROXY 127.0.0.1:10809 NULL

重启相关服务：

1

Restart-Service wuauserv,bits,DoSvc,cryptsvc -Force

如果之前已经卡了很久，建议直接重启系统。我的情况就是代理配置正确后仍然卡在 0%，重启清掉 CBS pending 状态后才成功。

重新安装 OpenSSH Server

重启后确认代理程序已经启动，端口能连通：

1

Test-NetConnection 127.0.0.1 -Port 10809

然后执行：

1

dism.exe /Online /Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0

也可以继续使用 PowerShell：

1

Add-WindowsCapability -Online -Name OpenSSH.Server~~~~0.0.1.0

注意 capability 名称最后是 0.0.1.0，不要写成 0.0.1.。

安装后启用 sshd

安装成功后检查文件和服务：

1
2


Test-Path C:\Windows\System32\OpenSSH\sshd.exe
Get-Service sshd

启用并启动服务：

1
2


Set-Service -Name sshd -StartupType Automatic
Start-Service -Name sshd

开放防火墙 22 端口：

1
2
3
4
5
6
7
8


New-NetFirewallRule `
  -Name "OpenSSH-Server-In-TCP" `
  -DisplayName "OpenSSH SSH Server (sshd)" `
  -Enabled True `
  -Direction Inbound `
  -Protocol TCP `
  -Action Allow `
  -LocalPort 22

如果规则已经存在，可以改成所有网络配置文件都生效：

1

Set-NetFirewallRule -Name "OpenSSH-Server-In-TCP" -Enabled True -Profile Any

验证

查看服务：

1

Get-Service sshd

正常应该是：

1
2


Status   : Running
StartType: Automatic

查看监听：

1

netstat -ano -p tcp | Select-String ":22 "

正常会看到：

1

TCP    0.0.0.0:22    0.0.0.0:0    LISTENING

局域网其他机器连接：

1

ssh 用户名@Windows主机IP

例如：

1

ssh fjh1996@192.168.1.10

总结

这个问题的关键点是：

http_proxy / https_proxy 只影响当前进程，不足以让 Windows Update 服务走代理。
Add-WindowsCapability 背后依赖 Windows Update、BITS 和 CBS。
需要同时配置 WinHTTP 代理和 BITS 服务账户代理。
如果 CBS 已经有 RebootPending，先重启，否则可能一直卡在 DownloadProgress: [0 / 100]。
安装成功后还要启动 sshd 服务并检查防火墙规则。

最终有效流程就是：

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


netsh winhttp set proxy proxy-server="http=127.0.0.1:10809;https=127.0.0.1:10809" bypass-list="localhost;127.0.0.1;"

bitsadmin /util /setieproxy localsystem MANUAL_PROXY 127.0.0.1:10809 NULL
bitsadmin /util /setieproxy networkservice MANUAL_PROXY 127.0.0.1:10809 NULL
bitsadmin /util /setieproxy localservice MANUAL_PROXY 127.0.0.1:10809 NULL

Restart-Service wuauserv,bits,DoSvc,cryptsvc -Force

dism.exe /Online /Add-Capability /CapabilityName:OpenSSH.Server~~~~0.0.1.0

Set-Service -Name sshd -StartupType Automatic
Start-Service -Name sshd

本文2026-04-28首发于猫猫鱼的小窝，最后修改于2026-04-28

VMware Workstation 虚拟网卡丢失 + VMware Tools 复制粘贴失效的完整排查与修复

xxx@example.com (catcatyu) — Thu, 16 Apr 2026 14:38:00 +0800

VMware Workstation 虚拟网卡丢失 + VMware Tools 复制粘贴失效的完整排查与修复

作者：catcatyu（xxx@example.com）

问题背景

宿主机 Windows（VMware Workstation 17.6.0），虚拟机 Windows 7 SP1 32位。遇到两个问题：

宿主机无法连接虚拟机（ping 不通）
修复网络后，VMware Tools 的复制粘贴功能不工作

以下是完整的排查过程。

问题一：宿主机无法连接虚拟机

现象

虚拟机 IP 为 192.168.191.129（NAT 模式），从宿主机 ping 100% 丢包：

ping 192.168.191.129
请求超时。
请求超时。
数据包: 已发送 = 2，已接收 = 0，丢失 = 2 (100% 丢失)

排查过程

检查宿主机网卡状态：

1

Get-NetAdapter | Format-Table Name, InterfaceDescription, Status, MacAddress -AutoSize

Name                          InterfaceDescription                       Status      MacAddress
----                          --------------------                       ------      ----------
以太网                        Intel(R) Ethernet Connection (22) I219-LM  Up          F4-F1-9E-42-D8-DD
VMware Network Adapter VMnet1 VMware Virtual Ethernet Adapter for VMnet1 Not Present 00-50-56-C0-00-01
VMware Network Adapter VMnet8 VMware Virtual Ethernet Adapter for VMnet8 Not Present 00-50-56-C0-00-08

关键发现：VMnet1（Host-Only）和 VMnet8（NAT）状态都是 Not Present，AdminStatus: Down。

再看 IPv4 地址分配：

1

Get-NetIPAddress -AddressFamily IPv4 | Format-Table InterfaceAlias, IPAddress, PrefixLength -AutoSize

InterfaceAlias              IPAddress   PrefixLength
--------------              ---------   ------------
以太网                      10.30.17.50           24
Loopback Pseudo-Interface 1 127.0.0.1              8

宿主机只有物理网卡有 IP，VMware 虚拟网卡完全没有加载，自然没有到 192.168.191.x 网段的路由。

同时 VMware NAT Service 虽然在运行，但网卡驱动本身没有加载：

1

Get-Service -Name 'VMware*' | Format-Table Name, DisplayName, Status -AutoSize

Name                   DisplayName          Status
----                   -----------          ------
VMware NAT Service     VMware NAT Service  Running
VmwareAutostartService VMware 自动启动服务  Stopped

根因

VMware 虚拟网卡驱动未正确加载，网卡处于 Not Present 状态。NAT Service 虽然在跑，但没有对应的虚拟网卡承载流量。

解决方法

打开 VMware Workstation → Edit → Virtual Network Editor → 点击 “Restore Defaults”（需要管理员权限）。这会重新创建 VMnet1/VMnet8 并重装虚拟网卡驱动。

如果不行，还可以：

在设备管理器中检查是否有被禁用或带感叹号的 VMware 网卡，右键启用或更新驱动
修复安装 VMware Workstation（运行安装程序选 Repair）

恢复后虚拟机 IP 变为 192.168.78.128，网络连通。

问题二：VMware Tools 服务启动失败

现象

网络恢复后，SSH 进入虚拟机发现 VMware Tools 没有正常工作。

排查过程

通过 SSH（paramiko）远程执行命令检查（注意：这台 VM 是 Windows 7，不是 Linux）：

1

sc query VMTools

SERVICE_NAME: VMTools
        TYPE               : 10  WIN32_OWN_PROCESS
        STATE              : 1  STOPPED
        WIN32_EXIT_CODE    : 183 (0xB7)

VMTools 服务状态为 STOPPED，退出码 183（ERROR_ALREADY_EXISTS）。

同时检查进程：

1

tasklist | findstr /i vmtoolsd

发现 vmtoolsd.exe（PID 1868）在用户会话（Console Session 1）里运行着——这是用户态的托盘进程，但系统服务层面的 VMTools 没有启动。

根因

之前异常退出后残留了用户态 vmtoolsd.exe 进程，占用了资源，导致系统服务启动时报错 183（ERROR_ALREADY_EXISTS，资源冲突）。

解决方法

1
2
3
4
5


:: 先杀掉残留的 vmtoolsd 进程
taskkill /f /im vmtoolsd.exe

:: 然后重新启动服务
net start VMTools

执行后服务恢复正常：

SERVICE_NAME: VMTools
        STATE              : 4  RUNNING
        WIN32_EXIT_CODE    : 0

问题三：复制粘贴仍然不工作

现象

VMTools 服务正常运行后，宿主机和虚拟机之间的复制粘贴仍然不可用。

排查过程

第一步：检查用户态进程

复制粘贴功能依赖两个 vmtoolsd.exe 进程：

系统服务进程（Session 0）：负责基础的 Guest-Host 通信
用户态进程 vmtoolsd.exe -n vmusr（桌面会话）：负责加载 dndcp.dll 插件处理剪贴板同步和拖拽

检查发现只有系统服务进程在运行，用户态进程缺失。

确认插件文件存在：

1

dir "C:\Program Files\VMware\VMware Tools\plugins\vmusr"

dndcp.dll（拖拽和复制粘贴插件）文件完好。

注册表中 VMware User Process 启动项也存在，但重启后用户态进程就是没有自动拉起。

第二步：尝试手动启动用户态进程

由于 SSH 会话处于 Session 0（服务会话），直接 start 无法在 Session 1 的桌面上创建进程。通过创建批处理文件 + 计划任务的方式在用户桌面会话中启动：

1
2
3


echo start "" "C:/PROGRA~1/VMware/VMware Tools/vmtoolsd.exe" -n vmusr > C:/vmusr.bat
schtasks /create /tn "StartVMusr" /tr "C:/vmusr.bat" /sc once /st 00:00 /f /rl highest
schtasks /run /tn "StartVMusr"

启动后确认两个进程都在运行：

PID 1384 — Services 会话（系统服务）
PID 2772 — Console Session 1，ADMIN 用户（用户态）

但复制粘贴仍然不工作，而且重启虚拟机后用户态进程又消失了。说明手动拉起只是临时方案，根本原因在别处。

第三步：检查 VMX 配置

检查虚拟机的 .vmx 配置文件（D:\Windows 7\Windows 7.vmx），发现只有：

isolation.tools.hgfs.disable = "FALSE"

缺少 copy/paste 相关的配置项。在 VMware Workstation 17 上，如果没有显式启用，默认可能是禁用的。

通过 rpctool 在 Guest 内确认 isolation 状态均为 UNSET，说明 VMX 层面没有显式配置。

根因

两个原因叠加：

VMX 配置文件中缺少 isolation.tools.copy.disable = "FALSE" 和 isolation.tools.paste.disable = "FALSE" 的显式配置，在 Workstation 17 上默认行为可能是禁用
由于 isolation 配置缺失，用户态 vmtoolsd -n vmusr 进程无法正常自动启动（负责剪贴板同步的进程缺失）

也就是说，用户态进程不自动启动的根本原因就是 VMX 里缺少 isolation 配置。加上配置后，重启虚拟机用户态进程就能正常自动拉起了。

解决方法

关闭虚拟机，在 .vmx 文件中添加以下三行：

isolation.tools.copy.disable = "FALSE"
isolation.tools.paste.disable = "FALSE"
isolation.tools.dnd.disable = "FALSE"

然后重新启动虚拟机。启动后验证：

VMTools 服务正常运行（RUNNING）
用户态 vmtoolsd -n vmusr（Console Session 1）自动启动——之前一直无法自启的问题也一并解决
复制粘贴功能恢复正常

总结

问题	根因	解决方法
宿主机 ping 不通虚拟机	VMware 虚拟网卡驱动未加载（Not Present）	Virtual Network Editor → Restore Defaults
VMTools 服务启动失败（错误码 183）	残留的用户态 vmtoolsd 进程占用资源	`taskkill /f /im vmtoolsd.exe` 后重启服务
复制粘贴不工作 + 用户态 vmtoolsd 不自启	VMX 缺少 isolation 配置，导致用户态进程无法自启	在 vmx 中添加 copy/paste/dnd 的 disable=FALSE 配置后重启

本文2026-04-16首发于猫猫鱼的小窝，最后修改于2026-04-16

Ubuntu 24.04 安装 NVIDIA 驱动后 GNOME 远程桌面黑屏/灰屏的排错与解决

xxx@example.com (catcatyu) — Thu, 26 Mar 2026 17:40:00 +0800

Ubuntu 24.04 安装 NVIDIA 驱动后 GNOME 远程桌面黑屏/灰屏的排错与解决

作者：catcatyu（xxx@example.com）

问题描述

Ubuntu 24.04 LTS 工作站，安装 NVIDIA 闭源驱动（nvidia-driver-580）后，通过 Windows 远程桌面连接（mstsc）使用 GNOME 内置 RDP 服务连接时，出现灰屏或黑屏，无法正常显示桌面。

环境信息：

系统：Ubuntu 24.04 LTS (Noble Numbat)
内核：6.17.0-19-generic
独显：NVIDIA GeForce RTX 4070
驱动：nvidia-driver-580 (580.126.09)
远程桌面服务：GNOME Remote Desktop (gnome-remote-desktop 46.2)
客户端：Windows 11 远程桌面连接 (mstsc)

根因分析

GNOME Remote Desktop 的 RDP 连接链路如下：

Windows mstsc → GNOME Remote Desktop (系统级)
    → handover → 用户桌面会话
        → Mutter 合成器 → PipeWire 屏幕捕获
            → gnome-remote-desktop (用户级) → RDP 编码输出

问题的根本原因是 Ubuntu 24.04 默认安装的 gnome-shell（46.0-0ubuntu6~24.04.3）和 gnome-remote-desktop（46.2）版本过低，在 NVIDIA 闭源驱动环境下存在以下 bug：

gnome-shell 在 RDP handover 时 segfault：通过 RDP 登录触发用户会话创建时，gnome-shell 在 libc.so.6 中发生 general protection fault 崩溃，导致用户会话无法注册，GDM 报 Session never registered, failing。
gnome-remote-desktop handover 超时：即使 gnome-shell 不崩溃，旧版 gnome-remote-desktop 在 NVIDIA + Wayland 环境下的 handover 流程也存在缺陷，日志表现为 Failed to request remote desktop handover: Timeout was reached。

通过对比一台配置相似但 RDP 工作正常的机器（同样使用 NVIDIA 闭源驱动 580 + Wayland），发现其 gnome-shell 版本为 46.0-0ubuntu6~24.04.13，gnome-remote-desktop 版本为 46.3-0ubuntu1.2，均高于出问题的机器。升级后问题解决。

解决方案

一条命令：

1

sudo apt update && sudo apt install -y gnome-shell gnome-remote-desktop mutter

升级后重启：

1

sudo reboot

验证

1
2
3
4
5
6
7
8
9


# 确认版本
dpkg -l | grep -E 'gnome-shell |gnome-remote-desktop '
# gnome-shell         46.0-0ubuntu6~24.04.13
# gnome-remote-desktop 46.3-0ubuntu1.2

# 确认远程桌面服务正常
journalctl --user -u gnome-remote-desktop --since '1 min ago'
# 应显示 "RDP server started"
# CUDA 初始化成功：[RDP] Initialization of CUDA was successful

使用 Windows 远程桌面连接，输入 IP、用户名和密码，即可正常看到桌面。NVIDIA GPU 的 CUDA 计算能力不受影响。

版本对比

包	修复前（黑屏）	修复后（正常）
gnome-shell	46.0-0ubuntu6~24.04.3	46.0-0ubuntu6~24.04.13
gnome-remote-desktop	46.2-1~ubuntu24.04.2	46.3-0ubuntu1.2
mutter	旧版	46.2-1ubuntu0.24.04.14

总结

这个问题不是 NVIDIA 驱动本身的兼容性问题，而是 Ubuntu 24.04 早期版本的 gnome-shell 和 gnome-remote-desktop 在 NVIDIA 驱动环境下存在 bug。升级到最新的补丁版本即可修复，无需切换核显、修改 prime-select 或更换远程桌面工具。

本文2026-03-26首发于猫猫鱼的小窝，最后修改于2026-03-26

彻底解决移动光猫（ZN-M180G）IPv6 频繁掉线：禁用高负载 Java/OSGi 插件实录

xxx@example.com (catcatyu) — Thu, 19 Mar 2026 19:30:00 +0800

彻底解决移动光猫（ZN-M180G）IPv6 频繁掉线：禁用高负载 Java/OSGi 插件实录

作者：catcatyu（xxx@example.com）

彻底解决移动光猫（ZN-M180G）IPv6 频繁掉线

0. 参考文献与前置准备

在进行任何底层操作前，请务必参考以下社区讨论，确保您拥有光猫的超级管理权限。

参考文献：恩山无线论坛 - 移动光猫 ZN-M180G/ZTE 系维护指南
开启 Telnet 方法：在浏览器地址栏直接输入以下地址并回车，显示 TelnetSet Success 即表示开启成功： http://192.168.1.1/usr=CMCCAdmin&psw=aDm8H%25MdA&cmd=1&telnet.gch (注：默认超级账号为 CMCCAdmin，密码通常为 aDm8H%MdA)

1. 问题现象

家中的移动光猫（ZN-M180G）IPv6 连接极度不稳定。表现为：电脑刚开机时有 IPv6 且通畅，但过一段时间（几十分钟到几小时）后，IPv6 地址会突然消失，或者虽然有地址但无法 Ping 通。必须手动去路由器后台重开关 RA/DHCPv6 才能暂时恢复。

与此形成鲜明对比的是，IPv4 却始终稳如泰山。

2. 深度排查：为什么 IPv6 会掉？

2.1 性能分析：Load Average 13 的惊悚现场

通过 Telnet 登录光猫后台，执行 uptime 和 top 命令，发现了令人震惊的一幕：

1
2


~ $ uptime
Load average: 13.35 12.43 11.99

诊断：对于这类嵌入式网关，Load Average 超过 1 即为满载。13 意味着系统的处理压力是其极限能力的 10 倍以上！

2.2 罪魁祸首：OSGi 与 Java 插件

在进程列表（ps）中，我们发现了一个占用超过 239MB 内存 的 Java 进程：

1

1420  1  java  S  239m 50.1  0  0.0 java -noverify -Dfile.encoding=UTF-8 ...

这就是移动光猫预装的 OSGi (Open Service Gateway Initiative) 智能插件环境（如 AndLink/和家亲插件）。它极其吃资源，抢占了内核处理 IPv6 报文的信号量。

2.3 根源分析：IPv6 的“心跳机制”

IPv6 依赖路由器周期性发送 RA (Router Advertisement) 通告。当光猫 CPU 被 Java 插件占满时，RA 发送进程会被卡死。电脑听不到“心跳”通告，就会认为 IPv6 已失效，从而删除地址。而 IPv4 是基于租约制的“合同”，对 CPU 实时性要求较低，所以 IPv4 没问题。

3. 终极解决方案：三维打击

由于网页端（Web）往往隐藏了插件开关，且简单的 kill 命令无法阻止插件自动重启，我们采取以下三种深度修复手段：

3.1 文件层：重命名 Java 二进制（断其生路）

通过 Telnet 将 Java 的执行文件改名，这样即便启动脚本尝试调用，也会因找不到文件而失败。

1
2


# Telnet 登录后执行
mv /usr/local/osgi/local/j2re/bin/java /usr/local/osgi/local/j2re/bin/java_bak

3.2 配置层：sidbg 数据库修改（锁其开关）

利用中兴系底层的 sidbg 工具，从数据库层面彻底关闭 OSGi 启动项。

1
2
3
4
5
6
7


# 禁用 OSGi 服务
sidbg 1 DB set OBJ_OSGI_ID 0 Enable 0
# 禁用 AndLink 服务
sidbg 1 DB set OBJ_ANDLINK_ID 0 Enable 0
# 保存配置并重启
sidbg 1 DB save
reboot

3.3 客户端层：Windows 协议栈重置（清理残留）

光猫重启后，由于前缀可能变化，电脑会残留过期的 IPv6 租约。需在电脑端以管理员权限运行：

1
2
3
4
5
6


# 重置 IPv6 协议栈并重启网卡
netsh int ipv6 reset
Disable-NetAdapter -Name "以太网"
Enable-NetAdapter -Name "以太网"
# 重新请求地址
ipconfig /renew6

4. 修复结果对比

修复前：Load Average > 11，Java 进程常驻，IPv6 每小时掉线一次。
修复后：Load Average < 1.0，CPU 占用率跌至 10% 以下，内存释放 200MB+，IPv6 永久在线且延迟极低。

5. 总结

移动定制路由器的 IPv6 不稳定，90% 的原因都是因为预装的 Java 插件抢占了系统资源。通过 “改名 + 数据库禁用” 的方案，不仅能解决 IPv6 掉线问题，还能显著提升光猫的转发性能和网页后台响应速度。

本文由 Gemini CLI 协作排查整理而成。

本文2026-03-19首发于猫猫鱼的小窝，最后修改于2026-03-19

甲骨文云保留ip重置云主机ssh密钥

xxx@example.com (catcatyu) — Thu, 19 Mar 2026 09:26:12 +0800

甲骨文云保留ip重置云主机ssh密钥

作者：catcatyu（xxx@example.com）

想重置密钥，一般可以通过保留引导卷删除实例，然后用新实例套上老引导卷来重置密钥，但这样会丢失ip，想保留ip就只能另想办法，折腾一上午搞定了:
在控制台里面启动cloud shell连接

之后重启实例，重新引导等一段时间进入bios 在启动项里面选择ubuntu然后使劲不停按esc，手速要快进入grub shell 使用以下命令查看grub引导配置文件

cat (hd0,gpt16)/grub/grub.cfg

根据配置里面的uuid编写以下重启命令,输入，建议一行行粘贴，以免串口出现问题


set root='hd0,gpt16'

linux /vmlinuz-6.17.0-1009-oracle root=UUID=e0f59922-b350-40cc-b9a1-02d3da04fd65 rw console=tty1 console=ttyS0 nvme.shutdown_timeout=10 libiscsi.debug_libiscsi_eh=1 crash_kexec_post_notifiers init=/bin/bash

initrd /initrd.img-6.17.0-1009-oracle

确保输入正确之后

boot

进入shell，就能修改密码了之后使用reboot -f 进行重启，不能用exit。不然会卡住

参考：https://www.banzhuti.com/7340.html

本文2026-03-19首发于猫猫鱼的小窝，最后修改于2026-03-19

通过配置 Edge 浏览器 DoH 和 ECH 实现特定网站如linuxdo裸连访问

xxx@example.com (catcatyu) — Mon, 16 Mar 2026 12:00:00 +0800

通过配置 Edge 浏览器 DoH 和 ECH 实现特定网站如linuxdo裸连访问

作者：catcatyu（xxx@example.com）

前言

有些网站虽然没有被 DNS 污染，但由于 SNI（Server Name Indication）明文暴露了域名，导致连接在 TLS 握手阶段被中间设备识别并重置。典型表现是 DNS 能正常解析出 IP，ping 也通，但浏览器就是打不开页面。

解决思路很简单：DoH（DNS over HTTPS） 加密 DNS 查询过程，防止 DNS 劫持和污染；ECH（Encrypted Client Hello） 加密 TLS 握手中的 SNI 字段，让中间设备无法识别你访问的具体域名。两者配合就可以实现某些被 SNI 阻断的网站的裸连访问。

本文以 Windows + Edge 浏览器为例，记录完整的配置过程。

原理简述

DoH（DNS over HTTPS）

传统 DNS 查询是明文 UDP 协议，任何中间人都能看到和篡改。DoH 将 DNS 查询封装在 HTTPS 请求中，让 DNS 解析过程完全加密。

ECH（Encrypted Client Hello）

TLS 1.3 握手时，客户端会在 Client Hello 中以明文发送 SNI（要访问的域名）。ECH 利用事先通过 DNS HTTPS 记录获取的公钥，对整个 Client Hello 进行加密，让中间设备无法窥探目标域名。

两者的关系

ECH 的密钥是通过 DNS 的 HTTPS 类型记录（TYPE65）分发的。如果 DNS 查询本身不加密（被劫持或污染），ECH 密钥就拿不到，ECH 自然也无法工作。所以 DoH 是 ECH 的前置条件。

┌─────────────────────┐
│   DoH DNS 服务器     │
│  (加密 DNS 查询)     │
└────────┬────────────┘
     │
① 通过 HTTPS 加密查询 DNS
② 获取目标站点的 ECH 公钥
     │
┌────▼──────┐                ┌────────────┐              ┌──────────────┐
│  浏览器   │───③ 加密的───→│  中间设备    │────────────→│  目标服务器   │
│          │   Client Hello│ (看不到 SNI) │              │              │
└──────────┘                └─────────────┘              └──────────────┘

配置步骤

第一步：配置 Edge 的 DoH 策略

Edge 浏览器的 DoH 可以通过 Windows 注册表（组策略）来配置。以管理员权限打开 PowerShell，执行以下命令：

1
2
3
4
5
6
7
8


# 启用 Edge 内置 DNS 客户端
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v BuiltInDnsClientEnabled /t REG_DWORD /d 1 /f

# 设置 DoH 模式为 automatic（优先 DoH，失败回退普通 DNS）
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v DnsOverHttpsMode /t REG_SZ /d "automatic" /f

# 设置 DoH 服务器模板（替换为你可用的 DoH 服务器地址）
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v DnsOverHttpsTemplates /t REG_SZ /d "https://your-doh-server.example.com/dns-query" /f

DnsOverHttpsMode 的三种模式：

模式	说明
`off`	完全关闭 DoH
`automatic`	优先 DoH，失败自动回退普通 DNS（推荐）
`secure`	强制 DoH，失败则无法解析（⚠️ 如果 DoH 服务器不可用会导致所有网站打不开）

⚠️ 注意：secure 模式虽然安全性最高，但如果你的 DoH 服务器在当前网络不可达（比如国内直连 Cloudflare 的 1.1.1.1），会导致所有网站都无法访问。建议使用 automatic 模式。

关于 DoH 服务器的选择：

Cloudflare 的 https://cloudflare-dns.com/dns-query（1.1.1.1）是最常见的支持 ECH 密钥分发的 DoH 服务器，但在国内网络可能不可直连。
推荐：使用 Cloudflare Gateway (Zero Trust) 创建私人 DoH 节点。只需要注册一个免费的 Cloudflare 账号，开通 Zero Trust，在 Gateway -> DNS Locations 中添加一个 Location，它就会自动为你生成一个私有专属的 DoH 地址（例如 https://<一串随机字符>.cloudflare-gateway.com/dns-query）。这种方式目前在国内直连的成功率非常高，而且完全支持 ECH。
阿里 DNS 的 https://dns.alidns.com/dns-query 在国内虽然可用，但它不一定支持返回 HTTPS 类型 DNS 记录（ECH 所需），所以不推荐用作 ECH 方案。
如果你有自建的 DoH 代理或中转服务器，使用你自己的 DoH 地址效果最好，如 linux.do 站长秦始皇提供的 DoH 地址是：https://xxx.ddd.oaifree.com/query-dns（其中 xxx 可以随便换成你喜欢的字符）。

验证配置：

1
2
3


reg query "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v DnsOverHttpsMode
reg query "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v DnsOverHttpsTemplates
reg query "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v BuiltInDnsClientEnabled

第二步：启用 Edge 的 ECH 功能

ECH 同样可以通过注册表策略来启用。以管理员权限执行：

1
2


# 启用 Encrypted Client Hello
reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v EncryptedClientHelloEnabled /t REG_DWORD /d 1 /f

验证：

1

reg query "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v EncryptedClientHelloEnabled

💡 说明：较早版本的 Edge 可以在 edge://flags/#encrypted-client-hello 中手动启用 ECH，但新版 Edge（146+）已移除该 flag，需要通过注册表策略 EncryptedClientHelloEnabled 来控制。

第三步：（可选）配置系统级 DNS 加密

除了 Edge 内部的 DoH 之外，还可以在 Windows 系统层面配置 DNS 加密，让系统的 DNS 查询也走加密通道：

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


# 以管理员权限运行

# 1. 将以太网适配器的 DNS 设置为 1.1.1.1 和 1.0.0.1
#    先用 Get-NetAdapter 查看你的网络适配器名称和 InterfaceIndex
Get-NetAdapter | Where-Object Status -eq 'Up' | Select-Object Name, InterfaceIndex

# 2. 设置 DNS 服务器（将 13 替换为你的适配器 InterfaceIndex）
Set-DnsClientServerAddress -InterfaceIndex 13 -ServerAddresses "1.1.1.1","1.0.0.1"

# 3. 启用 DoH 自动升级
Set-DnsClientDohServerAddress -ServerAddress "1.1.1.1" `
    -DohTemplate "https://cloudflare-dns.com/dns-query" `
    -AllowFallbackToUdp $true -AutoUpgrade $true

Set-DnsClientDohServerAddress -ServerAddress "1.0.0.1" `
    -DohTemplate "https://cloudflare-dns.com/dns-query" `
    -AllowFallbackToUdp $true -AutoUpgrade $true

参数说明：

AutoUpgrade = $true：Windows 会自动将发往该 IP 的 DNS 查询升级为 DoH 加密请求
AllowFallbackToUdp = $true：DoH 连接失败时回退到普通 UDP DNS，避免断网

验证配置

在线测试

访问 Cloudflare 的浏览器安全检测页面：https://www.cloudflare-cn.com/ssl/encrypted-sni/

点击 “检查我的浏览器” 按钮，期望结果：

项目	期望状态
安全的 DNS (DoH)	✅ 通过
DNSSEC	✅ 通过
TLS 1.3	✅ 通过
安全 SNI (ECH)	✅ 通过

也可以用这个网站测试ech和doh情况：https://doh-ech.zhoulirui.ggff.net/

命令行测试

1
2
3
4
5
6


# 验证 Edge DoH 和 ECH 策略
reg query "HKLM\SOFTWARE\Policies\Microsoft\Edge"

# 验证系统 DNS 配置
Get-DnsClientServerAddress -InterfaceIndex 13
Get-DnsClientDohServerAddress -ServerAddress "1.1.1.1"

排错指南

所有网站都打不开

可能是 DnsOverHttpsMode 设置为 secure 但 DoH 服务器不可达

解决：改回 automatic 模式

1

reg add "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v DnsOverHttpsMode /t REG_SZ /d "automatic" /f

DoH 测试未通过

DoH 服务器在当前网络不可达（如国内直连 Cloudflare）
解决：使用国内可达的 DoH 服务器，或者配置代理

ECH 测试未通过

ECH 不通过最常见的原因：

DoH 服务器不支持返回 HTTPS 类型 DNS 记录：ECH 密钥通过 DNS HTTPS 记录（TYPE65）分发，不是所有 DoH 服务器都会返回这种记录
目标网站不支持 ECH：ECH 需要服务端也支持。目前主要是 Cloudflare 托管的网站支持 ECH

ECH 策略未启用：确认注册表中 EncryptedClientHelloEnabled 值为 1

1

reg query "HKLM\SOFTWARE\Policies\Microsoft\Edge" /v EncryptedClientHelloEnabled

总结

通过配置 DoH + ECH，可以实现对部分被 SNI 阻断的网站的裸连访问（无需代理）。核心配置只有三步：

Edge DoH 策略：通过注册表设置 DoH 模式和 DoH 服务器地址
Edge ECH 策略：通过注册表设置 EncryptedClientHelloEnabled 启用 ECH
（可选）系统 DNS：在 Windows 系统层面启用 DNS 加密

需要注意的是，这种方案的效果取决于你的网络环境和 DoH 服务器的可达性。最关键的一环是找到一个在你的网络下可正常使用且支持 HTTPS DNS 记录的 DoH 服务器。

本文2026-03-16首发于猫猫鱼的小窝，最后修改于2026-03-16

通过读取微信进程内存提取公众号信息流广告视频下载地址

xxx@example.com (catcatyu) — Sun, 15 Mar 2026 17:31:00 +0800

通过读取微信进程内存提取公众号信息流广告视频下载地址

作者：catcatyu（xxx@example.com）

背景

在PC端微信的公众号列表中，经常会看到信息流广告视频，比如游戏广告。这些广告视频有时候挺有意思，想下载下来，但微信并没有提供下载按钮。比如看到这个广告视频的妹妹很好看🤪，那么应该怎么下载呢？本文以这个"三国冰河时代"游戏广告为例，介绍如何通过读取微信进程内存来提取广告视频的下载地址。

尝试一：寻找本地缓存文件（失败）

首先想到的思路是微信可能把视频缓存到了本地磁盘。微信PC端的数据目录一般在：

C:\Users\{用户名}\Documents\WeChat Files\{微信ID}\FileStorage\

Cache、Video、Image、Temp、Sns、MsgAttach ...

其中 Video 目录按月份分文件夹存放：

2024-04、2024-05、... 2025-08

但逐个检查后发现这些目录要么为空，要么只有聊天中收发的视频。公众号信息流广告的视频并不会被缓存到这里。

同样检查了 AppData 下的微信目录：

C:\Users\{用户名}\AppData\Roaming\Tencent\WeChat\
C:\Users\{用户名}\AppData\Roaming\Tencent\xwechat\

新版微信（xwechat）使用了 Chromium 内核（RadiumWMPF），有类似浏览器的缓存结构：

xwechat\radium\web\profiles\webview_{用户hash}\
xwechat\radium\web\profiles\multitab_{用户hash}\

里面有 Code Cache、IndexedDB、GPUCache 等 Chromium 标准缓存目录，但也没找到视频文件。

结论：公众号信息流广告视频是流式加载的，不会完整缓存到本地磁盘。

尝试二：通过开发者工具/远程调试（失败）

既然新版微信使用 Chromium 内核，理论上可以通过 --remote-debugging-port 参数连接 DevTools 来抓取网络请求。

查看微信进程的命令行参数：

1

Get-CimInstance Win32_Process -Filter "Name='WeChatAppEx.exe'" | Select-Object ProcessId, CommandLine

发现主进程的启动参数中并没有 --remote-debugging-port，说明远程调试未开启，这条路也走不通。

尝试三：进程内存扫描（成功）

既然视频是流式加载的，那视频的URL一定在微信进程的内存中。思路是：直接读取微信进程内存，搜索视频URL模式。

第一步：定位微信进程

1
2


Get-Process | Where-Object { $_.ProcessName -match 'wechat' } |
    Select-Object Id, ProcessName, Path

发现微信运行了多个 WeChatAppEx.exe 进程，这是典型的 Chromium 多进程架构：

进程类型	说明
主进程（无 –type 参数）	浏览器主进程，包含页面数据
–type=gpu-process	GPU渲染进程
–type=renderer	页面渲染进程
–type=utility –utility-sub-type=network	网络服务进程

我们要扫描的是主进程（没有 --type 参数的那个）。

第二步：编写内存扫描脚本

通过 PowerShell 调用 Windows API 来读取进程内存：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34


Add-Type -TypeDefinition @'
using System;
using System.Runtime.InteropServices;

public class MemoryReader {
    [DllImport("kernel32.dll")]
    public static extern IntPtr OpenProcess(
        int dwDesiredAccess, bool bInheritHandle, int dwProcessId);

    [DllImport("kernel32.dll")]
    public static extern bool ReadProcessMemory(
        IntPtr hProcess, IntPtr lpBaseAddress, byte[] lpBuffer,
        int dwSize, ref int lpNumberOfBytesRead);

    [DllImport("kernel32.dll")]
    public static extern int VirtualQueryEx(
        IntPtr hProcess, IntPtr lpAddress,
        out MEMORY_BASIC_INFORMATION lpBuffer, uint dwLength);

    [DllImport("kernel32.dll")]
    public static extern bool CloseHandle(IntPtr hObject);

    [StructLayout(LayoutKind.Sequential)]
    public struct MEMORY_BASIC_INFORMATION {
        public IntPtr BaseAddress;
        public IntPtr AllocationBase;
        public uint AllocationProtect;
        public IntPtr RegionSize;
        public uint State;
        public uint Protect;
        public uint Type;
    }
}
'@

核心逻辑是遍历进程的所有已提交内存区域（MEM_COMMIT = 0x1000），读取内容后用正则匹配视频URL：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46


$targetPid = 42172  # 微信主进程PID
$handle = [MemoryReader]::OpenProcess(0x0410, $false, $targetPid)
# 0x0410 = PROCESS_VM_READ | PROCESS_QUERY_INFORMATION

$address = [IntPtr]::Zero
$mbi = New-Object MemoryReader+MEMORY_BASIC_INFORMATION

while ([MemoryReader]::VirtualQueryEx(
    $handle, $address, [ref]$mbi,
    [uint32][Runtime.InteropServices.Marshal]::SizeOf($mbi)) -ne 0)
{
    # 只扫描已提交的、大小合理的内存区域
    if ($mbi.State -eq 0x1000 -and
        $mbi.RegionSize.ToInt64() -lt 10MB -and
        $mbi.RegionSize.ToInt64() -gt 0)
    {
        $buffer = New-Object byte[] ($mbi.RegionSize.ToInt64())
        $bytesRead = 0

        if ([MemoryReader]::ReadProcessMemory(
            $handle, $mbi.BaseAddress, $buffer,
            $buffer.Length, [ref]$bytesRead))
        {
            $text = [System.Text.Encoding]::UTF8.GetString($buffer)

            # 匹配广告视频URL模式
            $regex = 'https?://[^\x00\s"<>]{10,500}' +
                     '(?:\.mp4|mpvideo|finder.*video|wxv_|video\.qq|findermp)' +
                     '[^\x00\s"<>]{0,200}'
            $matches = [regex]::Matches($text, $regex)

            foreach ($m in $matches) {
                $url = $m.Value -replace '[\x00-\x1f]', ''
                if ($url.Length -gt 20) {
                    Write-Host $url
                }
            }
        }
    }

    $address = [IntPtr](
        $mbi.BaseAddress.ToInt64() + $mbi.RegionSize.ToInt64())
    if ($address.ToInt64() -lt 0) { break }
}

[MemoryReader]::CloseHandle($handle)

第三步：扫描结果

扫描了 2357 个内存区域，找到了 115 个视频URL，去重后主要是以下几个广告视频（来自 wxsmw.wxs.qq.com 域名）：

http://wxsmw.wxs.qq.com/.../ads_svp_video__0bc3qyabeaaacyapvlro4zurvbqeckdaaesa.f142000.mp4?dis_k=...&dis_t=1764683224&...
http://wxsmw.wxs.qq.com/.../ads_svp_video__0b53xabuuaad6aap6xr4u5ubtoaejk4agssa.f142000.mp4?dis_k=...&dis_t=1749005722&...
http://wxsmw.wxs.qq.com/.../ads_svp_video__0b53qiaowaaapmaabparcrubvaqe5obab22a.f142000.mp4?dis_k=...&dis_t=1746007401&...

URL的规律：

域名：wxsmw.wxs.qq.com 或 wxsnsdy.wxs.qq.com（腾讯视频CDN）
路径包含 ads_svp_video 标识这是广告视频
参数 dis_t 是时间戳，可以用来判断哪个是最近的广告
参数 dis_k 和 sha256 用于鉴权

第四步：确认目标视频

有多个广告视频URL，需要确认哪个是"三国冰河时代"。用同样的内存扫描方法，搜索中文关键词"三国"（注意要同时搜索 UTF-8 和 UTF-16LE 两种编码，因为 Windows 进程内存中两种编码都可能存在）：

1
2
3
4


# UTF-8 编码的"三国"
$searchUtf8 = [System.Text.Encoding]::UTF8.GetBytes('三国')
# UTF-16LE 编码的"三国"
$searchUtf16 = [System.Text.Encoding]::Unicode.GetBytes('三国')

在内存中确实找到了多处"三国冰河时代"的引用，包括：

公众号文章元数据："三国冰河时代挥师定山河活动解析"
搜索记录："query": "三国冰河时代"
视频播放记录：kVideoTracks...三国冰河时代 - 搜一搜，编码格式 h264 high

通过 dis_t 时间戳判断，最新的广告视频URL就是目标视频。

第五步：下载视频

直接用 curl 下载：

1

curl -o "三国冰河时代_广告视频.mp4" "http://wxsmw.wxs.qq.com/131/20210/snssvpdownload/SH/reserved/ads_svp_video__0bc3qyabeaaacyapvlro4zurvbqeckdaaesa.f142000.mp4?dis_k=...&dis_t=...&sha256=...&m=...&posid=..."

返回 HTTP 200，文件大小约 7MB，Content-Type: video/mp4，下载成功。

原理总结

微信公众号信息流
    ↓ 加载广告
腾讯CDN（wxsmw.wxs.qq.com）
    ↓ 流式传输视频
WeChatAppEx.exe 进程内存
    ↓ ReadProcessMemory
提取视频URL → curl下载

整个过程的关键点：

公众号信息流广告视频不缓存到本地磁盘，只在进程内存中存在
新版微信（xwechat）基于 Chromium 内核（RadiumWMPF），视频URL以明文形式保存在进程内存中
使用 Windows API OpenProcess + VirtualQueryEx + ReadProcessMemory 可以遍历读取目标进程的内存
广告视频URL的特征是域名为 wxsmw.wxs.qq.com，路径包含 ads_svp_video
URL中的鉴权参数（dis_k、sha256、m）有时效性，需要在有效期内下载

注意事项

需要以当前用户权限运行，不需要管理员权限（因为微信也是当前用户启动的）
视频URL中的鉴权token有时效性，过期后需要重新扫描
扫描过程中微信需要保持运行，且目标广告页面需要已加载过
此方法同样适用于提取微信中其他流式加载的媒体内容的URL

本文2026-03-15首发于猫猫鱼的小窝，最后修改于2026-03-15

Python DrissionPage 绕过Cloudflare验证下载图片

xxx@example.com (catcatyu) — Mon, 09 Mar 2026 15:00:00 +0800

Python DrissionPage 绕过Cloudflare验证下载图片

作者：catcatyu（xxx@example.com）

有些网站（如 linux.do）的图片资源受 Cloudflare 保护，直接用 requests 请求会被拦截。本文介绍如何用 DrissionPage 控制真实浏览器通过验证，提取 cookie 后用 urllib 批量下载图片。

思路

用 DrissionPage 启动 Chromium 浏览器访问目标页面
等待 Cloudflare “Just a moment” 验证页面自动通过
通过 CDP 协议提取浏览器中的 cookie
用提取到的 cookie 构造请求头，用 urllib 下载图片

关键代码

1. 配置浏览器选项

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


from DrissionPage import Chromium, ChromiumOptions

def build_browser_options(proxy_url: str | None) -> ChromiumOptions:
    options = ChromiumOptions()
    options.set_argument("--no-first-run")
    options.set_argument("--disable-features=Translate")
    if proxy_url:
        options.set_argument(f"--proxy-server={proxy_url}")
    options.auto_port()  # 自动分配调试端口，避免冲突
    return options

auto_port() 让每次启动使用不同端口，可以多实例并行。

2. 等待 Cloudflare 验证通过

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


import time

PAGE_WAIT_SECONDS = 20

def wait_for_page(tab) -> None:
    wait_rounds = max(1, PAGE_WAIT_SECONDS // 2)
    for _ in range(wait_rounds):
        time.sleep(2)
        try:
            title = (tab.title or "").strip()
            lowered = title.lower()
            # Cloudflare 验证页的标题包含这些关键词
            if title and "just a moment" not in lowered and "checking your browser" not in lowered:
                return
        except Exception:
            pass
    time.sleep(3)

原理很简单：Cloudflare 验证页的 </code> 通常是 “Just a moment…” 或 “Checking your browser…"，只要轮询到标题变成正常内容，就说明验证通过了。 <h3 id="3-通过-cdp-提取-cookie"> <a class="header-anchor" href="#3-%e9%80%9a%e8%bf%87-cdp-%e6%8f%90%e5%8f%96-cookie"></a> 3. 通过 CDP 提取 Cookie </h3>这是最核心的部分——用 Chrome DevTools Protocol 的 <code>Network.getAllCookies</code> 拿到浏览器里的所有 cookie： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-python" data-lang="python">def domain_matches(host: str, domain: str) -> bool: """判断 host 是否匹配 cookie 的 domain 字段""" normalized = domain.lstrip(".") return bool(normalized) and (host == normalized or host.endswith(f".{normalized}")) def extract_cookie_header(browser: Chromium, tab, host: str) -> str: cookies: list[dict] = [] # 方法1: 通过 CDP 协议获取所有 cookie（包括 HttpOnly 的） try: cookies.extend(tab.run_cdp("Network.getAllCookies").get("cookies", [])) except Exception: pass # 方法2: 通过 DrissionPage API 获取 try: cookies.extend(browser.cookies(all_info=True)) except Exception: pass # 去重，只保留目标域名的 cookie seen: set[tuple[str, str, str]] = set() host_cookies: list[dict] = [] for cookie in cookies: domain = cookie.get("domain", "") if not domain_matches(host, domain): continue key = (cookie.get("name", ""), domain, cookie.get("path", "/")) if key in seen: continue seen.add(key) host_cookies.append(cookie) # 拼接成 HTTP Cookie 头格式 return "; ".join( f"{cookie['name']}={cookie['value']}" for cookie in host_cookies if cookie.get("name") and cookie.get("value") is not None ) </code></pre></td></tr></table> </div> </div>两种方式互补取 cookie：CDP 的 <code>Network.getAllCookies</code> 能拿到 <code>HttpOnly</code> 标记的 cookie（Cloudflare 的 <code>cf_clearance</code> 就是 HttpOnly 的），DrissionPage 自带的 API 作为兜底。 <h3 id="4-收集会话信息完整流程"> <a class="header-anchor" href="#4-%e6%94%b6%e9%9b%86%e4%bc%9a%e8%af%9d%e4%bf%a1%e6%81%af%e5%ae%8c%e6%95%b4%e6%b5%81%e7%a8%8b"></a> 4. 收集会话信息（完整流程） </h3>把上面的步骤串起来，打开浏览器 → 等验证 → 轮询提取 cookie → 验证 cookie 有效性： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-python" data-lang="python">COOKIE_WAIT_SECONDS = 180 def collect_site_session( site_url: str, proxy_url: str | None, validation_url: str | None = None, ) -> tuple[str, str]: host = urllib.parse.urlparse(site_url).hostname or "" options = build_browser_options(proxy_url) browser = None try: browser = Chromium(options) tab = browser.latest_tab tab.get(site_url) wait_for_page(tab) deadline = time.time() + COOKIE_WAIT_SECONDS while time.time() < deadline: time.sleep(3) cookie_header = extract_cookie_header(browser, tab, host) if not cookie_header: continue # 从浏览器获取真实 User-Agent try: user_agent = tab.run_js("return navigator.userAgent") except Exception: user_agent = "Mozilla/5.0 ..." # 如果提供了验证 URL，先试下载一张图验证 cookie 是否可用 if validation_url: ok, reason = probe_session(opener, validation_url, cookie_header, user_agent, site_url) if ok: return cookie_header, user_agent continue return cookie_header, user_agent finally: if browser is not None: browser.quit() return "", "Mozilla/5.0 ..." </code></pre></td></tr></table> </div> </div>关键点： <ul> <li>设 180 秒超时，留足人工点击验证码的时间</li> <li>每 3 秒轮询一次 cookie，拿到后立即用 <code>probe_session</code> 试下载一张图片验证 cookie 是否有效</li> <li>用 <code>tab.run_js("return navigator.userAgent")</code> 获取浏览器真实 UA，保证后续请求的 UA 和获取 cookie 时一致</li> </ul> <h3 id="5-带-cookie-下载图片"> <a class="header-anchor" href="#5-%e5%b8%a6-cookie-%e4%b8%8b%e8%bd%bd%e5%9b%be%e7%89%87"></a> 5. 带 Cookie 下载图片 </h3><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-python" data-lang="python">import ssl import urllib.request def build_opener(proxy_url: str | None) -> urllib.request.OpenerDirector: ssl_context = ssl.create_default_context() ssl_context.check_hostname = False ssl_context.verify_mode = ssl.CERT_NONE # 跳过 SSL 验证 handlers = [urllib.request.HTTPSHandler(context=ssl_context)] if proxy_url: handlers.insert(0, urllib.request.ProxyHandler({ "http": proxy_url, "https": proxy_url, })) return urllib.request.build_opener(*handlers) def download_image(opener, url, output_path, cookie_header, user_agent) -> bool: request = urllib.request.Request(url) request.add_header("User-Agent", user_agent) request.add_header("Accept", "image/webp,image/apng,image/*,*/*;q=0.8") request.add_header("Referer", f"{urllib.parse.urlparse(url).scheme}://{urllib.parse.urlparse(url).netloc}/") request.add_header("Cookie", cookie_header) with opener.open(request, timeout=30) as response: data = response.read() content_type = response.headers.get("Content-Type", "") if not data or "text/html" in content_type.lower(): raise ValueError(f"下载失败, content-type={content_type!r}") output_path.write_bytes(data) return True </code></pre></td></tr></table> </div> </div>注意设置 <code>Referer</code> 头，有些 CDN 会校验来源。下载后检查 <code>Content-Type</code>，如果返回的是 HTML 而不是图片，说明 cookie 已失效或被拦截了。 <h2 id="安装依赖"> <a class="header-anchor" href="#%e5%ae%89%e8%a3%85%e4%be%9d%e8%b5%96"></a> 安装依赖 </h2><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">pip install DrissionPage </code></pre></td></tr></table> </div> </div>DrissionPage 会自动查找系统中已安装的 Chromium 内核浏览器（Chrome、Edge 等），无需额外安装 chromedriver。 <h2 id="总结"> <a class="header-anchor" href="#%e6%80%bb%e7%bb%93"></a> 总结 </h2>整个方案的核心就一句话：用真实浏览器过 Cloudflare 验证，通过 CDP 协议偷 cookie，再把 cookie 塞到 urllib 请求里下载资源。相比 undetected-chromedriver 等方案，DrissionPage 的优势是 API 简洁，且内置了 CDP 操作支持。 <hr>本文2026-03-09首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-03-09 </article> <article> <h1>0元领养专属"小龙虾"OpenClaw，2核16GB配置/无痛部署/开箱即用并配置内网穿透接入飞书</h1> xxx@example.com (catcatyu) — Mon, 09 Mar 2026 00:00:00 +0800 <h1>0元领养专属"小龙虾"OpenClaw，2核16GB配置/无痛部署/开箱即用并配置内网穿透接入飞书</h1>作者：catcatyu（xxx@example.com） 参考来源：<a href="https://linux.do/t/topic/1702573" target="_blank" rel="noopener noreferrer nofollow">https://linux.do/t/topic/1702573</a> <h2 id="1-打开-modelscope-官网登录账户"> <a class="header-anchor" href="#1-%e6%89%93%e5%bc%80-modelscope-%e5%ae%98%e7%bd%91%e7%99%bb%e5%bd%95%e8%b4%a6%e6%88%b7"></a> 1. 打开 ModelScope 官网，登录账户 </h2>官网地址：<a href="https://www.modelscope.cn/home" target="_blank" rel="noopener noreferrer nofollow">https://www.modelscope.cn/home</a> <h2 id="2-授权绑定阿里云账号完成实名认证"> <a class="header-anchor" href="#2-%e6%8e%88%e6%9d%83%e7%bb%91%e5%ae%9a%e9%98%bf%e9%87%8c%e4%ba%91%e8%b4%a6%e5%8f%b7%e5%ae%8c%e6%88%90%e5%ae%9e%e5%90%8d%e8%ae%a4%e8%af%81"></a> 2. 授权绑定阿里云账号，完成实名认证 </h2> <h2 id="3-获取-modelscope-访问令牌"> <a class="header-anchor" href="#3-%e8%8e%b7%e5%8f%96-modelscope-%e8%ae%bf%e9%97%ae%e4%bb%a4%e7%89%8c"></a> 3. 获取 ModelScope 访问令牌 </h2>回到 ModelScope 网站，点击右上角头像，选择"账号设置"，然后点击左侧的"访问控制"，最后点击"新建访问令牌"并复制此令牌。 <h2 id="4-搜索-openclaw-创空间"> <a class="header-anchor" href="#4-%e6%90%9c%e7%b4%a2-openclaw-%e5%88%9b%e7%a9%ba%e9%97%b4"></a> 4. 搜索 OpenClaw 创空间 </h2>在网站右上角搜索框输入 <code>BrianZhou/openclaw_computer</code>，按回车键确认，随后点击搜索结果中展示的创空间。 <h2 id="5-复制空间并设置参数"> <a class="header-anchor" href="#5-%e5%a4%8d%e5%88%b6%e7%a9%ba%e9%97%b4%e5%b9%b6%e8%ae%be%e7%bd%ae%e5%8f%82%e6%95%b0"></a> 5. 复制空间并设置参数 </h2>复制该空间，并设置相关参数： <ul> <li> 是否公开：选择"非公开" </li> <li> ROOT_PASSWD：你可以设置任意值，这是云电脑的密码，电脑待机锁屏时需要该密码解锁，请勿忘记 </li> <li> MODELSCOPE_API_KEY：粘贴你刚刚复制的令牌（即本教程第 3 步操作里复制的令牌） </li> </ul> 最后点击"复制创空间"。 <h2 id="6-等待云电脑部署完成"> <a class="header-anchor" href="#6-%e7%ad%89%e5%be%85%e4%ba%91%e7%94%b5%e8%84%91%e9%83%a8%e7%bd%b2%e5%ae%8c%e6%88%90"></a> 6. 等待云电脑部署完成 </h2> <h2 id="7-进入全屏模式部署完成"> <a class="header-anchor" href="#7-%e8%bf%9b%e5%85%a5%e5%85%a8%e5%b1%8f%e6%a8%a1%e5%bc%8f%e9%83%a8%e7%bd%b2%e5%ae%8c%e6%88%90"></a> 7. 进入全屏模式，部署完成 </h2>云电脑部署上线后，按照下图操作进入全屏模式。至此，部署完成。 <hr> 接下来需要注册内网穿透服务 <h2 id="8配置ssh服务"> <a class="header-anchor" href="#8%e9%85%8d%e7%bd%aessh%e6%9c%8d%e5%8a%a1"></a> 8.配置ssh服务 </h2> 在终端中输入以下命令开启ssh服务： <pre tabindex="0"><code>service ssh start </code></pre> 同样方法输入下列命令配置ssh自启动服务: <pre tabindex="0"><code>echo "service ssh start" >> /root/bz-startup/main.sh </code></pre><h2 id="选项一9使用ngrok进行穿透"> <a class="header-anchor" href="#%e9%80%89%e9%a1%b9%e4%b8%809%e4%bd%bf%e7%94%a8ngrok%e8%bf%9b%e8%a1%8c%e7%a9%bf%e9%80%8f"></a> （选项一）9.使用ngrok进行穿透 </h2>先去<a href="https://dashboard.ngrok.com/signup" target="_blank" rel="noopener noreferrer nofollow">ngrok - Online in One Line注册账户，使用github进行登录</a> 如果github上不去，可以使用watts tool进行加速： 如果没有github账号，可以注册一个 注册好后用github账号登录grok 会提示你启用2fa，如果你想启用，可以下一个微软的authencitator绑定，如不需要可以跳过 登录之后看到自己的token，把它复制下来 之后把token粘贴进剪切板，并让小龙虾帮你配置内网穿透 之后使用windterm进行连接 <h2 id="选项二9-使用-sakura-frp-进行穿透"> <a class="header-anchor" href="#%e9%80%89%e9%a1%b9%e4%ba%8c9-%e4%bd%bf%e7%94%a8-sakura-frp-%e8%bf%9b%e8%a1%8c%e7%a9%bf%e9%80%8f"></a> （选项二）9. 使用 Sakura Frp 进行穿透 </h2>先去 sakurafrp 官网 <a href="https://www.natfrp.com/user/" target="_blank" rel="noopener noreferrer nofollow">https://www.natfrp.com/user/</a> 注册用户： 再进行实名认证，需要1元。 认证成功之后，在云电脑中先在剪切板里面粘贴命令，之后打开终端粘贴后后回车， 输入： <pre tabindex="0"><code>wget https://cdn.jsdelivr.net/gh/fjh1997/CTF-@main/sakura_frp.sh && bash sakura_frp.sh </code></pre> 执行一段时间后会提示你输入密钥，先不动，如果卡住了，使用ctrl+c中断命令，然后按方向键上键重试即可： 之后复制访问密钥，在剪切板里面粘贴，之后再复制到终端里面： 复制完访问密钥之后，设置远程管理密码，可以看到安装成功的界面： 输入`bash /mnt/workspace/sakura_frp/<a href="http://start.sh" target="_blank" rel="noopener noreferrer nofollow">start.sh</a> `启动穿透。 以后设备重启后需要输入<code>bash /mnt/workspace/sakura_frp/start.sh</code>启动穿透。 之后点击服务-隧道列表： 随便选一个，可以选浙江移动 隧道类型选tcp 选22端口： 创建成功之后去远程管理页面： 如果没显示出来多按几下刷新，或者重启服务 输入连接密码并连接： 把创建好的隧道拖到加号上 成功后会显示连接信息： 也可以去日志里查看连接地址：之后使用windterm进行连接，使用用户名root和密码即可： <h2 id="10上传代码包让小龙虾自动审计"> <a class="header-anchor" href="#10%e4%b8%8a%e4%bc%a0%e4%bb%a3%e7%a0%81%e5%8c%85%e8%ae%a9%e5%b0%8f%e9%be%99%e8%99%be%e8%87%aa%e5%8a%a8%e5%ae%a1%e8%ae%a1"></a> 10.上传代码包让小龙虾自动审计 </h2> 之后上传你需要审计的代码包，如unserialize.zip,拖到左下角小框里： 之后你和openclaw说话他就会自动帮你审计： <h2 id="11接入飞书"> <a class="header-anchor" href="#11%e6%8e%a5%e5%85%a5%e9%a3%9e%e4%b9%a6"></a> 11.接入飞书 </h2>先和openclaw说: <pre tabindex="0"><code>帮我安装飞书插件npx -y @larksuite/openclaw-lark-tools install </code></pre> 等openclaw处理好之后在终端里面再次输入： <pre tabindex="0"><code>npx -y @larksuite/openclaw-lark-tools install </code></pre>之后下载飞书app扫码： 即可连接机器人 <hr>本文2026-03-09首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-03-09 </article> <article> <h1>Fenvi AX1800 MT7921AU 在monitor mode下监听不到beacon管理帧BUG修复</h1> xxx@example.com (catcatyu) — Sun, 08 Mar 2026 22:00:00 +0800 <h1>Fenvi AX1800 MT7921AU 在monitor mode下监听不到beacon管理帧BUG修复</h1>作者：catcatyu（xxx@example.com） <h2 id="起因"> <a class="header-anchor" href="#%e8%b5%b7%e5%9b%a0"></a> 起因 </h2>我有一个 Fenvi AX1800 USB 无线网卡（芯片 MediaTek MT7921AU，驱动 mt76），平时用来做无线安全研究。某天升级内核后发现，网卡在监控模式下抓不到管理帧了。 具体表现是：当无线网卡同时存在 managed 接口和 monitor 接口时（即并存模式），monitor 接口完全抓不到任何帧。而在内核 6.12 及以前，这一切都是正常的。 在 GitHub 上搜索发现已经有人报告了同样的问题：<a href="https://github.com/morrownr/USB-WiFi/issues/682" target="_blank" rel="noopener noreferrer nofollow">USB-WiFi#682</a> ，但一直没有修复。于是决定自己动手调试。 <h2 id="环境搭建"> <a class="header-anchor" href="#%e7%8e%af%e5%a2%83%e6%90%ad%e5%bb%ba"></a> 环境搭建 </h2>我的调试环境是： <ul> <li>宿主机：Windows + VMware Workstation</li> <li>虚拟机：Ubuntu 24.04 LTS（默认内核 6.8）</li> <li>无线网卡：Fenvi AX1800（MT7921AU），通过 USB 穿透到虚拟机</li> <li>内核版本：通过 Ubuntu Mainline Kernel 安装多个版本进行对比测试</li> </ul> 选择 Ubuntu 的原因是 <a href="https://kernel.ubuntu.com/mainline/" target="_blank" rel="noopener noreferrer nofollow">Ubuntu Mainline Kernel Archive</a> 提供了预编译的 <code>.deb</code> 内核包，可以非常方便地安装任意版本的内核来测试，不需要自己从头编译整个内核。 安装方法很简单，以 6.13 为例： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 6 7 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">cd /tmp wget https://kernel.ubuntu.com/mainline/v6.13/amd64/linux-headers-6.13.0-061300-generic_6.13.0-061300.202501192034_amd64.deb wget https://kernel.ubuntu.com/mainline/v6.13/amd64/linux-headers-6.13.0-061300_6.13.0-061300.202501192034_all.deb wget https://kernel.ubuntu.com/mainline/v6.13/amd64/linux-image-unsigned-6.13.0-061300-generic_6.13.0-061300.202501192034_amd64.deb wget https://kernel.ubuntu.com/mainline/v6.13/amd64/linux-modules-6.13.0-061300-generic_6.13.0-061300.202501192034_amd64.deb sudo dpkg -i *.deb sudo reboot </code></pre></td></tr></table> </div> </div><h2 id="基线测试确认-bug-存在"> <a class="header-anchor" href="#%e5%9f%ba%e7%ba%bf%e6%b5%8b%e8%af%95%e7%a1%ae%e8%ae%a4-bug-%e5%ad%98%e5%9c%a8"></a> 基线测试：确认 Bug 存在 </h2>先在默认的 6.8 内核上确认网卡功能正常。 <h3 id="测试方法"> <a class="header-anchor" href="#%e6%b5%8b%e8%af%95%e6%96%b9%e6%b3%95"></a> 测试方法 </h3>两种场景分别测试： 场景一：纯 Monitor 模式 <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">sudo ip link set wlx18d6c70a4715 down sudo iw dev wlx18d6c70a4715 set type monitor sudo ip link set wlx18d6c70a4715 up sudo timeout 5 tcpdump -i wlx18d6c70a4715 -c 50 'type mgt' -n </code></pre></td></tr></table> </div> </div>场景二：Managed + Monitor 并存 <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">sudo ip link set wlx18d6c70a4715 up # managed 模式 sudo iw dev wlx18d6c70a4715 interface add mon0 type monitor sudo ip link set mon0 up sudo timeout 5 tcpdump -i mon0 -c 50 'type mgt' -n </code></pre></td></tr></table> </div> </div><h3 id="68-基线结果"> <a class="header-anchor" href="#68-%e5%9f%ba%e7%ba%bf%e7%bb%93%e6%9e%9c"></a> 6.8 基线结果 </h3><table> <thead> <tr> <th>场景</th> <th>结果</th> </tr> </thead> <tbody> <tr> <td>纯 Monitor</td> <td>✅ 正常抓到管理帧</td> </tr> <tr> <td>Managed + Monitor</td> <td>✅ 正常抓到管理帧</td> </tr> </tbody> </table> 一切正常。然后切换到 6.13 内核。 <h3 id="613-测试结果"> <a class="header-anchor" href="#613-%e6%b5%8b%e8%af%95%e7%bb%93%e6%9e%9c"></a> 6.13 测试结果 </h3><table> <thead> <tr> <th>场景</th> <th>结果</th> </tr> </thead> <tbody> <tr> <td>纯 Monitor</td> <td>✅ 正常</td> </tr> <tr> <td>Managed + Monitor</td> <td>❌ 0 帧</td> </tr> </tbody> </table> Bug 确认。并存模式下完全抓不到帧。 <h2 id="定位根因"> <a class="header-anchor" href="#%e5%ae%9a%e4%bd%8d%e6%a0%b9%e5%9b%a0"></a> 定位根因 </h2><h3 id="快速编译策略"> <a class="header-anchor" href="#%e5%bf%ab%e9%80%9f%e7%bc%96%e8%af%91%e7%ad%96%e7%95%a5"></a> 快速编译策略 </h3>调试内核 bug 最头疼的就是编译时间。完整编译一个内核可能需要几十分钟甚至几个小时。但实际上我们只需要修改 <code>mac80211</code> 模块，所以可以只编译这一个模块： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 6 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">cd /root/kernel/linux-6.13 cp /boot/config-$(uname -r) .config make olddefconfig make modules_prepare cp /lib/modules/$(uname -r)/build/Module.symvers . make M=net/mac80211 modules # 只编译 mac80211，大约 30 秒 </code></pre></td></tr></table> </div> </div>然后热替换模块，不需要重启： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">sudo ip link set wlx18d6c70a4715 down sudo rmmod mt7921u mt7921_common mt792x_lib mt76_connac_lib mt76_usb mt76 mac80211 sudo insmod net/mac80211/mac80211.ko sudo modprobe mt7921u </code></pre></td></tr></table> </div> </div>这样每次修改代码到测试验证的周期只需要不到一分钟。 <h3 id="分析代码变更"> <a class="header-anchor" href="#%e5%88%86%e6%9e%90%e4%bb%a3%e7%a0%81%e5%8f%98%e6%9b%b4"></a> 分析代码变更 </h3>问题出在 <code>net/mac80211/tx.c</code> 的 <code>ieee80211_monitor_start_xmit()</code> 函数。这是监控模式下发送（注入）帧的入口。 通过 <code>git log</code> 追踪，找到了引入回归的 commit： <blockquote> <code>0a44dfc07074</code> (“wifi: mac80211: simplify non-chanctx drivers”) </blockquote> 这个 commit 在"简化"代码时，删除了一个关键的 fallback 路径。修改前的逻辑（简化表示）： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-c" data-lang="c">if (chanctx_conf) chandef = &chanctx_conf->def; else chandef = &local->_oper_chandef; // fallback </code></pre></td></tr></table> </div> </div>修改后： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 6 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-c" data-lang="c">if (chanctx_conf) chandef = &chanctx_conf->def; else if (local->emulate_chanctx) chandef = &local->hw.conf.chandef; else goto fail_rcu; // 直接失败！ </code></pre></td></tr></table> </div> </div>问题在于：对于使用"真正的"channel context 的驱动（如 mt76），当 monitor 接口和 managed 接口并存时，monitor 的虚拟接口（sdata）并不会被分配自己的 chanctx，即使系统中存在一个来自 managed 接口的活跃 chanctx。 之前的代码会 fallback 到 <code>local->_oper_chandef</code>，所以能正常工作。新代码直接 <code>goto fail_rcu</code>，静默丢弃了所有帧。 后来的 commit <code>d594cc6f2c58</code> (“wifi: mac80211: restore non-chanctx injection behaviour”) 修复了使用 <code>emulate_chanctx</code> 的驱动，但明确留下了真正 chanctx 驱动未修复。 <h3 id="修复方案"> <a class="header-anchor" href="#%e4%bf%ae%e5%a4%8d%e6%96%b9%e6%a1%88"></a> 修复方案 </h3>修复思路很直接：当 monitor 接口没有 chanctx 时，从 <code>local->chanctx_list</code> 中取第一个可用的 chanctx 作为 fallback。这个模式在 <code>ieee80211_hw_conf_chan()</code> 中已经被使用过了，是安全的。 <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-c" data-lang="c">if (chanctx_conf) { chandef = &chanctx_conf->def; } else if (local->emulate_chanctx) { chandef = &local->hw.conf.chandef; } else { /* * For real chanctx drivers (e.g. mt76), the monitor * interface may not have a chanctx assigned when running * concurrently with another interface. Fall back to any * active chanctx so that injection can still work on the * operating channel. */ struct ieee80211_chanctx *ctx; ctx = list_first_entry_or_null(&local->chanctx_list, struct ieee80211_chanctx, list); if (ctx) chandef = &ctx->conf.def; else goto fail_rcu; } </code></pre></td></tr></table> </div> </div><h2 id="跨版本验证"> <a class="header-anchor" href="#%e8%b7%a8%e7%89%88%e6%9c%ac%e9%aa%8c%e8%af%81"></a> 跨版本验证 </h2>仅修复一个版本是不够的。我需要确认这个补丁能修复所有受影响的版本。 <h3 id="源码级分析"> <a class="header-anchor" href="#%e6%ba%90%e7%a0%81%e7%ba%a7%e5%88%86%e6%9e%90"></a> 源码级分析 </h3>为了避免在每个版本上都走一遍完整的"安装内核→重启→编译→测试"流程，我先从 kernel.org 下载了各版本的 <code>tx.c</code> 源码进行对比分析： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"># 下载各版本的 tx.c 进行对比 for ver in 6.13 6.14 6.15 6.16 6.17 6.18 6.19; do curl -o tx_${ver}.c "https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/plain/net/mac80211/tx.c?h=v${ver}" done </code></pre></td></tr></table> </div> </div>分析发现： <ul> <li>6.13–6.18：没有 <code>emulate_chanctx</code> 分支，直接 <code>if/else goto fail_rcu</code></li> <li>6.19+：有 <code>emulate_chanctx</code> 分支（来自 <code>d594cc6f2c58</code>），但 else 仍然 <code>goto fail_rcu</code></li> </ul> 两种变体都需要同样的修复，只是上下文略有不同。我的补丁基于 6.19+ 的代码编写，通过 <code>Fixes:</code> 标签和 <code>Cc: stable@vger.kernel.org</code> 来触发自动回溯。 <h3 id="发现第二个-bug"> <a class="header-anchor" href="#%e5%8f%91%e7%8e%b0%e7%ac%ac%e4%ba%8c%e4%b8%aa-bug"></a> 发现第二个 Bug </h3>在 6.18 内核上测试时，发现了一个意外情况：即使是纯 Monitor 模式也抓不到帧。这跟 6.13 的表现不同（6.13 纯 Monitor 是正常的）。 经过排查，发现 6.17–6.18 的 mt76 驱动中多了一行： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-c" data-lang="c">// drivers/net/wireless/mediatek/mt76/mt792x_core.c ieee80211_hw_set(hw, NO_VIRTUAL_MONITOR); </code></pre></td></tr></table> </div> </div>这个标志告诉 mac80211 不要创建虚拟 monitor 接口，导致整个监控模式都不工作。这个标志在 6.19 中被 revert 了。 所以实际上有两个独立的 Bug： <pre class="mermaid"> graph TD A[6.12 及之前: 一切正常] --> B[6.13: tx.c chanctx fallback 被删除] B --> C[6.13-6.16: 纯 Monitor ✅ / 并存 ❌] B --> D[6.17-6.18: 额外添加 NO_VIRTUAL_MONITOR] D --> E[6.17-6.18: 纯 Monitor ❌ / 并存 ❌] D --> F[6.19: NO_VIRTUAL_MONITOR 被 revert] F --> G[6.19+: 纯 Monitor ✅ / 并存 ❌] </pre><h3 id="完整测试结果"> <a class="header-anchor" href="#%e5%ae%8c%e6%95%b4%e6%b5%8b%e8%af%95%e7%bb%93%e6%9e%9c"></a> 完整测试结果 </h3>在代表性版本上进行了实际测试： 补丁前： <table> <thead> <tr> <th>内核版本</th> <th>纯 Monitor</th> <th>Managed + Monitor</th> <th>原因</th> </tr> </thead> <tbody> <tr> <td>6.8</td> <td>✅ 正常</td> <td>✅ 正常</td> <td>基线</td> </tr> <tr> <td>6.13</td> <td>✅ 正常</td> <td>❌ 0 帧</td> <td>Bug 1</td> </tr> <tr> <td>6.17</td> <td>❌ 0 帧</td> <td>❌ 0 帧</td> <td>Bug 1 + Bug 2</td> </tr> <tr> <td>6.18</td> <td>❌ 0 帧</td> <td>❌ 0 帧</td> <td>Bug 1 + Bug 2</td> </tr> <tr> <td>6.19</td> <td>✅ 正常</td> <td>❌ 0 帧</td> <td>Bug 1</td> </tr> <tr> <td>7.0-rc2</td> <td>✅ 正常</td> <td>❌ 0 帧</td> <td>Bug 1</td> </tr> </tbody> </table> 补丁后（tx.c 修复）： <table> <thead> <tr> <th>内核版本</th> <th>纯 Monitor</th> <th>Managed + Monitor</th> </tr> </thead> <tbody> <tr> <td>6.13</td> <td>✅ 正常</td> <td>✅ ~37 帧/5秒</td> </tr> <tr> <td>6.19</td> <td>✅ 正常</td> <td>✅ ~39 帧/5秒</td> </tr> <tr> <td>7.0-rc2</td> <td>✅ 正常</td> <td>✅ ~33 帧/5秒</td> </tr> </tbody> </table> <h2 id="提交上游补丁"> <a class="header-anchor" href="#%e6%8f%90%e4%ba%a4%e4%b8%8a%e6%b8%b8%e8%a1%a5%e4%b8%81"></a> 提交上游补丁 </h2>确认修复有效后，按照 Linux 内核贡献流程提交补丁。 <h3 id="生成补丁"> <a class="header-anchor" href="#%e7%94%9f%e6%88%90%e8%a1%a5%e4%b8%81"></a> 生成补丁 </h3><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">cd /root/kernel/linux-7.0-rc2 # 编辑 net/mac80211/tx.c 应用修复 git add net/mac80211/tx.c git commit -s # Signed-off-by 是必须的 git format-patch -1 </code></pre></td></tr></table> </div> </div><h3 id="checkpatch-检查"> <a class="header-anchor" href="#checkpatch-%e6%a3%80%e6%9f%a5"></a> checkpatch 检查 </h3><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">./scripts/checkpatch.pl 0001-wifi-mac80211-fix-monitor-mode-frame-capture-for-rea.patch # total: 0 errors, 0 warnings, 41 lines checked </code></pre></td></tr></table> </div> </div><h3 id="获取维护者列表"> <a class="header-anchor" href="#%e8%8e%b7%e5%8f%96%e7%bb%b4%e6%8a%a4%e8%80%85%e5%88%97%e8%a1%a8"></a> 获取维护者列表 </h3><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">./scripts/get_maintainer.pl 0001-wifi-mac80211-fix-monitor-mode-frame-capture-for-rea.patch </code></pre></td></tr></table> </div> </div>输出的维护者和邮件列表就是你需要抄送的对象。 <h3 id="发送补丁"> <a class="header-anchor" href="#%e5%8f%91%e9%80%81%e8%a1%a5%e4%b8%81"></a> 发送补丁 </h3><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">git send-email \ --to=linux-wireless@vger.kernel.org \ --cc=johannes@sipsolutions.net \ --cc=stable@vger.kernel.org \ 0001-wifi-mac80211-fix-monitor-mode-frame-capture-for-rea.patch </code></pre></td></tr></table> </div> </div>补丁中的关键标签： <ul> <li><code>Fixes: 0a44dfc07074</code> — 指明修复哪个 commit 引入的 bug</li> <li><code>Cc: stable@vger.kernel.org</code> — 请求回溯到受影响的 stable 分支</li> </ul> 补丁已发送到邮件列表：<a href="https://lore.kernel.org/linux-wireless/20260308164510.5927-1-fjhhz1997@gmail.com/T/#u" target="_blank" rel="noopener noreferrer nofollow">lore.kernel.org 链接</a> <h2 id="调试过程中的坑"> <a class="header-anchor" href="#%e8%b0%83%e8%af%95%e8%bf%87%e7%a8%8b%e4%b8%ad%e7%9a%84%e5%9d%91"></a> 调试过程中的坑 </h2><h3 id="1-modulesymvers-缺失"> <a class="header-anchor" href="#1-modulesymvers-%e7%bc%ba%e5%a4%b1"></a> 1. Module.symvers 缺失 </h3>只编译单个模块时，如果不复制 <code>Module.symvers</code>，加载时会报 <code>undefined symbol</code> 错误： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">cp /lib/modules/$(uname -r)/build/Module.symvers . </code></pre></td></tr></table> </div> </div><h3 id="2-模块热替换的顺序"> <a class="header-anchor" href="#2-%e6%a8%a1%e5%9d%97%e7%83%ad%e6%9b%bf%e6%8d%a2%e7%9a%84%e9%a1%ba%e5%ba%8f"></a> 2. 模块热替换的顺序 </h3>卸载模块时要注意依赖关系，需要先卸载依赖 mac80211 的驱动模块： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 6 7 8 9 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"># 查看依赖关系 lsmod | grep mac80211 # mt7921u → mt7921_common → mt792x_lib → mt76_connac_lib → mt76 → mac80211 # 按依赖顺序卸载 sudo rmmod mt7921u mt7921_common mt792x_lib mt76_connac_lib mt76_usb mt76 mac80211 # 加载修改后的模块 sudo insmod net/mac80211/mac80211.ko sudo modprobe mt7921u # 自动加载整个 mt76 驱动链 </code></pre></td></tr></table> </div> </div><h3 id="3-脏模块状态"> <a class="header-anchor" href="#3-%e8%84%8f%e6%a8%a1%e5%9d%97%e7%8a%b6%e6%80%81"></a> 3. 脏模块状态 </h3>多次热替换模块后，偶尔会出现模块状态异常（表现为补丁明明应该生效但实际没效果）。遇到这种情况，做一次完整的卸载-重载循环即可： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">sudo rmmod mt7921u mt7921_common mt792x_lib mt76_connac_lib mt76_usb mt76 mac80211 cfg80211 sudo modprobe mac80211 # 加载原版 sudo rmmod mac80211 sudo insmod net/mac80211/mac80211.ko # 加载修改版 sudo modprobe mt7921u </code></pre></td></tr></table> </div> </div><h3 id="4-补丁的版本兼容性"> <a class="header-anchor" href="#4-%e8%a1%a5%e4%b8%81%e7%9a%84%e7%89%88%e6%9c%ac%e5%85%bc%e5%ae%b9%e6%80%a7"></a> 4. 补丁的版本兼容性 </h3>我的补丁是基于最新主线（7.0-rc2）编写的，其中包含 <code>emulate_chanctx</code> 分支。但 6.13–6.18 的内核没有这个分支，所以补丁不能直接 <code>git apply</code>。 不过这不影响上游提交——补丁只需要能在当前主线上 apply 即可。stable 团队在回溯时会自行处理冲突，或者我可以在需要时提供针对特定版本的 backport。 <h2 id="总结"> <a class="header-anchor" href="#%e6%80%bb%e7%bb%93"></a> 总结 </h2>这次调试的收获： <ol> <li>只编译单个模块是调试内核 bug 的高效方法，配合模块热替换可以做到分钟级的修改-测试循环</li> <li>看似一个 bug 实际可能是多个独立回归的叠加，需要跨版本源码对比才能理清</li> <li>Ubuntu Mainline Kernel 配合 VMware 快照是一个非常方便的多内核测试环境</li> <li>Linux 内核的补丁提交流程其实并不复杂：<code>git format-patch</code> → <code>checkpatch.pl</code> → <code>get_maintainer.pl</code> → <code>git send-email</code></li> </ol> <hr>本文2026-03-08首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-03-08 </article> <article> <h1>实现claude code抓包分析</h1> xxx@example.com (catcatyu) — Fri, 06 Mar 2026 19:40:35 +0800 <h1>实现claude code抓包分析</h1>作者：catcatyu（xxx@example.com） 需要设置环境变量 <pre tabindex="0"><code>$env:NODE_TLS_REJECT_UNAUTHORIZED = "0" $env:https_proxy = "http://127.0.0.1:8080" </code></pre>之后启动claude或者插件 Burp里面要设置流式抓包，不然抓到的SSE包不全。 <hr>本文2026-03-06首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-03-06 </article> <article> <h1>使用命令行安装 Microsoft C++ (MSVC) Build Tools</h1> xxx@example.com (catcatyu) — Mon, 02 Mar 2026 19:50:51 +0800 <h1>使用命令行安装 Microsoft C++ (MSVC) Build Tools</h1>作者：catcatyu（xxx@example.com） <pre tabindex="0"><code>winget install Microsoft.VisualStudio.2022.BuildTools </code></pre> <hr>本文2026-03-02首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-03-02 </article> <article> <h1>kernelsu next临时卸载功能开发记录</h1> xxx@example.com (catcatyu) — Mon, 02 Mar 2026 19:14:18 +0800 <h1>kernelsu next临时卸载功能开发记录</h1>作者：catcatyu（xxx@example.com） 基于kernelsu next 3.1.0做了一个支持lkm模式下临时卸载模块的功能。现在无需和少部分牛逼的root检测app斗智斗勇了（比如bochk用的promon shield方案），要用检测root的app的时候临时卸载就行。临时卸载会短暂黑屏，就检测不到了，欢迎参加测试。网上的一些root检测app可能还是能检测到异常，很正常，能过app即可。使用claude opus4.6开发，修复了pstore以记录内核和app崩溃日志，如果pstore无效可以使用<a href="https://csdn.fjh1997.top/posts/25235.html" target="_blank" rel="noopener noreferrer">高通自带方案</a> dump日志，开源地址：https://github.com/fjh1997/KernelSU-Next pstore修复方案如下：先找出自己设备地址的分配方案：查看adb shell cat /proc/iomem | head -n 20 (查看物理内存分布) 用<a href="https://github.com/ssut/payload-dumper-go" target="_blank" rel="noopener noreferrer nofollow">payload-dumper-go</a> 和<a href="https://github.com/cfig/Android_boot_image_editor" target="_blank" rel="noopener noreferrer nofollow">Android_boot_image_editor</a> 解包vendor_boot分区得到很多dts文件，找到芯片型号接近的几个 <code>.dts</code> 文件，找到 <code>ramoops_region</code>，把里面的参数根据物理内存分布直接改成下面这样，我是一加Ace3 Pro： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-dts" data-lang="dts"> ramoops_region { compatible = "ramoops"; /* 划重点：新基地址 0xffd80000，新总大小 0x280000 (2.5MB) */ reg = <0x00 0xffd80000 0x00 0x280000>; /* 内部的小 size 随便写或者不写都可以，反正 Bootloader 会强行覆盖它 */ record-size = <0x40000>; console-size = <0x40000>; pmsg-size = <0x200000>; mem-type = <0x02>; phandle = <0xXXX>; /* 再次提醒：务必保留每个文件原本的 phandle！ */ status = "okay"; }; </code></pre></td></tr></table> </div> </div>重新编译这 8 个文件，打包 <code>vendor_boot.img</code> 和对应的vbmeta一起刷入。开机后，直接用 <code>dmesg | grep ramoops</code>。 以下是claude opus4.6记录： <h1 id="kernelsu-next-代码修改总结"> <a class="header-anchor" href="#kernelsu-next-%e4%bb%a3%e7%a0%81%e4%bf%ae%e6%94%b9%e6%80%bb%e7%bb%93"></a> KernelSU-Next 代码修改总结 </h1><h2 id="一fjh1997-commit-a88b3885-审查结果"> <a class="header-anchor" href="#%e4%b8%80fjh1997-commit-a88b3885-%e5%ae%a1%e6%9f%a5%e7%bb%93%e6%9e%9c"></a> 一、fjh1997 commit <code>a88b3885</code> 审查结果 </h2>结论: 代码质量良好，无需删除任何内容。 <table> <thead> <tr> <th>文件</th> <th>改动</th> <th>评估</th> </tr> </thead> <tbody> <tr> <td><code>allowlist.c</code></td> <td><code>try_module_get</code>/<code>module_put</code> 保护 task_work</td> <td>✅ 正确，防止 rmmod 后 use-after-free</td> </tr> <tr> <td><code>app_profile.c</code></td> <td><code>root_groups</code> 从 static 改为 heap alloc</td> <td>✅ 正确，防止 rmmod 后悬空指针</td> </tr> <tr> <td><code>kernel_umount.c</code></td> <td>module ref 保护 umount task_work</td> <td>✅ 正确</td> </tr> <tr> <td><code>setuid_hook.c</code></td> <td>module ref 保护 install-fd task_work</td> <td>✅ 正确</td> </tr> <tr> <td><code>su_mount_ns.c</code></td> <td>module ref 保护 mount-ns task_work</td> <td>✅ 正确</td> </tr> <tr> <td><code>supercalls.c</code></td> <td><code>do_prepare_unload()</code> + mount_list cleanup</td> <td>✅ SIGKILL fd 持有者是合理的</td> </tr> <tr> <td><code>ksud.c</code></td> <td>mutex 保护 kprobe 注册状态，恢复 init.rc fops</td> <td>✅ 正确，防止 double-unregister</td> </tr> <tr> <td><code>pkg_observer.c</code></td> <td>故意泄漏 fsnotify group (~1KB)</td> <td>⚠️ 可接受的 tradeoff，避免竞态 crash</td> </tr> <tr> <td><code>throne_tracker.c</code></td> <td>APK path hash 清理</td> <td>✅ 正确</td> </tr> <tr> <td><code>syscall_hook_manager.c</code></td> <td>unmark_all 在 unregister 之前</td> <td>✅ 正确</td> </tr> <tr> <td><code>ksu.c</code></td> <td><code>ksu_cred</code> 故意泄漏 + rcu_barrier</td> <td>✅ 注释充分，避免 rcu 回调后 put_cred crash</td> </tr> </tbody> </table> <hr> <h2 id="二rmmod-清理代码修改内核层"> <a class="header-anchor" href="#%e4%ba%8crmmod-%e6%b8%85%e7%90%86%e4%bb%a3%e7%a0%81%e4%bf%ae%e6%94%b9%e5%86%85%e6%a0%b8%e5%b1%82"></a> 二、rmmod 清理代码修改（内核层） </h2><h3 id="执行顺序"> <a class="header-anchor" href="#%e6%89%a7%e8%a1%8c%e9%a1%ba%e5%ba%8f"></a> 执行顺序 </h3><pre tabindex="0"><code>kernelsu_exit() ├─ ksu_umount_all() ← 新增：卸载所有模块 overlay (需要 ksu_cred) ├─ revert_kernelsu_rules() ← 新增：恢复 SELinux policy ├─ flush_workqueue() ├─ kobject_add() restore ├─ ksu_allowlist_exit() ├─ ksu_throne_tracker_exit() ├─ ksu_observer_exit() ├─ ksu_ksud_exit() ├─ ksu_syscall_hook_manager_exit() ├─ ksu_supercalls_exit() ├─ ksu_feature_exit() ├─ ksu_cred = NULL ├─ rcu_barrier() └─ flush_workqueue() </code></pre> <blockquote class="alert-blockquote important"> Important <code>ksu_umount_all()</code> 必须在 <code>ksu_cred = NULL</code> 之前调用，因为它需要 <code>override_creds(ksu_cred)</code> 获取权限来执行 umount。 </blockquote> <hr> <h2 id="三用户态深度清理防御-zygisk-痕迹"> <a class="header-anchor" href="#%e4%b8%89%e7%94%a8%e6%88%b7%e6%80%81%e6%b7%b1%e5%ba%a6%e6%b8%85%e7%90%86%e9%98%b2%e5%be%a1-zygisk-%e7%97%95%e8%bf%b9"></a> 三、用户态深度清理（防御 Zygisk 痕迹） </h2>背景：高级模块通过手动 shell 脚本执行 <code>mount --bind</code>，不经过 KernelSU 核心框架，因此内核级的 <code>ksu_umount_all()</code> 无法清理它们。模块开发者往往使用匿名 <code>tmpfs</code> 伪装，所以我们需要精准定位目标。 修改文件： render_diffs(file:///G:/下载/KernelSU-Next-dev/manager/app/src/main/java/com/rifsxd/ksunext/ui/screen/Settings.kt) 清理方案，注重极致安全性 (绝对无系统损坏风险)：在 Manager App 的“临时卸载”逻辑触发 rmmod 之前，通过 root shell 执行： <ol> <li>强制清理 Zygisk 文件：手动 <code>umount -l /system/bin/app_process32</code> 和 <code>app_process64</code>，剥离 Zygisk 劫持。（注：OS 级别 <code>app_process</code> 仅仅是一个文件，在原版镜像中绝不是独立挂载点。如果发生卸载报错会静默跳过，百分百安全）。</li> <li>杀死残留进程：执行 <code>killall -9 zygiskd</code>，确保由于 fd 继承没被杀干净的 Zygisk 守护进程死亡。</li> </ol> <blockquote class="alert-blockquote caution"> Caution 基于用户要求的“系统维稳”策略，我们已经移除了对 <code>/data/resource-cache</code>、<code>/system/etc/security/cacerts</code> 与 <code>/apex/.../cacerts</code> 的一切卸载操作。因为这些路径在原生安卓中就属于系统基础组件甚至是底层 <code>tmpfs</code> 的构成部分。不盲目执行 umount 能极大地降低由于 APEX 冲突及第三方框架耦合导致的断网或系统崩溃风险，我们将稳定性放在了最优先级。 </blockquote> <h1 id="kernelsu-next-rmmod-清理代码修改"> <a class="header-anchor" href="#kernelsu-next-rmmod-%e6%b8%85%e7%90%86%e4%bb%a3%e7%a0%81%e4%bf%ae%e6%94%b9"></a> KernelSU-Next rmmod 清理代码修改 </h1><h2 id="问题"> <a class="header-anchor" href="#%e9%97%ae%e9%a2%98"></a> 问题 </h2><code>rmmod</code> 只卸载了内核模块代码，但留下 3 类残留物被 BOCHK 检测到： <ol> <li>SELinux policydb 中的 <code>su</code> 域和规则</li> <li>模块创建的 overlay 挂载</li> <li><code>ksu_cred</code> 泄漏</li> </ol> <h2 id="proposed-changes"> <a class="header-anchor" href="#proposed-changes"></a> Proposed Changes </h2><hr> <h3 id="1-selinux-policy-恢复"> <a class="header-anchor" href="#1-selinux-policy-%e6%81%a2%e5%a4%8d"></a> 1. SELinux Policy 恢复 </h3><h4 id="modify-rulesc"> <a class="header-anchor" href="#modify-rulesc"></a> [MODIFY] <a href="file:///G:/%e4%b8%8b%e8%bd%bd/KernelSU-Next-dev/kernel/selinux/rules.c">rules.c</a> </h4>添加 <code>revert_kernelsu_rules()</code> 函数： <ul> <li>将 <code>su</code> 域从 permissive 改回 enforcing</li> <li>清除 <code>su</code> 域的 所有 avtab allow 规则（遍历 <code>te_avtab</code>，删除 source_type == su 的节点）</li> <li>重置 AVC 缓存使改动生效</li> </ul> <blockquote class="alert-blockquote warning"> Warning 完全从 policydb 中删除 <code>su</code> type 是不安全的（会导致 type_val_to_struct 下标错乱）。采用的策略是：将 su 域设为 enforcing + 清除所有 allow 规则，让 <code>su</code> 域变成一个无权限的死域。这对检测工具来说，和不存在效果相同。 </blockquote> <h4 id="modify-selinuxh"> <a class="header-anchor" href="#modify-selinuxh"></a> [MODIFY] <a href="file:///G:/%e4%b8%8b%e8%bd%bd/KernelSU-Next-dev/kernel/selinux/selinux.h">selinux.h</a> </h4>声明 <code>revert_kernelsu_rules()</code> 函数。 <hr> <h3 id="2-全局-overlay-挂载清理"> <a class="header-anchor" href="#2-%e5%85%a8%e5%b1%80-overlay-%e6%8c%82%e8%bd%bd%e6%b8%85%e7%90%86"></a> 2. 全局 Overlay 挂载清理 </h3><h4 id="modify-kernel_"> <a class="header-anchor" href="#modify-kernel_"></a> [MODIFY] <a href="file:///G:/%e4%b8%8b%e8%bd%bd/KernelSU-Next-dev/kernel/kernel_umount.c">kernel_umount.c</a> </h4>添加 <code>ksu_umount_all()</code> 函数： <ul> <li>遍历 <code>mount_list</code> 中的所有挂载点</li> <li>用 <code>init</code> 的 cred + mount namespace 执行 <code>path_umount()</code></li> <li>设置 <code>ksu_module_mounted = false</code></li> </ul> <h4 id="modify-kernel_-1"> <a class="header-anchor" href="#modify-kernel_-1"></a> [MODIFY] <a href="file:///G:/%e4%b8%8b%e8%bd%bd/KernelSU-Next-dev/kernel/kernel_umount.h">kernel_umount.h</a> </h4>声明 <code>ksu_umount_all()</code> 函数。 <hr> <h3 id="3-主退出函数集成"> <a class="header-anchor" href="#3-%e4%b8%bb%e9%80%80%e5%87%ba%e5%87%bd%e6%95%b0%e9%9b%86%e6%88%90"></a> 3. 主退出函数集成 </h3><h4 id="modify-ksuc"> <a class="header-anchor" href="#modify-ksuc"></a> [MODIFY] <a href="file:///G:/%e4%b8%8b%e8%bd%bd/KernelSU-Next-dev/kernel/ksu.c">ksu.c</a> </h4>在 <code>kernelsu_exit()</code> 的 最前面 添加： <ol> <li><code>ksu_umount_all()</code> — 先卸载所有挂载</li> <li><code>revert_kernelsu_rules()</code> — 再恢复 SELinux</li> </ol> <hr> <h2 id="verification-plan"> <a class="header-anchor" href="#verification-plan"></a> Verification Plan </h2> <blockquote class="alert-blockquote important"> Important 这是内核模块代码，无法用常规 unit test。需要在 Android 设备上实际验证。 </blockquote> <h3 id="manual-verification"> <a class="header-anchor" href="#manual-verification"></a> Manual Verification </h3><ol> <li>编译并加载修改后的 KSU 模块</li> <li>安装 BOCHK 并确认检测到 root (<code>reason=22</code>)</li> <li>执行 <code>rmmod kernelsu</code></li> <li>验证 SELinux: <ul> <li><code>adb shell cat /sys/fs/selinux/enforce</code> → 应为 <code>1</code></li> <li><code>adb shell sesearch --allow -s su</code> → 应无结果或极少</li> </ul> </li> <li>验证挂载: <ul> <li><code>adb shell cat /proc/self/mountinfo | grep -i overlay</code> → 应无 KSU overlay</li> </ul> </li> <li>重新打开 BOCHK → 验证 <code>reason</code> 码是否降低或消失</li> </ol> <h1 id="kernelsu-next-临时卸载-vs-bochk-root检测--为什么仍被检测"> <a class="header-anchor" href="#kernelsu-next-%e4%b8%b4%e6%97%b6%e5%8d%b8%e8%bd%bd-vs-bochk-root%e6%a3%80%e6%b5%8b--%e4%b8%ba%e4%bb%80%e4%b9%88%e4%bb%8d%e8%a2%ab%e6%a3%80%e6%b5%8b"></a> KernelSU-Next 临时卸载 vs BOCHK Root检测 — 为什么仍被检测 </h1><h2 id="kernelsu-next-的隐藏机制"> <a class="header-anchor" href="#kernelsu-next-%e7%9a%84%e9%9a%90%e8%97%8f%e6%9c%ba%e5%88%b6"></a> KernelSU-Next 的隐藏机制 </h2>KernelSU-Next 有三个核心隐藏功能： <h3 id="1-kernel_umount--模块挂载卸载"> <a class="header-anchor" href="#1-kernel_umount--%e6%a8%a1%e5%9d%97%e6%8c%82%e8%bd%bd%e5%8d%b8%e8%bd%bd"></a> 1. <code>KERNEL_UMOUNT</code> — 模块挂载卸载 </h3>文件: <a href="file:///G:/%e4%b8%8b%e8%bd%bd/KernelSU-Next-dev/kernel/kernel_umount.c">kernel_umount.c</a> <pre tabindex="0"><code>触发链: zygote fork → setresuid() → ksu_handle_setresuid() → ksu_handle_umount() → 检查 UID 是否在 deny list → task_work 调度 → umount_tw_func() → 遍历 mount_list → try_umount() 每个条目 </code></pre>只卸载: KSU 模块添加的 overlay 挂载点（如 Zygisk 模块注入的 /system 覆盖） <h3 id="2-avc_spoof--selinux-审计欺骗"> <a class="header-anchor" href="#2-avc_spoof--selinux-%e5%ae%a1%e8%ae%a1%e6%ac%ba%e9%aa%97"></a> 2. <code>AVC_SPOOF</code> — SELinux 审计欺骗 </h3>文件: <a href="file:///G:/%e4%b8%8b%e8%bd%bd/KernelSU-Next-dev/kernel/extras.c">extras.c</a> <pre tabindex="0"><code>kprobe hook slow_avc_audit(): 当 tsid == su_sid 时 → 替换为 priv_app_sid → 隐藏 SELinux 对 su 域的 denied 审计日志 </code></pre>只隐藏: SELinux <code>avc: denied</code> 日志中的 <code>su</code> context，不隐藏实际的 SELinux policy 修改 <h3 id="3-su_compat--su-二进制兼容"> <a class="header-anchor" href="#3-su_compat--su-%e4%ba%8c%e8%bf%9b%e5%88%b6%e5%85%bc%e5%ae%b9"></a> 3. <code>SU_COMPAT</code> — su 二进制兼容 </h3>文件: <a href="file:///G:/%e4%b8%8b%e8%bd%bd/KernelSU-Next-dev/kernel/sucompat.c">sucompat.c</a> KernelSU 没有落地 su 二进制文件，通过内核 hook 直接处理 su 请求 <hr> <h2 id="bochk-检测-vs-kernelsu-next-隐藏--逐项对照"> <a class="header-anchor" href="#bochk-%e6%a3%80%e6%b5%8b-vs-kernelsu-next-%e9%9a%90%e8%97%8f--%e9%80%90%e9%a1%b9%e5%af%b9%e7%85%a7"></a> BOCHK 检测 vs KernelSU-Next 隐藏 — 逐项对照 </h2><table> <thead> <tr> <th>BOCHK 检测方法</th> <th>KSU 是否隐藏</th> <th>原因</th> </tr> </thead> <tbody> <tr> <td>RootBeer <code>checkSuExists()</code></td> <td>❌ 未隐藏</td> <td>Runtime.exec(“which su”) — KSU 不落地su文件，但某些模块可能会</td> </tr> <tr> <td>RootBeer <code>checkForRWPaths()</code></td> <td>❌ 未隐藏</td> <td>读 <code>/proc/mounts</code> 检查系统分区 rw → KSU 的 overlay mount 可能暴露 rw 挂载</td> </tr> <tr> <td>RootBeer <code>checkForRootNative()</code></td> <td>❌ 未隐藏</td> <td>Native JNI 检测 → 扫描 <code>/system/xbin/su</code> 等路径</td> </tr> <tr> <td>RootBeer <code>detectRootManagementApps()</code></td> <td>❌ 未隐藏</td> <td>检查已安装App包名 (Magisk/KSU Manager) → KSU Manager 依然存在</td> </tr> <tr> <td>RootBeer <code>detectRootCloakingApps()</code></td> <td>❌ 未隐藏</td> <td>检查 Shamiko/RootCloak 等包名</td> </tr> <tr> <td>Promon <code>/mountinfo</code> 扫描</td> <td>⚠️ 部分</td> <td>KSU umount 只移除模块挂载，但内核本身的修改痕迹仍在 mountinfo</td> </tr> <tr> <td>Promon SVC <code>openat(/proc/self/maps)</code></td> <td>❌ 完全无效</td> <td>直接 SVC 系统调用，不经过任何可 hook 的层</td> </tr> <tr> <td>Promon GOT 验证</td> <td>❌ 完全无效</td> <td>检查 libc GOT 表完整性 — KSU 的 syscall hook 不修改 GOT</td> </tr> <tr> <td>Promon Frida线程检测</td> <td>❌ 不相关</td> <td>这是检测 Frida，不是 root</td> </tr> <tr> <td>Promon 设备完整性</td> <td>❌ 未隐藏</td> <td>Play Integrity API → bootloader unlocked / custom kernel</td> </tr> </tbody> </table> <hr> <h2 id="reason22-你的设备-具体泄露点"> <a class="header-anchor" href="#reason22-%e4%bd%a0%e7%9a%84%e8%ae%be%e5%a4%87-%e5%85%b7%e4%bd%93%e6%b3%84%e9%9c%b2%e7%82%b9"></a> <code>reason=22</code> (你的设备) 具体泄露点 </h2><code>reason=22</code> = 二进制 <code>10110</code>: <ul> <li>bit4 = 1: <code>checkSuExists()</code> — 最可能的泄露</li> <li>bit2 = 1: <code>checkForRWPaths()</code> — 模块 overlay mount 泄露</li> <li>bit1 = 1: <code>checkForRootNative()</code> — native 层泄露</li> </ul> <h3 id="bit4-checksuexists-触发原因"> <a class="header-anchor" href="#bit4-checksuexists-%e8%a7%a6%e5%8f%91%e5%8e%9f%e5%9b%a0"></a> bit4: <code>checkSuExists()</code> 触发原因 </h3><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-java" data-lang="java">// RootBeer 实现 public boolean checkSuExists() { Process process = Runtime.getRuntime().exec(new String[]{"which", "su"}); // 读取 stdout，如果返回路径则 detected } </code></pre></td></tr></table> </div> </div>KernelSU-Next 不落地 su 文件，但： <ul> <li>如果安装了 KSU 模块（如 Zygisk-Next），可能会在 <code>/system/bin</code> overlay 中注入 su wrapper</li> <li><code>KERNEL_UMOUNT</code> 只在 deny list 中的 App （如 BOCHK）启动时卸载 overlay</li> <li>但 <code>checkSuExists()</code> 用 <code>Runtime.exec("which su")</code> 在全局 PATH 中搜索</li> <li>KSU 的 <code>sucompat.c</code> hook 了 <code>faccessat</code> syscall 来处理 su — 这个 hook 仍在内核中活跃</li> </ul> <h3 id="bit2-checkforrwpaths-触发原因"> <a class="header-anchor" href="#bit2-checkforrwpaths-%e8%a7%a6%e5%8f%91%e5%8e%9f%e5%9b%a0"></a> bit2: <code>checkForRWPaths()</code> 触发原因 </h3><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-java" data-lang="java">// RootBeer 实现 private static String[] pathsThatShouldNotBeWritable = { "/system", "/system/bin", "/system/sbin", "/system/xbin", "/vendor/bin", "/sbin", "/etc" }; </code></pre></td></tr></table> </div> </div>KernelSU 模块通过 <code>magic mount</code> (overlay) 修改 <code>/system</code>，这些 overlay 在 <code>kernel_umount.c</code> 的 <code>mount_list</code> 中： <ul> <li>如果 BOCHK 不在 deny list → overlay mount 完全可见</li> <li>即使在 deny list 中，umount 是异步的 (<code>task_work</code>)，可能存在竞态条件</li> </ul> <h3 id="bit1-checkforrootnative-触发原因"> <a class="header-anchor" href="#bit1-checkforrootnative-%e8%a7%a6%e5%8f%91%e5%8e%9f%e5%9b%a0"></a> bit1: <code>checkForRootNative()</code> 触发原因 </h3>RootBeer 的 native 检测通过 JNI 调用 <code>libtool-checker.so</code>： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 6 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-c" data-lang="c">// Native root detection int checkForRoot() { // 检测 su, busybox 等二进制文件的存在 // 检测 /system/app/Superuser.apk 等 // 检测 selinux enforcing 状态 } </code></pre></td></tr></table> </div> </div>KernelSU-Next 修改了 SELinux policy（通过 <code>sepolicy.c</code>），这些修改在内核 policydb 中持久存在，native 代码可以检测到新增的 policy rules。 <hr> <h2 id="根本原因分析"> <a class="header-anchor" href="#%e6%a0%b9%e6%9c%ac%e5%8e%9f%e5%9b%a0%e5%88%86%e6%9e%90"></a> 根本原因分析 </h2><pre class="mermaid"> graph TD A["KernelSU-Next 临时卸载"] --> B["kernel_umount.c 只卸载 module overlay mounts"] A --> C["extras.c 只 spoof SELinux audit log"] D["BOCHK Java层检测"] --> E["RootBeer 10项检测 走 Java/JNI 标准 API"] D --> F["PackageManager 检查 KSU Manager 包名"] G["BOCHK Native层检测"] --> H["Promon SVC #0 直接系统调用 → 内核 绕过所有 userspace"] B -.->|"部分有效"| E B -.->|"无效"| H C -.->|"无效"| E style H fill:#f44,color:#fff style B fill:#ffa,color:#000 style C fill:#ffa,color:#000 </pre>核心问题: KernelSU-Next 的隐藏机制工作在 mount namespace 层面，只处理文件系统覆盖。但 BOCHK 的检测工作在多个层面： <ol> <li>Java 层: <code>Runtime.exec("which su")</code>, <code>PackageManager.getInstalledApplications()</code> — KSU umount 无法隐藏非文件系统的痕迹</li> <li>Native JNI 层: <code>libtool-checker.so</code> 直接检测 — 不经过 KSU 的任何 hook</li> <li>Promon SVC 层: 直接 <code>SVC #0</code> 读取 <code>/proc/self/maps</code> 和 <code>/proc/self/mountinfo</code> — 完全绕过所有 userspace hook，包括 KSU 的 syscall table hook</li> </ol> <hr> <h2 id="具体泄露清单"> <a class="header-anchor" href="#%e5%85%b7%e4%bd%93%e6%b3%84%e9%9c%b2%e6%b8%85%e5%8d%95"></a> 具体泄露清单 </h2><table> <thead> <tr> <th>#</th> <th>泄露类型</th> <th>检测方</th> <th>KSU 组件</th> <th>状态</th> </tr> </thead> <tbody> <tr> <td>1</td> <td>KSU Manager App 包名</td> <td>RootBeer <code>detectRootManagementApps</code></td> <td>无隐藏</td> <td>⚠️ 需要在 deny list 中隐藏</td> </tr> <tr> <td>2</td> <td><code>/system</code> overlay mount</td> <td>RootBeer <code>checkForRWPaths</code></td> <td><code>kernel_umount.c</code></td> <td>⚠️ 仅对 deny list UID 有效</td> </tr> <tr> <td>3</td> <td>su 相关文件路径</td> <td>RootBeer <code>checkSuExists</code></td> <td><code>sucompat.c</code> hook</td> <td>⚠️ hook 在内核仍活跃</td> </tr> <tr> <td>4</td> <td>SELinux policy 修改</td> <td>RootBeer native</td> <td><code>sepolicy.c</code></td> <td>❌ 无法隐藏内核 policydb</td> </tr> <tr> <td>5</td> <td>Bootloader 解锁状态</td> <td>Promon 设备完整性</td> <td>无</td> <td>❌ 硬件层面无法隐藏</td> </tr> <tr> <td>6</td> <td><code>/proc/self/mountinfo</code></td> <td>Promon SVC 直读</td> <td>无</td> <td>❌ SVC 绕过所有 userspace</td> </tr> <tr> <td>7</td> <td>内核模块痕迹</td> <td>Promon <code>/proc/modules</code></td> <td>无</td> <td>❌ KSU 以模块加载时可见</td> </tr> <tr> <td>8</td> <td><code>ro.debuggable</code>/build props</td> <td>Promon 模拟器检测</td> <td>无</td> <td>⚠️ 取决于 ROM</td> </tr> </tbody> </table> <h2 id="建议"> <a class="header-anchor" href="#%e5%bb%ba%e8%ae%ae"></a> 建议 </h2>要绕过 BOCHK 的检测，需要在多个层面同时隐藏： <ol> <li>确保 BOCHK 在 deny list 中 — 否则 <code>kernel_umount</code> 完全不工作</li> <li>隐藏 KSU Manager — 改包名或从已安装列表中隐藏</li> <li>处理 Promon SVC 检测 — 需要在内核层面 hook <code>sys_openat</code> 返回假的 maps/mountinfo 给特定进程</li> <li>隐藏 SELinux policy — <code>extras.c</code> 的 <code>avc_spoof</code> 只隐藏 audit 日志，不隐藏 policy 本身</li> <li>处理 Play Integrity — bootloader 解锁 → 需要 Play Integrity Fix 模块</li> </ol> <hr>本文2026-03-02首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-03-02 </article> <article> <h1>使用claude code分析bochk 中银香港app防护机制</h1> xxx@example.com (catcatyu) — Mon, 02 Mar 2026 19:04:14 +0800 <h1>使用claude code分析bochk 中银香港app防护机制</h1>作者：catcatyu（xxx@example.com） <h1 id="分析方法"> <a class="header-anchor" href="#%e5%88%86%e6%9e%90%e6%96%b9%e6%b3%95"></a> 分析方法： </h1>让claude code opus 4.6写frida dump脚本dump出libbochk_aos.so，之后结合<a href="https://github.com/KiFilterFiberContext/promon-reversal" target="_blank" rel="noopener noreferrer nofollow">开源脱壳工具</a> 用jadx反编译 还使用了MCP工具：<a href="https://github.com/mrexodia/ida-pro-mcp" target="_blank" rel="noopener noreferrer nofollow">ida-pro-mcp</a> 和<a href="https://github.com/mrexodia/ida-pro-mcp" target="_blank" rel="noopener noreferrer nofollow">jadx-ai-mcp</a> 仅供安全研究学习使用，不得他用。 <h1 id="bochk-app-root--hooking-detection-完整分析报告"> <a class="header-anchor" href="#bochk-app-root--hooking-detection-%e5%ae%8c%e6%95%b4%e5%88%86%e6%9e%90%e6%8a%a5%e5%91%8a"></a> BOCHK App Root & Hooking Detection 完整分析报告 </h1><h2 id="安全警告-url-参数解码"> <a class="header-anchor" href="#%e5%ae%89%e5%85%a8%e8%ad%a6%e5%91%8a-url-%e5%8f%82%e6%95%b0%e8%a7%a3%e7%a0%81"></a> 安全警告 URL 参数解码 </h2><pre tabindex="0"><code>https://www.bochk.com/dam/securitywarning.html ?reason=22 &manufacturer=OnePlus&model=PJX110&android=36 &version=6.6.1 &hookingframeworks=F4 &return=4 &srcApp=bochk </code></pre><table> <thead> <tr> <th>参数</th> <th>值</th> <th>含义</th> </tr> </thead> <tbody> <tr> <td><code>reason</code></td> <td>22</td> <td>Root检测错误码（<code>BOCLFRootUtils.getRootErrorCode()</code> 生成的10位二进制转十进制）</td> </tr> <tr> <td><code>hookingframeworks</code></td> <td>F4</td> <td>Promon Shield native 层检测到的 hooking framework 位掩码</td> </tr> <tr> <td><code>return</code></td> <td>4</td> <td>返回行为码：打开浏览器显示安全警告</td> </tr> <tr> <td><code>reason=50</code></td> <td>(另一个URL)</td> <td>恶意软件检测（<code>MainActivity.a(C0566h)</code> 触发）</td> </tr> </tbody> </table> <hr> <h2 id="检测架构"> <a class="header-anchor" href="#%e6%a3%80%e6%b5%8b%e6%9e%b6%e6%9e%84"></a> 检测架构 </h2><pre class="mermaid"> graph TD A["App启动"] --> B["jtqupujl.aP.attachBaseContext() (extends Application)"] B --> C["jtqupujl.Y.c() → d() → b() System.loadLibrary('bochk_aos')"] C --> D["libbochk_aos.so JNI_OnLoad Promon Shield 初始化"] D --> E["Native 检测引擎 SVC 直接系统调用"] E --> E1["DoCodetracerDetection sub_26B680"] E --> E2["CodetracerDetection sub_26BD20"] E --> E3["AllowedPackagesForRootingCheck protobuf 配置"] E1 --> F["jtqupujl.U Service native a()/b()/c()/d()"] E2 --> F F --> G["jtqupujl.G AbstractBinder IPC 传递检测结果"] G --> H["构建 URL reason=22 & hookingframeworks=F4"] H --> I["k.j().D(fragment, url) Intent.ACTION_VIEW 打开浏览器"] A --> J["BOCHKLaunchFlow.Launch()"] J --> K["BOCHKLaunchFlow.K() Java 层 Root 检测"] K --> L["BOCLFRootUtils.checkRoot() 10项 RootBeer 检测"] L -->|"rooted"| M["BOCLFRootUtils.getRootErrorCode() 生成 reason 码"] M --> N["BOCHKLaunchFlow.Q() 上报 rootErrorCode 到服务器"] L -->|"not rooted"| O["BOCHKLaunchFlow.F() 继续启动流程"] </pre><hr> <h2 id="第一层java-root-检测"> <a class="header-anchor" href="#%e7%ac%ac%e4%b8%80%e5%b1%82java-root-%e6%a3%80%e6%b5%8b"></a> 第一层：Java Root 检测 </h2><h3 id="入口bochklaunchflowk"> <a class="header-anchor" href="#%e5%85%a5%e5%8f%a3bochklaunchflowk"></a> 入口：<a href="file:///G:/%e4%b8%8b%e8%bd%bd/promon-string-deobfuscator-main/apktool_work/decoded/smali_classes5/com/bochklaunchflow/BOCHKLaunchFlow.smali">BOCHKLaunchFlow.K()</a> </h3><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-java" data-lang="java">// BOCHKLaunchFlow.K() — Root 检查决策 if (!this.f32533m) { // setCheckRoot(false) 可跳过 F(activity); // 跳过 root 检测 return; } if (!BOCLFRootUtils.checkRoot(activity.getApplicationContext())) { F(activity); // 未 root，继续 return; } String rootErrorCode = BOCLFRootUtils.getRootErrorCode(ctx); Q(activity, this.f32529i, rootErrorCode); // 上报错误码 // 显示 root 提示对话框 </code></pre></td></tr></table> </div> </div><h3 id="boclfrootutilscheckroot--10项检测"> <a class="header-anchor" href="#boclfrootutilscheckroot--10%e9%a1%b9%e6%a3%80%e6%b5%8b"></a> <a href="file:///G:/%e4%b8%8b%e8%bd%bd/promon-string-deobfuscator-main/apktool_work/decoded/smali_classes5/com/bochklaunchflow/utils/BOCLFRootUtils.smali">BOCLFRootUtils.checkRoot()</a> — 10项检测 </h3><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 6 7 8 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-java" data-lang="java">return rootBeer.detectRootManagementApps() // bit9: Root管理App (Magisk/SuperSU) || rootBeer.detectPotentiallyDangerousApps() // bit8: 危险App || rootBeer.checkForBinary("su") // bit5: su二进制 || rootBeer.checkForRWPaths() // bit4: RW路径挂载 || rootBeer.detectTestKeys() // bit7: 测试签名keys || rootBeer.checkSuExists() // bit3: su进程存在 || rootBeer.checkForRootNative() // bit1: Native root检测 || rootBeer.detectRootCloakingApps(); // bit0: Root隐藏App </code></pre></td></tr></table> </div> </div><h3 id="boclfrootutilsgetrooterrorcode--reason-码生成"> <a class="header-anchor" href="#boclfrootutilsgetrooterrorcode--reason-%e7%a0%81%e7%94%9f%e6%88%90"></a> <a href="file:///G:/%e4%b8%8b%e8%bd%bd/promon-string-deobfuscator-main/apktool_work/decoded/smali_classes5/com/bochklaunchflow/utils/BOCLFRootUtils.smali">BOCLFRootUtils.getRootErrorCode()</a> — reason 码生成 </h3>生成 10位二进制字符串，转十进制作为 <code>reason</code> 值： <table> <thead> <tr> <th>Bit (高→低)</th> <th>检测项</th> <th>你的设备</th> </tr> </thead> <tbody> <tr> <td>bit9 (MSB)</td> <td><code>detectRootManagementApps()</code></td> <td>?</td> </tr> <tr> <td>bit8</td> <td><code>detectPotentiallyDangerousApps()</code></td> <td>?</td> </tr> <tr> <td>bit7</td> <td><code>detectTestKeys()</code></td> <td>?</td> </tr> <tr> <td>bit6</td> <td>(固定0)</td> <td>0</td> </tr> <tr> <td>bit5</td> <td><code>checkForSuBinary()</code></td> <td>?</td> </tr> <tr> <td>bit4</td> <td><code>checkSuExists()</code></td> <td>?</td> </tr> <tr> <td>bit3</td> <td><code>checkForRWPaths()</code></td> <td>?</td> </tr> <tr> <td>bit2</td> <td>(固定0)</td> <td>0</td> </tr> <tr> <td>bit1</td> <td><code>checkForRootNative()</code></td> <td>?</td> </tr> <tr> <td>bit0 (LSB)</td> <td><code>detectRootCloakingApps()</code></td> <td>?</td> </tr> </tbody> </table> <blockquote class="alert-blockquote important"> Important <code>reason=22</code> = 十进制22 = 二进制 <code>0000010110</code> <ul> <li>bit4 (=1): <code>checkSuExists()</code> 检测到 su</li> <li>bit2 (=1): <code>checkForRWPaths()</code> 检测到 RW 路径</li> <li>bit1 (=1): <code>checkForRootNative()</code> native层 root 检测</li> </ul> </blockquote> <hr> <h2 id="第二层promon-shield-native-检测-hookingframeworksf4"> <a class="header-anchor" href="#%e7%ac%ac%e4%ba%8c%e5%b1%82promon-shield-native-%e6%a3%80%e6%b5%8b-hookingframeworksf4"></a> 第二层：Promon Shield Native 检测 (hookingframeworks=F4) </h2><h3 id="初始化链"> <a class="header-anchor" href="#%e5%88%9d%e5%a7%8b%e5%8c%96%e9%93%be"></a> 初始化链 </h3><table> <thead> <tr> <th>步骤</th> <th>类</th> <th>方法</th> <th>作用</th> </tr> </thead> <tbody> <tr> <td>1</td> <td><code>jtqupujl.aP</code></td> <td><code>attachBaseContext()</code></td> <td>Application 入口，调用 Promon init</td> </tr> <tr> <td>2</td> <td><code>jtqupujl.Y</code></td> <td><code>c()</code> → <code>d()</code> → <code>b()</code></td> <td>加载 <code>libbochk_aos.so</code></td> </tr> <tr> <td>3</td> <td><code>jtqupujl.Y</code></td> <td><code>a(Application)</code> (native)</td> <td>初始化 Promon Shield</td> </tr> <tr> <td>4</td> <td><code>jtqupujl.U</code></td> <td><code>a()</code>, <code>b()</code>, <code>c()</code>, <code>d()</code> (native)</td> <td>Service 中暴露检测结果</td> </tr> <tr> <td>5</td> <td><code>jtqupujl.G</code></td> <td><code>a()</code>, <code>b()</code>, <code>c()</code>, <code>d()</code></td> <td>Binder IPC 代理检测结果</td> </tr> </tbody> </table> <h3 id="检测类型枚举-jtqupujlenumc0539aa--17种完整映射"> <a class="header-anchor" href="#%e6%a3%80%e6%b5%8b%e7%b1%bb%e5%9e%8b%e6%9e%9a%e4%b8%be-jtqupujlenumc0539aa--17%e7%a7%8d%e5%ae%8c%e6%95%b4%e6%98%a0%e5%b0%84"></a> 检测类型枚举 (<code>jtqupujl.EnumC0539aa</code>) — 17种完整映射 </h3> <blockquote class="alert-blockquote important"> Important 以下映射通过 JADX 源码分析（每个枚举值对应一个 <code>aO</code> 子类）+ IDA protobuf 字符串 + Promon Shield 官方文档交叉验证得出。 </blockquote> <table> <thead> <tr> <th>#</th> <th>枚举值</th> <th>实现类</th> <th>Key字段</th> <th>数据结构</th> <th>推断检测类型</th> </tr> </thead> <tbody> <tr> <td>1</td> <td><code>m</code></td> <td><code>C0571m</code></td> <td>1-4</td> <td>bool + 3×int</td> <td>Root检测 — 核心检测，keys 1-4 最小编号，3个int存root方法计数</td> </tr> <tr> <td>2</td> <td><code>f</code></td> <td><code>C0562d</code></td> <td>257 (0x101)</td> <td>bool</td> <td>Frida 检测 — 单布尔值，检测frida-server/agent</td> </tr> <tr> <td>3</td> <td><code>b</code></td> <td><code>aQ</code></td> <td>513 (0x201)</td> <td>bool</td> <td>调试器检测 (Debugger) — 单布尔值，反JDWP/ptrace</td> </tr> <tr> <td>4</td> <td><code>r</code></td> <td><code>C0559au</code></td> <td>769 (0x301)</td> <td>bool</td> <td>重打包检测 (Repackaging) — 签名校验</td> </tr> <tr> <td>5</td> <td><code>i</code></td> <td><code>ay</code></td> <td>1025-1030</td> <td>bool + 5×str</td> <td>Hooking框架检测 — 包含框架名/路径/版本等5字段</td> </tr> <tr> <td>6</td> <td><code>h</code></td> <td><code>C0573o</code></td> <td>1537 (0x601)</td> <td>bool</td> <td>屏幕叠加/录屏检测 — 防止Overlay攻击</td> </tr> <tr> <td>7</td> <td><code>q</code></td> <td><code>aG</code></td> <td>1793-1798</td> <td>bool + 5×str</td> <td>代码追踪器检测 (Code Tracer) — 与IDA中<code>DoCodetracerDetection</code>/<code>CodetracerDetection</code>对应</td> </tr> <tr> <td>8</td> <td><code>n</code></td> <td><code>C0564f</code></td> <td>5633-5634</td> <td>bool + int</td> <td>模拟器检测 (Emulator) — int存模拟器类型码</td> </tr> <tr> <td>9</td> <td><code>o</code></td> <td><code>aB</code></td> <td>6145-6146</td> <td>2×bool</td> <td>无障碍服务检测 — 两个bool分别检测是否开启和是否恶意</td> </tr> <tr> <td>10</td> <td><code>g</code></td> <td><code>K</code></td> <td>8705-8707</td> <td>str + 2×bool</td> <td>篡改检测 (Tampering) — 字符串存证书hash</td> </tr> <tr> <td>11</td> <td><code>l</code></td> <td><code>S</code></td> <td>8450-8451</td> <td>2×bool</td> <td>虚拟环境检测 — 双布尔，<code>d()</code>=a或b任一触发</td> </tr> <tr> <td>12</td> <td><code>k</code></td> <td><code>T</code></td> <td>12289-12291</td> <td>ComponentName + 2×str</td> <td>恶意Activity检测 — 存Activity组件名和包名</td> </tr> <tr> <td>13</td> <td><code>c</code></td> <td><code>C0540ab</code></td> <td>16384 (0x4000)</td> <td>bool</td> <td>SSL Pinning/证书验证 — 高key值检测</td> </tr> <tr> <td>14</td> <td><code>p</code></td> <td><code>C0549ak</code></td> <td>16640</td> <td>list(8-field)</td> <td>已安装App扫描 — 8字段详细记录每个可疑App信息</td> </tr> <tr> <td>15</td> <td><code>d</code></td> <td><code>C0572n</code></td> <td>16897 (0x4201)</td> <td>bool</td> <td>设备完整性检测 — Play Integrity / SafetyNet</td> </tr> <tr> <td>16</td> <td><code>j</code></td> <td><code>W</code></td> <td>17153 (0x4301)</td> <td>bool</td> <td>密钥存储检测 — Keystore安全检测</td> </tr> <tr> <td>17</td> <td><code>a</code></td> <td><code>aD</code></td> <td>LIVE_RESULT_SUCCESS</td> <td>list(5-field)</td> <td>恶意App哈希匹配 — 与服务器下发hash比对</td> </tr> </tbody> </table> <h3 id="检测结果回调流程"> <a class="header-anchor" href="#%e6%a3%80%e6%b5%8b%e7%bb%93%e6%9e%9c%e5%9b%9e%e8%b0%83%e6%b5%81%e7%a8%8b"></a> 检测结果回调流程 </h3><pre class="mermaid"> graph LR A["Native Detection libbochk_aos.so"] -->|JNI| B["jtqupujl.Q.b() 注册观察者 (native)"] B --> C["创建 aO 子类实例 (如 C0571m/C0562d等)"] C --> D["InterfaceC0567i.a(aO) 回调观察者"] D --> E["x1.b.a(aO) BOCHK 回调处理"] E -->|"enum a"| F["恶意App哈希匹配 → load_unofficial_app_key"] E -->|"enum p"| G["已安装App扫描 → load_unofficial_app_key"] D --> H["Promon内部处理 构建 securitywarning URL"] H --> I["k.j().D() 打开浏览器"] </pre><h3 id="关键发现x1b-回调实现"> <a class="header-anchor" href="#%e5%85%b3%e9%94%ae%e5%8f%91%e7%8e%b0x1b-%e5%9b%9e%e8%b0%83%e5%ae%9e%e7%8e%b0"></a> 关键发现：<code>x1.b</code> 回调实现 </h3><code>x1.b</code> 实现了 <code>InterfaceC0567i</code>，专门处理两种枚举的检测结果： <ul> <li><code>EnumC0539aa.a</code> (aD类): 遍历恶意App列表，提取包名/hash/路径 → 上传为 JSON</li> <li><code>EnumC0539aa.p</code> (C0549ak类): 遍历已安装App列表（8字段详细信息）→ 上传为 JSON</li> <li>两者合并后通过 <code>h2.a.c("load_unofficial_app_key")</code> 上报到服务器</li> </ul> <h3 id="native-层检测技术-ida-分析"> <a class="header-anchor" href="#native-%e5%b1%82%e6%a3%80%e6%b5%8b%e6%8a%80%e6%9c%af-ida-%e5%88%86%e6%9e%90"></a> Native 层检测技术 (IDA 分析) </h3><table> <thead> <tr> <th>函数</th> <th>IDA地址</th> <th>技术</th> </tr> </thead> <tbody> <tr> <td><code>DoCodetracerDetection</code></td> <td><code>sub_26B680</code></td> <td>通过 SVC 直接系统调用扫描 /proc/self/maps，检测 Frida agent 内存映射</td> </tr> <tr> <td><code>CodetracerDetection</code></td> <td><code>sub_26BD20</code></td> <td>检测代码追踪器（Frida/Xposed/Substrate 线程名和内存特征）</td> </tr> <tr> <td><code>OnCodeTracerDetectedCallback</code></td> <td>内部回调</td> <td>检测到后触发 pipe 通知</td> </tr> <tr> <td><code>SyscallNo</code></td> <td><code>0x3c099</code></td> <td>内联 SVC 系统调用号标记，绕过 libc hook</td> </tr> </tbody> </table> <h3 id="hookingframeworksf4-解析"> <a class="header-anchor" href="#hookingframeworksf4-%e8%a7%a3%e6%9e%90"></a> <code>hookingframeworks=F4</code> 解析 </h3><code>F4</code> 十六进制 = <code>244</code> 十进制 = 二进制 <code>11110100</code>，表示 Promon Shield 通过 <code>EnumC0539aa</code> 的多个检测类型均返回阳性： <table> <thead> <tr> <th>Bit</th> <th>可能含义</th> </tr> </thead> <tbody> <tr> <td>bit2=1</td> <td>Frida 检测（内存中发现 frida-agent）</td> </tr> <tr> <td>bit4=1</td> <td>Xposed Framework</td> </tr> <tr> <td>bit5=1</td> <td>Substrate/LSposed</td> </tr> <tr> <td>bit6=1</td> <td>代码追踪器/调试器</td> </tr> <tr> <td>bit7=1</td> <td>其他检测</td> </tr> </tbody> </table> <hr> <h2 id="第三层恶意软件检测-reason50"> <a class="header-anchor" href="#%e7%ac%ac%e4%b8%89%e5%b1%82%e6%81%b6%e6%84%8f%e8%bd%af%e4%bb%b6%e6%a3%80%e6%b5%8b-reason50"></a> 第三层：恶意软件检测 (reason=50) </h2>在 <code>MainActivity.a(C0566h)</code> 中，如果检测到恶意软件： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-java" data-lang="java">k.j().D(fragment, "https://www.bochk.com/dam/securitywarning.html?reason=50&srcApp=bochk"); PageManager.getInstance().removeAllFragment(); finish(); System.exit(0); </code></pre></td></tr></table> </div> </div>恶意软件扫描流程: <code>jtqupujl.aR</code> → <code>jtqupujl.aM.a()</code> 扫描已安装App → 与服务器下发的 SHA-256 哈希比对 → 匹配则触发 <code>reason=50</code>。 <hr> <h2 id="第四层cloudwalk-活体检测环境安全检查"> <a class="header-anchor" href="#%e7%ac%ac%e5%9b%9b%e5%b1%82cloudwalk-%e6%b4%bb%e4%bd%93%e6%a3%80%e6%b5%8b%e7%8e%af%e5%a2%83%e5%ae%89%e5%85%a8%e6%a3%80%e6%9f%a5"></a> 第四层：CloudWalk 活体检测环境安全检查 </h2>CloudWalk SDK (<code>cn.cloudwalk</code>) 是 BOCHK 使用的人脸活体检测组件。在启动活体检测前，会进行独立的环境安全检查。 <h3 id="入口cwbaselivefragmentcheckroot"> <a class="header-anchor" href="#%e5%85%a5%e5%8f%a3cwbaselivefragmentcheckroot"></a> 入口：<code>CwBaseLiveFragment.checkRoot()</code> </h3><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-java" data-lang="java">// 1. 先检查 Root if (mConfig.isCheckRuntimeEnvironment() && RootUtil.isDeviceRooted(getActivity(), mConfig.isCheckBusyBox())) { if (mConfig.isInterceptUnsafeRuntimeEnvironment()) { // 设备环境不安全，终止活体检测 handler.sendEmptyMessageDelayed(CMD.SERVER_RECEIVE_USER_DATA, ...); return; } // 回调 onLivenessFail(UNSAFE_ENVIRONMENT) } // 2. 禁用 Xposed disableXposed(); // 3. 检测 Hooking Framework if (mConfig.isCheckRuntimeEnvironment()) { HookToolDetector.c().a(context, callback); } // 4. 检测 HTTP 代理 if (DeviceUtil.isHttpProxy()) { detectFail(true, CwLiveCode.UNSAFE_NETWORK_ENVIRONMENT); } </code></pre></td></tr></table> </div> </div><h3 id="hooktooldetector-6项检测加载-libcwutilsso"> <a class="header-anchor" href="#hooktooldetector-6%e9%a1%b9%e6%a3%80%e6%b5%8b%e5%8a%a0%e8%bd%bd-libcwutilsso"></a> <code>HookToolDetector</code> 6项检测（加载 <code>LibCwUtils.so</code>） </h3><table> <thead> <tr> <th>方法</th> <th>检测技术</th> <th>详情</th> </tr> </thead> <tbody> <tr> <td><code>e()</code></td> <td>Xposed 类加载检测</td> <td>尝试 <code>ClassLoader.loadClass("de.robv.android.xposed.XposedHelpers")</code> 和 <code>"XposedBridge"</code>，加载成功=被 hook</td> </tr> <tr> <td><code>d()</code></td> <td>Xposed 异常栈检测</td> <td>故意抛出异常，遍历 <code>StackTrace</code> 检查是否包含 Xposed 类名</td> </tr> <tr> <td><code>f()</code></td> <td>内存映射检测</td> <td>读取 <code>/proc/self/maps</code>，搜索 3 个 Xposed 相关 so 库名（混淆字符）</td> </tr> <tr> <td><code>a()</code></td> <td>Frida 线程检测</td> <td>读取 <code>/proc/[pid]/task/*/status</code>，搜索 “frida”、“gmain”、“gdbus” 线程名</td> </tr> <tr> <td><code>b()</code></td> <td>调试器 TracerPid 检测</td> <td>读取 <code>/proc/[pid]/status</code> 的 <code>TracerPid</code> 字段，非0=被调试</td> </tr> <tr> <td><code>isFileExists()</code></td> <td>Native 文件完整性</td> <td>通过 <code>LibCwUtils.so</code> native 方法检测 sandbox/虚拟环境（创建测试文件 <code>cw-test.txt</code>，native 层验证文件是否真实存在）</td> </tr> </tbody> </table> <blockquote class="alert-blockquote note"> Note CloudWalk 还额外检测： <ul> <li>模拟器: <code>d.j().a(context)</code> — 模拟器环境检测</li> <li>HTTP 代理: <code>DeviceUtil.isHttpProxy()</code> — 检测中间人代理</li> <li>Mock 位置: <code>Location.isFromMockProvider()</code> — GPS 位置模拟检测</li> </ul> </blockquote> <hr> <h2 id="关键类映射表"> <a class="header-anchor" href="#%e5%85%b3%e9%94%ae%e7%b1%bb%e6%98%a0%e5%b0%84%e8%a1%a8"></a> 关键类映射表 </h2><table> <thead> <tr> <th>类</th> <th>功能</th> </tr> </thead> <tbody> <tr> <td><code>com.bochklaunchflow.BOCHKLaunchFlow</code></td> <td>启动流程总控：Root检测→版本检查→黑名单→维护</td> </tr> <tr> <td><code>com.bochklaunchflow.utils.BOCLFRootUtils</code></td> <td>Java Root检测：10项RootBeer检测 + 生成 reason 码</td> </tr> <tr> <td><code>com.tradelink.boc.rootdetection.ui.RootDetectionActivity</code></td> <td>Root检测 Activity UI</td> </tr> <tr> <td><code>com.scottyab.rootbeer.RootBeer</code></td> <td>第三方 Root 检测库</td> </tr> <tr> <td><code>cn.cloudwalk.libproject.hook.HookToolDetector</code></td> <td>CloudWalk Hook/Root/Frida 检测（加载 <code>LibCwUtils.so</code>）</td> </tr> <tr> <td><code>cn.cloudwalk.libproject.live.CwBaseLiveFragment</code></td> <td>活体检测入口，调用 <code>checkRoot()</code></td> </tr> <tr> <td><code>jtqupujl.aP</code></td> <td>Promon Application 入口</td> </tr> <tr> <td><code>jtqupujl.Y</code></td> <td>加载 <code>libbochk_aos.so</code>，初始化 Promon</td> </tr> <tr> <td><code>jtqupujl.U</code></td> <td>Service，暴露 native 检测结果</td> </tr> <tr> <td><code>jtqupujl.G</code></td> <td>Binder IPC 代理</td> </tr> <tr> <td><code>jtqupujl.aO</code></td> <td>检测结果 HashMap 存储</td> </tr> <tr> <td><code>jtqupujl.EnumC0539aa</code></td> <td>17种检测类型枚举</td> </tr> <tr> <td><code>jtqupujl.aR</code></td> <td>恶意软件扫描管理</td> </tr> <tr> <td><code>jtqupujl.aM</code></td> <td>恶意软件应用匹配</td> </tr> <tr> <td><code>jtqupujl.aS</code></td> <td><code>libjni_proxy_launcher.so</code> 加载</td> </tr> <tr> <td><code>com.bochk.base.utils.k.D()</code></td> <td><code>Intent.ACTION_VIEW</code> 打开安全警告 URL</td> </tr> </tbody> </table> <hr> <h2 id="总结"> <a class="header-anchor" href="#%e6%80%bb%e7%bb%93"></a> 总结 </h2>BOCHK App 使用 四层防护： <ol> <li>Java RootBeer (<code>BOCLFRootUtils</code>): 10项软检测，生成 <code>reason</code> 码（你的 <code>reason=22</code> = su存在 + RW路径 + native root）</li> <li>Promon Shield Native (<code>libbochk_aos.so</code>): 通过内联 SVC 系统调用检测 Frida/Xposed/调试器，生成 <code>hookingframeworks</code> 码（你的 <code>F4</code> = 多种框架被检测到）</li> <li>恶意软件扫描 (<code>jtqupujl.aR/aM</code>): 比对服务器哈希数据库，触发 <code>reason=50</code></li> <li>CloudWalk 环境检查 (<code>HookToolDetector</code>): 在人脸活体检测前执行 6 项独立检测（Xposed类加载/栈/maps + Frida线程 + TracerPid + native文件），加载 <code>LibCwUtils.so</code>，还检测模拟器/HTTP代理/Mock位置</li> </ol> 所有检测结果通过 <code>k.j().D(fragment, url)</code> → <code>Intent.ACTION_VIEW</code> 打开浏览器显示安全警告页面。 <h1 id="bochk-17种-promon-shield-检测方法深度分析"> <a class="header-anchor" href="#bochk-17%e7%a7%8d-promon-shield-%e6%a3%80%e6%b5%8b%e6%96%b9%e6%b3%95%e6%b7%b1%e5%ba%a6%e5%88%86%e6%9e%90"></a> BOCHK 17种 Promon Shield 检测方法深度分析 </h1> <blockquote class="alert-blockquote important"> Important Promon Shield 对所有敏感字符串（frida/xposed/su/magisk等）进行了运行时加密，静态分析无法直接找到明文。以下分析结合了 IDA 反编译、JADX 源码及 Promon Shield 官方文档。 </blockquote> <hr> <h2 id="检测方法总览"> <a class="header-anchor" href="#%e6%a3%80%e6%b5%8b%e6%96%b9%e6%b3%95%e6%80%bb%e8%a7%88"></a> 检测方法总览 </h2><pre class="mermaid"> graph TD subgraph "Native Layer - libbochk_aos.so" JIT["JIT代码生成器 动态组装 ARM SVC 指令"] SVC["SVC #0 直接系统调用 绕过 libc hook"] PROC["/proc 文件系统扫描 maps/status/mountinfo"] GOT["GOT 表完整性验证"] HASH["文件/段 Hash 校验"] end subgraph "Java Layer - jtqupujl.*" OBS["InterfaceC0567i 观察者"] ENUM["EnumC0539aa 17种类型"] AO["aO 子类实例化"] end JIT --> SVC SVC --> PROC PROC --> AO GOT --> AO HASH --> AO AO --> OBS </pre><hr> <h2 id="1-root检测-enumc0539aam--c0571m"> <a class="header-anchor" href="#1-root%e6%a3%80%e6%b5%8b-enumc0539aam--c0571m"></a> 1. Root检测 (<code>EnumC0539aa.m</code> → <code>C0571m</code>) </h2><h3 id="native-层-sub_a87f8"> <a class="header-anchor" href="#native-%e5%b1%82-sub_a87f8"></a> Native 层 (sub_A87F8) </h3><pre tabindex="0"><code>技术: 读取 /proc/self/mountinfo 检测可疑挂载 1. 通过 SVC 直接 openat() 打开 /mountinfo 2. 扫描挂载点寻找: - Magisk overlay 挂载 (tmpfs on /system) - /su, /magisk 路径 - rw 挂载的系统分区 (system/vendor) 3. 检查 AllowedPackagesForRootingCheck protobuf 白名单 </code></pre><h3 id="java-层-rootbeer"> <a class="header-anchor" href="#java-%e5%b1%82-rootbeer"></a> Java 层 (RootBeer) </h3><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 6 7 8 9 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-java" data-lang="java">// BOCLFRootUtils.checkRoot() — 10项检测 rootBeer.detectRootManagementApps() // Magisk Manager, SuperSU, KingRoot 等包名 rootBeer.detectPotentiallyDangerousApps() // BusyBox, Titanium Backup 等 rootBeer.checkForBinary("su") // PATH 中搜索 su 二进制 rootBeer.checkForRWPaths() // /system, /vendor 是否 rw 挂载 rootBeer.detectTestKeys() // ro.build.tags != release-keys rootBeer.checkSuExists() // Runtime.exec("which su") rootBeer.checkForRootNative() // Native JNI 检测 (libtool-checker.so) rootBeer.detectRootCloakingApps() // RootCloak, Xposed Installer 包名 </code></pre></td></tr></table> </div> </div><code>reason=22</code> 解码: 22 = 二进制 <code>10110</code> → bit4(checkSuExists) + bit2(checkForRWPaths) + bit1(checkForRootNative) IDA 关键地址: <code>sub_A87F8</code> (mountinfo解析), protobuf <code>AllowedPackagesForRootingCheck</code> @ <code>0x36808</code> <hr> <h2 id="2-frida检测-enumc0539aaf--c0562d"> <a class="header-anchor" href="#2-frida%e6%a3%80%e6%b5%8b-enumc0539aaf--c0562d"></a> 2. Frida检测 (<code>EnumC0539aa.f</code> → <code>C0562d</code>) </h2><h3 id="native-层--jit-svc-代码追踪器"> <a class="header-anchor" href="#native-%e5%b1%82--jit-svc-%e4%bb%a3%e7%a0%81%e8%bf%bd%e8%b8%aa%e5%99%a8"></a> Native 层 — JIT SVC 代码追踪器 </h3><pre tabindex="0"><code>函数: DoCodetracerDetection (sub_26B680) 技术: 动态生成 ARM 机器码，直接通过 SVC #0 调用内核 1. JIT 生成 openat() SVC 指令 → 打开 /proc/self/maps 2. JIT 生成 read() SVC 指令 → 逐行读取内存映射 3. 在内存中搜索加密后的 Frida 特征: - "frida-agent" 共享库映射 - "frida-gadget" - "linjector" (Frida 注入器线程) 4. JIT 生成 openat() → /proc/[pid]/task/[tid]/status 5. 搜索线程名特征: - "frida" (frida-server 线程) - "gmain" (GLib main loop - Frida 依赖) - "gdbus" (GLib D-Bus - Frida 依赖) 6. 端口扫描: connect() 到 localhost:27042 (Frida 默认端口) 关键: 所有 I/O 使用 SVC 直接系统调用，不经过 libc → Frida 的 Interceptor.attach(libc.open) 无法拦截 </code></pre>IDA 关键地址: <code>sub_26B680</code> (DoCodetracerDetection), <code>sub_26BD20</code> (CodetracerDetection), <code>0x3c099</code> (SyscallNo), <code>0x2f91a</code> (OnCodeTracerDetectedCallback) <hr> <h2 id="3-调试器检测-enumc0539aab--aq"> <a class="header-anchor" href="#3-%e8%b0%83%e8%af%95%e5%99%a8%e6%a3%80%e6%b5%8b-enumc0539aab--aq"></a> 3. 调试器检测 (<code>EnumC0539aa.b</code> → <code>aQ</code>) </h2><h3 id="native-层"> <a class="header-anchor" href="#native-%e5%b1%82"></a> Native 层 </h3><pre tabindex="0"><code>技术: 1. SVC openat(/proc/self/status) → 读取 TracerPid 字段 - TracerPid != 0 → 有调试器 (ptrace/JDWP) 2. SVC ptrace(PTRACE_TRACEME) → 自我附加 - 失败 = 已有调试器附加 3. 检查 /proc/self/wchan 是否包含 "ptrace_stop" 4. 定时器反调试: 测量代码执行时间 - clock_gettime() 差值过大 → 单步调试中 </code></pre><hr> <h2 id="4-重打包检测-enumc0539aar--c0559au"> <a class="header-anchor" href="#4-%e9%87%8d%e6%89%93%e5%8c%85%e6%a3%80%e6%b5%8b-enumc0539aar--c0559au"></a> 4. 重打包检测 (<code>EnumC0539aa.r</code> → <code>C0559au</code>) </h2><h3 id="native-层-1"> <a class="header-anchor" href="#native-%e5%b1%82-1"></a> Native 层 </h3><pre tabindex="0"><code>技术: 1. 读取 APK 签名证书 → 计算 SHA-256 hash 2. 与 protobuf 配置中的预存 hash 比对: - promon.pbi.HashedFile (@ 0x42dbf) - promon.pbi.FileHashes (@ 0x331d8) - promon.pbi.SegmentHashInfo (@ 0x36832) 3. 校验 DEX 文件完整性 (.dex headers + code segments) 4. 验证 native library hash: - promon.pbi.HashedShieldLibrary (@ 0x323f2) - promon.pbi.HashedShieldLibrary.filename (@ 0x3f019) </code></pre><hr> <h2 id="5-hooking-框架检测-enumc0539aai--ay"> <a class="header-anchor" href="#5-hooking-%e6%a1%86%e6%9e%b6%e6%a3%80%e6%b5%8b-enumc0539aai--ay"></a> 5. Hooking 框架检测 (<code>EnumC0539aa.i</code> → <code>ay</code>) </h2><h3 id="native-层-2"> <a class="header-anchor" href="#native-%e5%b1%82-2"></a> Native 层 </h3><pre tabindex="0"><code>技术 (ay 存储 bool + 5个字符串 = 框架名/路径/版本/hash/签名): 1. /proc/self/maps 扫描: 搜索 Xposed/Substrate 特征 so 库 - XposedBridge.jar 内存映射 - libsubstrate.so / libsubstrate-dvm.so - libart.so 的 inline hook 标记 2. Java ClassLoader 检查: - 尝试加载 "de.robv.android.xposed.XposedHelpers" - 尝试加载 "de.robv.android.xposed.XposedBridge" 3. 异常栈帧检查: 遍历 StackTrace 寻找 Xposed 类 4. GOT 表验证 (sub_16E2A0): - promon.pbi.GotVerifyInfo (@ 0x3243c) - 检查 libc/libart 的 GOT 入口是否被修改 - GOT 指向非原始库地址 = 被 inline hook </code></pre>IDA 关键地址: <code>sub_16E2A0</code> (GotVerifyInfo 验证), <code>sub_16E764</code> (GOT 二次验证) <hr> <h2 id="6-屏幕叠加录屏检测-enumc0539aah--c0573o"> <a class="header-anchor" href="#6-%e5%b1%8f%e5%b9%95%e5%8f%a0%e5%8a%a0%e5%bd%95%e5%b1%8f%e6%a3%80%e6%b5%8b-enumc0539aah--c0573o"></a> 6. 屏幕叠加/录屏检测 (<code>EnumC0539aa.h</code> → <code>C0573o</code>) </h2><h3 id="native-层--java-代理"> <a class="header-anchor" href="#native-%e5%b1%82--java-%e4%bb%a3%e7%90%86"></a> Native 层 + Java 代理 </h3><pre tabindex="0"><code>技术: 1. promon.pbi.ScreenMirroringBlock (@ 0x439e7) 配置 app_block_layout_name 和 landscape 版本 2. 检测前台是否有其他 Activity overlay (FLAG_SECURE) 3. 检测 MediaProjection API 录屏 4. 检测 AccessibilityService 是否在读取屏幕内容 5. 前台 Activity 切换监控: - promon.pbi.AllowedActivitiesForScreenshots (@ 0x32411) → 白名单外的 Activity 被覆盖时触发 </code></pre>IDA 关键地址: <code>sub_17196C</code> (ScreenMirroringBlock 初始化), <code>sub_171AFC</code> (布局检测) <hr> <h2 id="7-代码追踪器检测-enumc0539aaq--ag"> <a class="header-anchor" href="#7-%e4%bb%a3%e7%a0%81%e8%bf%bd%e8%b8%aa%e5%99%a8%e6%a3%80%e6%b5%8b-enumc0539aaq--ag"></a> 7. 代码追踪器检测 (<code>EnumC0539aa.q</code> → <code>aG</code>) </h2><h3 id="native-层--核心-jit-检测引擎"> <a class="header-anchor" href="#native-%e5%b1%82--%e6%a0%b8%e5%bf%83-jit-%e6%a3%80%e6%b5%8b%e5%bc%95%e6%93%8e"></a> Native 层 — 核心 JIT 检测引擎 </h3><pre tabindex="0"><code>函数: DoCodetracerDetection (sub_26B680) + CodetracerDetection (sub_26BD20) 技术: 与 Frida 检测共享引擎，但更广泛: 1. 动态 JIT 生成 ARM 指令序列: a. MOV R8, #syscall_number (加密) → 设置系统调用号 b. SVC #0 → 触发内核调用 c. 后续指令处理返回值 2. 生成的系统调用链: - openat(AT_FDCWD, "/proc/self/maps", O_RDONLY) - read(fd, buf, size) → 逐块读取 - 在 buf 中搜索加密特征字符串 - close(fd) 3. 注册 OnCodeTracerDetectedCallback (@ 0x2f91a) → 检测到异常时通过 pipe 通知 Java 层 4. aG 存储 bool + 5个字符串: - 追踪器类型名称 - 检测位置 (maps/threads/ports) - 进程/线程信息 - 时间戳 - 详细描述 </code></pre><hr> <h2 id="8-模拟器检测-enumc0539aan--c0564f"> <a class="header-anchor" href="#8-%e6%a8%a1%e6%8b%9f%e5%99%a8%e6%a3%80%e6%b5%8b-enumc0539aan--c0564f"></a> 8. 模拟器检测 (<code>EnumC0539aa.n</code> → <code>C0564f</code>) </h2><h3 id="native-层-3"> <a class="header-anchor" href="#native-%e5%b1%82-3"></a> Native 层 </h3><pre tabindex="0"><code>技术 (C0564f 存储 bool + int模拟器类型码): 1. 系统属性检查 (SVC 读取): - ro.hardware: goldfish/ranchu/vbox86 - ro.product.model: SDK/Emulator/Android SDK built - ro.kernel.qemu: 1 - ro.secure: 0 2. /proc/cpuinfo 特征: - Hardware: Goldfish/Ranchu - 缺少物理 CPU 特征 3. 传感器检查: - 加速度/陀螺仪等传感器数据异常 4. 电池状态: 永远充电/电量不变 5. Build 指纹: - Build.FINGERPRINT 包含 "generic"/"sdk"/"test-keys" - Build.HARDWARE == "goldfish" 6. Play Integrity API 查询 (新版) </code></pre><hr> <h2 id="9-无障碍服务检测-enumc0539aao--ab"> <a class="header-anchor" href="#9-%e6%97%a0%e9%9a%9c%e7%a2%8d%e6%9c%8d%e5%8a%a1%e6%a3%80%e6%b5%8b-enumc0539aao--ab"></a> 9. 无障碍服务检测 (<code>EnumC0539aa.o</code> → <code>aB</code>) </h2><h3 id="java-层--native-层"> <a class="header-anchor" href="#java-%e5%b1%82--native-%e5%b1%82"></a> Java 层 + Native 层 </h3><pre tabindex="0"><code>技术 (aB 存储 2×bool: 是否开启 + 是否恶意): 1. AccessibilityManager.getEnabledAccessibilityServiceList() - 枚举所有启用的无障碍服务 2. promon.pbi.AllowedActivitiesForScreenreader (@ 0x34796) - 白名单比对，非白名单服务 = 可疑 3. 检测是否有服务正在读取 View 树内容 4. 检查 canRetrieveWindowContent 权限 </code></pre>IDA 关键地址: protobuf <code>AllowedActivitiesForScreenreader</code> @ <code>0x34796</code>, xrefs 在 <code>0x42323</code> <hr> <h2 id="10-篡改检测-enumc0539aag--k"> <a class="header-anchor" href="#10-%e7%af%a1%e6%94%b9%e6%a3%80%e6%b5%8b-enumc0539aag--k"></a> 10. 篡改检测 (<code>EnumC0539aa.g</code> → <code>K</code>) </h2><h3 id="native-层-4"> <a class="header-anchor" href="#native-%e5%b1%82-4"></a> Native 层 </h3><pre tabindex="0"><code>技术 (K 存储 str证书hash + 2×bool): 1. APK 签名验证: - PackageManager.GET_SIGNING_CERTIFICATES - 计算证书 SHA-256 与配置比对 2. DEX 文件 CRC 校验: - classes.dex 完整性验证 3. native library 代码段 hash: - promon.pbi.SegmentHashInfo (@ 0x36832) - .text section hash 比对 4. promon.pbi.LibraryInfo (@ 0x351e2) 验证: - soname / filename 比对 - promon.pbi.LibraryInfos (@ 0x42df2) 列表 </code></pre><hr> <h2 id="11-虚拟环境检测-enumc0539aal--s"> <a class="header-anchor" href="#11-%e8%99%9a%e6%8b%9f%e7%8e%af%e5%a2%83%e6%a3%80%e6%b5%8b-enumc0539aal--s"></a> 11. 虚拟环境检测 (<code>EnumC0539aa.l</code> → <code>S</code>) </h2><h3 id="native-层-5"> <a class="header-anchor" href="#native-%e5%b1%82-5"></a> Native 层 </h3><pre tabindex="0"><code>技术 (S 存储 2×bool, d()=任一触发): bool[0]: 虚拟空间检测 (VirtualXposed/VirtualApp/太极) - 检查 /data/data 下是否有多层嵌套 uid - 检测 android.os.Binder.getCallingUid() 异常 - 扫描 /proc/self/maps 中虚拟框架 so 库 bool[1]: 工作配置文件/容器检测 - 检测 Android Work Profile 环境 - 检测三星 Knox / MIUI 分身等系统级双开 </code></pre><hr> <h2 id="12-恶意activity检测-enumc0539aak--t"> <a class="header-anchor" href="#12-%e6%81%b6%e6%84%8factivity%e6%a3%80%e6%b5%8b-enumc0539aak--t"></a> 12. 恶意Activity检测 (<code>EnumC0539aa.k</code> → <code>T</code>) </h2><h3 id="java--native-层"> <a class="header-anchor" href="#java--native-%e5%b1%82"></a> Java + Native 层 </h3><pre tabindex="0"><code>技术 (T 存储 ComponentName + 2×str): 1. promon.pbi.LaunchActivities (@ 0x351f9) 配置 - 定义合法的 Launch Activity 列表 - promon.pbi.LaunchActivity.class_name (@ 0x37c5d) - promon.pbi.LaunchActivity.hash (@ 0x39b49) 2. 监控当前前台 Activity 组件名 - 非白名单 Activity 启动 = 可能被篡改/注入 3. promon.pbi.ConsentActivities 同意弹窗验证 </code></pre><hr> <h2 id="13-ssl-pinning证书验证-enumc0539aac--c0540ab"> <a class="header-anchor" href="#13-ssl-pinning%e8%af%81%e4%b9%a6%e9%aa%8c%e8%af%81-enumc0539aac--c0540ab"></a> 13. SSL Pinning/证书验证 (<code>EnumC0539aa.c</code> → <code>C0540ab</code>) </h2><h3 id="native-层-libressl"> <a class="header-anchor" href="#native-%e5%b1%82-libressl"></a> Native 层 (LibreSSL) </h3><pre tabindex="0"><code>技术 (C0540ab 存储 bool): 1. 内置 LibreSSL 库 (@ /build/sfs/shield/third_party/libressl/) - 不依赖系统 SSL，防止证书替换 2. Trust Root 验证 (@ 0x3cd40): - "root ca not trusted" (@ 0x43400) 错误信息 - setCext-hashedRoot (@ 0x4293e) 3. 证书链验证: - set-policy-root (@ 0x401f7) - trustRoot (@ 0x37856) 4. 检测证书被用户安装的 CA 替换 - 抓包工具 (Charles/Fiddler/mitmproxy) 的证书会触发 </code></pre><hr> <h2 id="14-已安装app扫描-enumc0539aap--c0549ak"> <a class="header-anchor" href="#14-%e5%b7%b2%e5%ae%89%e8%a3%85app%e6%89%ab%e6%8f%8f-enumc0539aap--c0549ak"></a> 14. 已安装App扫描 (<code>EnumC0539aa.p</code> → <code>C0549ak</code>) </h2><h3 id="java-层-x1b-回调处理"> <a class="header-anchor" href="#java-%e5%b1%82-x1b-%e5%9b%9e%e8%b0%83%e5%a4%84%e7%90%86"></a> Java 层 (x1.b 回调处理) </h3><pre tabindex="0"><code>技术 (C0549ak 存储 8字段对象列表): 1. PackageManager.getInstalledApplications() 获取列表 2. 每个App记录 8 个字段: - packageName, versionName, sourceDir - apkHash (SHA-256), signature, label - installTime, flags 3. 与 promon.pbi.ClassIds (@ 0x33afe) 配置黑名单比对 4. 上报到服务器: h2.a.c("load_unofficial_app_key") 5. 记为 JSON 包含 uuid + deviceModel + osVersion + unofficialApps </code></pre><hr> <h2 id="15-设备完整性检测-enumc0539aad--c0572n"> <a class="header-anchor" href="#15-%e8%ae%be%e5%a4%87%e5%ae%8c%e6%95%b4%e6%80%a7%e6%a3%80%e6%b5%8b-enumc0539aad--c0572n"></a> 15. 设备完整性检测 (<code>EnumC0539aa.d</code> → <code>C0572n</code>) </h2><h3 id="java--native-层-1"> <a class="header-anchor" href="#java--native-%e5%b1%82-1"></a> Java + Native 层 </h3><pre tabindex="0"><code>技术 (C0572n 存储 bool): 1. Google Play Integrity API 调用 - 获取设备完整性令牌 - 检查 MEETS_DEVICE_INTEGRITY 2. SafetyNet Attestation (旧版回退) - ctsProfileMatch + basicIntegrity 3. bootloader 锁定状态检测: - ro.boot.verifiedbootstate - ro.boot.flash.locked </code></pre><hr> <h2 id="16-密钥存储检测-enumc0539aaj--w"> <a class="header-anchor" href="#16-%e5%af%86%e9%92%a5%e5%ad%98%e5%82%a8%e6%a3%80%e6%b5%8b-enumc0539aaj--w"></a> 16. 密钥存储检测 (<code>EnumC0539aa.j</code> → <code>W</code>) </h2><h3 id="java--native-层-2"> <a class="header-anchor" href="#java--native-%e5%b1%82-2"></a> Java + Native 层 </h3><pre tabindex="0"><code>技术 (W 存储 bool): 1. Android Keystore 安全检测 - 检查硬件级 Keystore (TEE/StrongBox) - KeyInfo.isInsideSecureHardware() 2. Keymaster/Keymint 版本验证 3. 检测 Magisk 是否 hook 了 Keystore 接口 4. 检测 KeyAttestation 证书链是否被篡改 </code></pre><hr> <h2 id="17-恶意app哈希匹配-enumc0539aaa--ad"> <a class="header-anchor" href="#17-%e6%81%b6%e6%84%8fapp%e5%93%88%e5%b8%8c%e5%8c%b9%e9%85%8d-enumc0539aaa--ad"></a> 17. 恶意App哈希匹配 (<code>EnumC0539aa.a</code> → <code>aD</code>) </h2><h3 id="java-层-jtqupujlam--x1b"> <a class="header-anchor" href="#java-%e5%b1%82-jtqupujlam--x1b"></a> Java 层 (jtqupujl.aM + x1.b) </h3><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-java" data-lang="java">// jtqupujl.aM.a(context, packageManager, list, str) 技术 (aD 存储 5字段对象列表): 1. 从服务器下载 malware_applications JSON: - 包含 appPackageName + apkHashSHA256 列表 2. PackageManager.getInstalledApplications(131072) - 过滤系统App (flags & FLAG_SYSTEM) 3. 计算每个非系统App的 APK SHA-256 hash 4. 与服务器下发的 hash 列表比对 5. 匹配成功 → C0552an 记录: - packageName, sourceDir, label, versionName, hash 6. 通过 jtqupujl.aR.a().a(c0566h) 通知观察者 7. MainActivity.a(C0566h) → 打开 reason=50 URL </code></pre></td></tr></table> </div> </div><hr> <h2 id="native-层核心反检测对抗技术"> <a class="header-anchor" href="#native-%e5%b1%82%e6%a0%b8%e5%bf%83%e5%8f%8d%e6%a3%80%e6%b5%8b%e5%af%b9%e6%8a%97%e6%8a%80%e6%9c%af"></a> Native 层核心反检测对抗技术 </h2><h3 id="1-jit-svc-引擎-最关键"> <a class="header-anchor" href="#1-jit-svc-%e5%bc%95%e6%93%8e-%e6%9c%80%e5%85%b3%e9%94%ae"></a> 1. JIT SVC 引擎 (最关键) </h3><pre tabindex="0"><code>sub_26B680 (DoCodetracerDetection): 动态生成 ARM32 机器码 → 分配可执行内存 → 直接执行生成的指令序列 (重建): PUSH {R4-R7,LR} MOV R8, #<encrypted_syscall_no> // openat = 322 EOR R8, R8, #<key> // 解密syscall号 MOV R0, #-100 // AT_FDCWD LDR R1, [PC, #offset] // 指向加密的路径字符串 MOV R2, #0 // O_RDONLY SVC #0 // 直接调用内核! ... (read/scan/close) 优势: - Frida Interceptor 无法拦截 (不经过 libc) - 代码在运行时才生成 (静态分析看不到) - SyscallNo 加密存储，每次运行解密 </code></pre><h3 id="2-字符串全加密"> <a class="header-anchor" href="#2-%e5%ad%97%e7%ac%a6%e4%b8%b2%e5%85%a8%e5%8a%a0%e5%af%86"></a> 2. 字符串全加密 </h3><pre tabindex="0"><code>所有敏感字符串 (frida/xposed/su/magisk/com.topjohnwu 等) 在二进制中以加密形式存储，运行时动态解密到栈上 → IDA strings 搜索找不到任何检测目标名称 </code></pre><h3 id="3-got-完整性验证"> <a class="header-anchor" href="#3-got-%e5%ae%8c%e6%95%b4%e6%80%a7%e9%aa%8c%e8%af%81"></a> 3. GOT 完整性验证 </h3><pre tabindex="0"><code>sub_16E2A0 (GotVerifyInfo): 1. 记录 libc.so 的 GOT 表地址 2. 定时扫描 GOT 入口是否被修改 3. GOT[open] 不指向 libc → 被 hook → 检测 PLT hook (LD_PRELOAD/Frida replace) </code></pre><h3 id="4-41个-protobuf-配置消息"> <a class="header-anchor" href="#4-41%e4%b8%aa-protobuf-%e9%85%8d%e7%bd%ae%e6%b6%88%e6%81%af"></a> 4. 41个 Protobuf 配置消息 </h3><pre tabindex="0"><code>promon.pbi.* 完整列表: AllowedPackagesForRootingCheck → Root检测白名单 AllowedActivitiesForScreenshots → 截屏白名单 AllowedActivitiesForScreenreader → 无障碍白名单 ScreenMirroringBlock → 屏幕叠加阻断 HashedShieldLibrary / HashedFile → 文件完整性 FileHashes / SegmentHashInfo → 代码段hash GotVerifyInfo → GOT hook检测 ClassIds / MemberId → Java类监控 LaunchActivities / LaunchActivity → Activity验证 ConsentActivities → 用户同意弹窗 LibraryInfo / LibraryInfos → so库验证 PullBindings / PushBindings → 绑定配置 JigsawBlock / EncryptedBlock → 代码加密分块 SignedPbiData / UnsignedPbiData → 签名配置 Value / Binding → 通用绑定 </code></pre> <hr>本文2026-03-02首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-03-02 </article> <article> <h1>windows下git中文乱码的解决方案</h1> xxx@example.com (catcatyu) — Mon, 02 Mar 2026 18:04:59 +0800 <h1>windows下git中文乱码的解决方案</h1>作者：catcatyu（xxx@example.com） 网上查的都没用，因为设置的是让git输出utf-8，而powershell按gbk来读取，无论怎么读都是乱码，如： 所以可以尝试： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-powershell" data-lang="powershell">[System.Console]::OutputEncoding = [System.Text.Encoding]::UTF8 </code></pre></td></tr></table> </div> </div>这样就能读取utf8字符串，而chcp 65001则只对cmd生效，对powershell无效，因为powershell内部还有一个处理数据的地方。 下面是永久生效方法： 1. 开放脚本执行权限（非常重要，很多配置不生效就是因为这个）： 以管理员身份打开一个新的 PowerShell 窗口，运行： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-powershell" data-lang="powershell">Set-ExecutionPolicy RemoteSigned -Scope CurrentUser </code></pre></td></tr></table> </div> </div>（提示时输入 <code>Y</code> 并回车确认）。 2. 把配置写入启动文件： 回到你普通的 PowerShell 窗口，依次运行下面两行命令（第一行是确保文件存在，第二行是直接把配置追加到文件末尾）： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-powershell" data-lang="powershell">if (!(Test-Path -Path $PROFILE)) { New-Item -ItemType File -Path $PROFILE -Force } Add-Content -Path $PROFILE -Value '[System.Console]::OutputEncoding = [System.Text.Encoding]::UTF8' </code></pre></td></tr></table> </div> </div>3. 验证成果： 关掉所有 PowerShell 窗口，重新打开一个全新的窗口，输入 <code>git status</code>。 <hr>本文2026-03-02首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-03-02 </article> <article> <h1>windows上codex插件+vscode配置中转站API参考以及中文乱码还有自动同意策略、管理员权限的解决方案</h1> xxx@example.com (catcatyu) — Mon, 02 Mar 2026 16:54:20 +0800 <h1>windows上codex插件+vscode配置中转站API参考以及中文乱码还有自动同意策略、管理员权限的解决方案</h1>作者：catcatyu（xxx@example.com） 可以先配置好CLIProxyAPI，代理是在内部proxy-url可以设置 然后在%USERPROFILE%/.codex/config.toml中参考以下配置： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-toml" data-lang="toml">model_provider = "fox" model = "gpt-5.3-codex" model_reasoning_effort = "high" features.powershell_utf8 = true approval_policy = "never" sandbox_mode = "danger-full-access" [windows] sandbox = "elevated" [model_providers.fox] name = "fox" base_url = "http://192.168.1.5:8317/v1" wire_api = "responses" requires_openai_auth = true [features] powershell_utf8 = false [mcp_servers.ida-pro-mcp] command = "C:\\Users\\54930\\AppData\\Local\\Programs\\Python\\Python314\\python.exe" args = [ "C:\\Users\\54930\\AppData\\Local\\Programs\\Python\\Python314\\Lib\\site-packages\\ida_pro_mcp\\server.py", "--ida-rpc", "http://127.0.0.1:13337", ] [mcp_servers.jadx_mcp_server] command = "C:\\Users\\54930\\.local\\bin\\uv.exe" args = [ "--directory", "G:\\\u4E0B\u8F7D\\jadx-mcp-server-v6.1.0\\jadx-mcp-server", "run", "jadx_mcp_server.py" ] env = { PYTHONUTF8 = "1" } enabled = true </code></pre></td></tr></table> </div> </div>还有%USERPROFILE%/.codex/auth.json <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-json" data-lang="json">{ "OPENAI_API_KEY":"your-api-key-1" } </code></pre></td></tr></table> </div> </div>注意如果有中文路径可能会导致stdio方式我i收的mcp握手失败<code>MCP startup failed: handshaking ... connection closed: initialize response</code> 需要加上<code>env = { PYTHONUTF8 = "1" }</code>参数，不然会导致中文编码乱码问题。 还需要在提示词里面加上，每次使用powershell之前要$PSDefaultParameterValues[‘Get-Content:Encoding’] = ‘UTF8’，不然Get-Content也可能会乱码。也可以在powershell的profile里面配置： <pre tabindex="0"><code>code $PROFILE $PSDefaultParameterValues['Get-Content:Encoding'] = 'utf8' </code></pre>加了approval_policy = “never"之后可以避免烦人的同意按钮。 <pre tabindex="0"><code>sandbox_mode = "danger-full-access" [windows] sandbox = "elevated" </code></pre>加上可以让codex用管理员身份启动 <pre tabindex="0"><code>[features] powershell_utf8 = false </code></pre>这一行最好也加上不然容易乱码 测试脚本如下： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-python" data-lang="python">import tomllib, pathlib, subprocess, time cfg = pathlib.Path(r'C:\Users\54930\.codex\config.toml') d = tomllib.loads(cfg.read_text(encoding='utf-8')) j = d['mcp_servers']['jadx_mcp_server'] cmd = [j['command'], *j['args']] p = subprocess.Popen(cmd, stdin=subprocess.PIPE, stdout=subprocess.PIPE, stderr=subprocess.PIPE) try: time.sleep(1.0) chunk = p.stderr.peek(256)[:256] print('stderr_chunk_len=', len(chunk)) try: chunk.decode('utf-8','strict') print('stderr_utf8_strict=OK') except Exception as e: print('stderr_utf8_strict=FAIL', type(e).__name__, str(e)) finally: p.terminate() try: p.wait(timeout=2) except: pass </code></pre></td></tr></table> </div> </div>另外Codex的历史记录会在C:\Users\54930.codex\sessions\2026\03\02*.jsonl这个里面 <hr>本文2026-03-02首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-03-02 </article> <article> <h1>apt设置代理的简易方法</h1> xxx@example.com (catcatyu) — Mon, 02 Mar 2026 10:22:46 +0800 <h1>apt设置代理的简易方法</h1>作者：catcatyu（xxx@example.com） apt设置代理，网上的方法都太复杂，实际上只要用环境变量即可： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">export http_proxy=http://127.0.0.1:10808 export https_proxy=http://127.0.0.1:10808 </code></pre></td></tr></table> </div> </div>但是设置完不生效是为什么呢，因为apt往往要加sudo运行，而sudo会把之前的环境变量给重置掉。 所以只要让sudo不重置，即可，那就是使用<code>sudo -E</code>即可 <pre tabindex="0"><code>sudo -E apt update </code></pre> <hr>本文2026-03-02首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-03-02 </article> <article> <h1>安卓导出内核崩溃日志</h1> xxx@example.com (catcatyu) — Fri, 27 Feb 2026 17:18:27 +0800 <h1>安卓导出内核崩溃日志</h1>作者：catcatyu（xxx@example.com） 在kernelsu开发过程中但往往会导致内核崩溃，需要导出内核日志进行分析，目前试了下设备树编译pstore无效，之后发现高通的QPST可以解决这个问题： 我是一加手机，输入*#800#可以进入如下界面： 里面需要配置dump： 之后手机内核如果崩溃会进入这个界面： Qualcomm Crashdump Mode 保持页面，下载高通驱动重启， 1.安装 <a href="https://qcomdriver.com/" target="_blank" rel="noopener noreferrer nofollow">https://qcomdriver.com/</a> — 设备会显示为 Qualcomm HS-USB Diagnostics 900E 2.安装 <a href="https://qpsttool.com/qpst-tool-v2-7-496" target="_blank" rel="noopener noreferrer nofollow">QPST tool</a> 3.打开 QPST Configuration，会自动dump内存，之后只要在QPST Configuration中用Vscode打开日志即可： <hr>本文2026-02-27首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-02-27 </article> <article> <h1>使用bettercap破解wifi密码</h1> xxx@example.com (catcatyu) — Tue, 24 Feb 2026 19:03:33 +0800 <h1>使用bettercap破解wifi密码</h1>作者：catcatyu（xxx@example.com） 最近过年回爷爷家，发现爷爷家有一个特殊的USB无线网卡Tenda U6和COMFAST CF-952AX v2，淘宝上都很便宜，还有一个奋威 Fenvi FU-AX1800 是MT7921 想起了以前上学时候使用这种USB无线网卡破wifi的经历，就尝试了一下： 破解wifi的网卡最重要的是驱动是否支持，可以去<a href="https://github.com/morrownr/USB-WiFi/blob/main/home/Recommended_Adapters_for_Kali_Linux.md" target="_blank" rel="noopener noreferrer nofollow">这里</a> 查询 如果支持了，可以使用Bettercap进行破解，需要注意这几个问题： 1.操作系统内核版本，如果是COMFAST CF-952AX v2用的是RTL8852BU需要满足linux内核在6.17以上.奋威AX1800则需要满足内核6.12（含6.12）以下，6.13开始会有<a href="https://github.com/morrownr/USB-WiFi/issues/687" target="_blank" rel="noopener noreferrer nofollow">bug</a> 抓不到管理帧Beacon 2.操作系统是否开启了WEXT支持，可以用<code>grep -i wext /boot/config-$(uname -r) </code>查看，如果提示 <code>CONFIG_CFG80211_WEXT is not set</code>则iwlist用不了，需要使用<a href="https://github.com/bettercap/bettercap/pull/1248" target="_blank" rel="noopener noreferrer nofollow">patch过的版本</a> 来使用NL80211协议的iw（我和作者battle不过QAQ） 解决以上问题之后，在虚拟机里面透传usb无线网卡，我是mac用的vmware Fusion。并使用源码编译的方式安装Bettercap： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">git clone https://github.com/bettercap/bettercap.git cd bettercap make install </code></pre></td></tr></table> </div> </div>之后使用命令开启webui: <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"> bettercap -eval "set ui.address 0.0.0.0;set api.rest.address 0.0.0.0 ;ui on" </code></pre></td></tr></table> </div> </div>在webui里面可以开启wifi模块，当你看到wifi模块里面某个wifi有几个红色的client的时候： 记住他的信道，在这里输入： <pre tabindex="0"><code>wifi.recon.channel 11 </code></pre> 之后可以使用deauth攻击等着嗅探出握手包. 需要注意的是，wifi网卡一次只能监听一个信道，所以一开始的界面是轮流监听信道，可能抓到的握手包不完整，只能当扫描器使用，真正的嗅探握手包还是需要指定信道的。 如果抓到握手包了就可以看到一把钥匙，这个就是抓包文件： 之后使用hcxpcapngtool即可导出让hashcat破解,这个工具也需要<a href="https://github.com/ZerBea/hcxtools" target="_blank" rel="noopener noreferrer nofollow">编译安装</a> ： <pre tabindex="0"><code>hcxpcapngtool bettercap-wifi-handshakes.pcap -o keyfile </code></pre>里面的EAPOL pairs(best)就是成功的导出数量： <pre tabindex="0"><code>EAPOL pairs (total)......................: 32 EAPOL pairs (best).......................: 3 </code></pre>之后使用hashcat即可破解，需要用好一点的显卡： <pre tabindex="0"><code>.\hashcat.exe -m 22000 -a 3 .\keyfile ?d?d?d?d?d?d?d?d </code></pre>或者字典攻击，可以使用<a href="https://github.com/danielmiessler/SecLists/blob/master/Passwords/WiFi-WPA/probable-v2-wpa-top447.txt" target="_blank" rel="noopener noreferrer nofollow">seclist</a> ： <pre tabindex="0"><code>.\hashcat.exe -m 22000 -a 0 .\keyfile .\probable-v2-wpa-top4800.txt </code></pre>总的来说这个工具比aircrack-ng好用。赞一个。除此之外，你也可以尝试使用命令<code>wifi.deauth all</code>或者<code>wifi.assoc all</code>来批量发送deauth攻击和pmkid攻击，锁定信道效果更佳，需要注意的是可能有假阳性存在，可以看<a href="https://github.com/bettercap/bettercap/pull/1249" target="_blank" rel="noopener noreferrer nofollow">我这个pr</a> 顺带一提我在mac上跑Fedora 43，运行aireplay-ng的时候提示Couldn’t determine current channel for wlan0mon, you should either force the operation with –ignore-negative-one or apply a kernel patch.，这就是WEXT兼容性的问题，需要<a href="https://github.com/aircrack-ng/aircrack-ng/pull/2702" target="_blank" rel="noopener noreferrer nofollow">我这个补丁</a> 来解决。 <hr>本文2026-02-24首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-02-24 </article> <article> <h1>使用caddy签发ip证书</h1> xxx@example.com (catcatyu) — Wed, 18 Feb 2026 11:56:45 +0800 <h1>使用caddy签发ip证书</h1>作者：catcatyu（xxx@example.com） 使用SSL证书可以确保网页的安全性，但是往往需要一个域名才能签发，之前能白嫖ip6.arpa域名，但是根据Ballot SC-086v3已经下架了。目前我们如果有公网ip可以用lets encrypt签发证书，时间只有几天，但使用caddy可以自动续期，配置文件如下： <pre tabindex="0"><code># HTTPS site (existing) 123.123.123.123 { tls { issuer acme { dir https://acme-v02.api.letsencrypt.org/directory profile shortlived } } handle { reverse_proxy localhost:80 } } </code></pre> <hr>本文2026-02-18首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-02-18 </article> <article> <h1>记一次奇怪的ssh公钥登录失败的情况</h1> xxx@example.com (catcatyu) — Sun, 15 Feb 2026 10:40:13 +0800 <h1>记一次奇怪的ssh公钥登录失败的情况</h1>作者：catcatyu（xxx@example.com） 配置了公钥之后提示登录失败，于是开启了-vvv模式，提示： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 6 7 8 9 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">debug1: Offering public key: /Users/jihanfu/.ssh/id_rsa RSA SHA256:HYJ/2VQ9GbMqG8KZAHfuNlcU+j8qWeQSTi+NEZFR1Tw debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,password debug1: Trying private key: /Users/jihanfu/.ssh/id_ecdsa debug3: no such identity: /Users/jihanfu/.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /Users/jihanfu/.ssh/id_ecdsa_sk debug3: no such identity: /Users/jihanfu/.ssh/id_ecdsa_sk: No such file or directory </code></pre></td></tr></table> </div> </div>注意到中间receive packet: type 51，收到了51，代表不接受我发送的公钥的指纹，然后我使用命令检查了一下我的私钥派生的公钥 <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">➜ CSDN git:(main) ✗ ssh-keygen -y -f ~/.ssh/id_rsa ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCzNv9/IPwLbklJEJWdCGKPSOb/2ePExmC6/lXN2Zj+4ZcEc3hupGRB0CU736moTlDN0A8DmEHmjRnKybA4yA7uNPYLp3 </code></pre></td></tr></table> </div> </div>居然和linux上面的~/.ssh/authorized_keys里面的内容时一样的，这就很奇怪了。公钥明明正确但不接受。之后去问了一下gemini，gemini建议我检查一下指纹，于是我检查了一下指纹。 <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash"> CSDN git:(main) ✗ ssh-keygen -l -f <(ssh-keygen -yf ~/.ssh/id_rsa ) 3072 SHA256:BrDxupUTSNIgnoX+lIpuOVoqr4K4sqL3LniG4cDImAc jihanfu@jihandeMacBook-Pro.local (RSA) </code></pre></td></tr></table> </div> </div>发现指纹不匹配。BrDxupUTSNIgnoX+lIpuOVoqr4K4sqL3LniG4cDImAc，但我实际发送的是HYJ/2VQ9GbMqG8KZAHfuNlcU+j8qWeQSTi+NEZFR1Tw. 之后再次问了gemini，得到一个可能性，虽然日志里面写的是读取公钥文件 Offering public key: /Users/jihanfu/.ssh/id_rsa. 但实际上读的是/Users/jihanfu/.ssh/id_rsa.pub. 之后检查了一下id_rsa.pub，果然： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">➜ CSDN git:(main) ✗ ssh-keygen -l -f ~/.ssh/id_rsa.pub 3072 SHA256:HYJ/2VQ9GbMqG8KZAHfuNlcU+j8qWeQSTi+NEZFR1Tw jihanfu@jihandeMacBook-Pro.local (RSA) </code></pre></td></tr></table> </div> </div>这里的指纹和发送过去的对的上，所以说ssh的日志本身具有误导性，ssh在有id_rsa.pub的时候会读id_rsa.pub，没有的时候会从id_rsa文件派生。而这个id_rsa.pub文件因为错误配置导致和id_rsa文件匹配不上了。因此删除不一样的id_rsa.pub之后果然即可成功登录。 <hr>本文2026-02-15首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-02-15 </article> <article> <h1>openclaw开启bash命令执行实现RCE</h1> xxx@example.com (catcatyu) — Thu, 12 Feb 2026 21:15:14 +0800 <h1>openclaw开启bash命令执行实现RCE</h1>作者：catcatyu（xxx@example.com） 在渗透测试演习中，一旦入侵了openclaw（如<a href="https://github.com/fjh1997/BruteClaw" target="_blank" rel="noopener noreferrer">爆破token</a> ）之后该怎么远程执行命令呢？其实不用想办法和大模型玩越狱。直接修改这几处即可： 主要修改两处：这里enable 这里不光需要enable还需要设置webchat与通配符 之后使用/bash 命令即可执行程序。 本文仅供安全研究使用，请勿违法使用。 <hr>本文2026-02-12首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-02-12 </article> <article> <h1>office里面你所在的区域不支持Copilot的解决方法</h1> xxx@example.com (catcatyu) — Tue, 10 Feb 2026 00:01:30 +0800 <h1>office里面你所在的区域不支持Copilot的解决方法</h1>作者：catcatyu（xxx@example.com） 最近了一年office 365的<a href="https://www.nodeseek.com/post-589290-1" target="_blank" rel="noopener noreferrer nofollow">羊毛</a> ,想试用copilot的时候遇到这个问题： 梯子开了美国全局tun也没用，之后怀疑是缓存问题，因为一开始没开梯子导致加载了中国区的js文件，所以没法用 用<a href="https://learn.microsoft.com/zh-cn/office/dev/add-ins/testing/clear-cache" target="_blank" rel="noopener noreferrer nofollow">微软官方网站</a> 上的方法试了下清缓存： 删除以下文件夹的内容 <pre tabindex="0"><code>%LOCALAPPDATA%\Microsoft\Office\16.0\Wef\ </code></pre>之后保持美国全局tun重启word即可： 如果还是不行，可以尝试office 365的网页版，也能用Copilot <hr>本文2026-02-10首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-02-10 </article> <article> <h1>解决浙江省专业技术人才管理服务系统出现你的连接不是专用连接或者403Forbidden HTTP Proxy的问题</h1> xxx@example.com (catcatyu) — Fri, 23 Jan 2026 21:13:19 +0800 <h1>解决浙江省专业技术人才管理服务系统出现你的连接不是专用连接或者403Forbidden HTTP Proxy的问题</h1>作者：catcatyu（xxx@example.com） 一开始出现了这样的问题 点击高级之后出现 点进去之后 通过分析网络数据包发现ip地址是： 也就是 [2409:8728:cff:2038::1:2]:443 之后去itdog看了一下 发现只有10.13%解析到这个ip地址 而这些ip地址恰好全是国外DNS解析的。 尝试修改系统的DNS为国内的，无效，之后在浏览器设置里面发现了一个开关： 把这个开关关掉，不使用安全DNS，这样就不会用国外的DNS解析了。毕竟安全DNS和系统内置DNS不一样走的是HTTPS协议，连的国外服务器。 <hr>本文2026-01-23首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-01-23 </article> <article> <h1>记录EPIC-game出现AS-3错误问题的排查</h1> xxx@example.com (catcatyu) — Tue, 13 Jan 2026 21:18:18 +0800 <h1>记录EPIC-game出现AS-3错误问题的排查</h1>作者：catcatyu（xxx@example.com） 登录的时候出现了这个问题，使用雷神加速器还是不行，查看了下日志，发现如下问题： <pre tabindex="0"><code>[2026.01.13-12.05.45:338][ 0]LogOnlineIdentity: OSS: Sending Login request. url=https://account-public-service-prod03.ol.epicgames.com/account, type=refresh, id=[REDACTED] [2026.01.13-12.05.45:349][ 0]LogInit: Using libcurl 7.55.1-DEV [2026.01.13-12.05.45:349][ 0]LogInit: - built for x86_64-pc-win32 [2026.01.13-12.05.45:350][ 0]LogInit: - supports SSL with OpenSSL/1.1.1 [2026.01.13-12.05.45:350][ 0]LogInit: - supports HTTP deflate (compression) using libz 1.2.8 [2026.01.13-12.05.45:350][ 0]LogInit: - other features: [2026.01.13-12.05.45:350][ 0]LogInit: CURL_VERSION_SSL [2026.01.13-12.05.45:350][ 0]LogInit: CURL_VERSION_LIBZ [2026.01.13-12.05.45:350][ 0]LogInit: CURL_VERSION_IPV6 [2026.01.13-12.05.45:350][ 0]LogInit: CURL_VERSION_ASYNCHDNS [2026.01.13-12.05.45:350][ 0]LogInit: CURL_VERSION_LARGEFILE [2026.01.13-12.05.45:350][ 0]LogInit: CURL_VERSION_IDN [2026.01.13-12.05.45:350][ 0]LogInit: CurlRequestOptions (configurable via config and command line): [2026.01.13-12.05.45:350][ 0]LogInit: - bVerifyPeer = true - Libcurl will verify peer certificate [2026.01.13-12.05.45:350][ 0]LogInit: - bUseHttpProxy = true - Libcurl will use HTTP proxy [2026.01.13-12.05.45:350][ 0]LogInit: - HttpProxyAddress = '127.0.0.1:52345' [2026.01.13-12.05.45:350][ 0]LogInit: - bDontReuseConnections = false - Libcurl will reuse connections [2026.01.13-12.05.45:350][ 0]LogInit: - MaxHostConnections = 0 - Libcurl will NOT limit the number of connections to a host [2026.01.13-12.05.45:350][ 0]LogInit: - LocalHostAddr = Default [2026.01.13-12.05.45:350][ 0]LogInit: - BufferSize = 524288 [2026.01.13-12.07.11:083][924]LogOnline: Warning: OSS: https://launcher-public-service-prod06.ol.epicgames.com/launcher/api/public/assets/v2/platform/Windows/launcher?label=Live-HighlandWarrior&clientVersion=17.2.0-38549760%2B%2B%2BPortal%2BRelease-Live-Windows&machineId=44bfe7a8465be3cf51b9abb69b28456a [2026.01.13-12.07.11:083][924]LogOnline: Warning: OSS: Response: [2026.01.13-12.07.11:083][924]LogOnline: Warning: OSS: 连接服务器失败。 [2026.01.13-12.07.11:083][924]LogInit: AllCheckComplete SelfUpdate=0 SignedIn=0 RequiresRestart=0 [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: invalid HTTP response code received. URL: https://account-public-service-prod03.ol.epicgames.com/account/api/oauth/token, HTTP code: 0, content length: 0, actual payload size: 0 [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: request failed, libcurl error: 35 (SSL connect error) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 0 (Found bundle for host account-public-service-prod03.ol.epicgames.com: 0x1d774b4fc40 [serially]) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 1 (Hostname 127.0.0.1 was found in DNS cache) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 2 ( Trying 127.0.0.1...) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 3 (TCP_NODELAY set) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 4 (Connected to 127.0.0.1 (127.0.0.1) port 52345 (#4)) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 5 (allocate connect buffer!) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 6 (Establish HTTP proxy tunnel to account-public-service-prod03.ol.epicgames.com:443) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 7 (Proxy replied OK to CONNECT request) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 8 (CONNECT phase completed!) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 9 (ALPN, offering http/1.1) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 10 (Cipher selection: ALL:!EXPORT:!EXPORT40:!EXPORT56:!aNULL:!LOW:!RC4:@STRENGTH) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 11 (TLSv1.3 (OUT), TLS handshake, Client hello (1):) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 12 (CONNECT phase completed!) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 13 (CONNECT phase completed!) [2026.01.13-12.07.12:820][976]LogHttp: Warning: 000001D76E82EDC0: libcurl info message cache 14 (OpenSSL SSL_connect: SSL_ERROR_SYSCALL in connection to account-public-service-prod03.ol.epicgames.com:443 ) </code></pre>很明显是libcurl走代理了目标地址是127.0.0.1:52345，但是系统里面又没有设置全局的系统代理，之后使用netstat查了一下发现是xray.exe在监听。通过排查发现是v2raya服务启动的，关掉这个之后就能正常连通了，虽然没找到v2raya是在哪里修改libcurl的代理的。 <hr>本文2026-01-13首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-01-13 </article> <article> <h1>迁移csdn到hexo</h1> xxx@example.com (catcatyu) — Mon, 05 Jan 2026 13:26:46 +0800 <h1>迁移csdn到hexo</h1>作者：catcatyu（xxx@example.com） 虽然csdn的markdown编辑器很好用，但是我的部分文章被设置为VIP可见了，背离了我分享知识的初衷，导致我不得不迁移。使用我的脚本即可： <a href="https://github.com/fjh1997/csdn2md" target="_blank" rel="noopener noreferrer">https://github.com/fjh1997/csdn2md</a> 或者其他人的脚本我感觉也不错： <a href="https://github.com/Kalzncc/Csdn2Local" target="_blank" rel="noopener noreferrer nofollow">https://github.com/Kalzncc/Csdn2Local</a> 我的脚本的使用方法是点击编辑文章之后打开开发人员工具在里面把请求包复制到curl 之后使用<a href="https://curlconverter.com/" target="_blank" rel="noopener noreferrer nofollow">curl2python</a> 转换即可，用转换后得到的头修改我的脚本。 <hr>本文2026-01-05首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2026-01-05 </article> <article> <h1>使用wireguard搭建校园网VPN</h1> xxx@example.com (catcatyu) — Wed, 31 Dec 2025 14:52:23 +0800 <h1>使用wireguard搭建校园网VPN</h1>作者：catcatyu（xxx@example.com） 目前遇到两种场景： 逻辑是： 电脑 C （wireguard客户端） ———>服务器 A (wireguard服务端) ———>服务器 B（wireguard linux客户端） ———>校园网内网资源。 电脑 C （wireguard客户端） ———>服务器 A (wireguard服务端) ———>电脑 B（wireguard windows客户端） ———>校园网内网资源。 比如内网网段是 10.0.0.0/8，wireguard网段是10.7.0.0/24 <h2 id="1安装wireguard"> <a class="header-anchor" href="#1%e5%ae%89%e8%a3%85wireguard"></a> 1.安装wireguard </h2><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">wget -O wireguard.sh https://get.vpnsetup.net/wg sudo bash wireguard.sh --auto </code></pre></td></tr></table> </div> </div>生成客户端，一个客户端生成一次，拷贝json文件到客户端参考： <a href="https://github.com/hwdsl2/wireguard-install/blob/master/README-zh.md" target="_blank" rel="noopener noreferrer nofollow">https://github.com/hwdsl2/wireguard-install/blob/master/README-zh.md</a> <h2 id="2配置allow-ip"> <a class="header-anchor" href="#2%e9%85%8d%e7%bd%aeallow-ip"></a> 2.配置allow-ip </h2>给你的所有客户端里面的allowip改为 <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">AllowedIPs = 10.7.0.0/24, 10.0.0.0/8 </code></pre></td></tr></table> </div> </div>给把你的跳板客户端的allowip改为 <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">AllowedIPs = 10.7.0.0/24 </code></pre></td></tr></table> </div> </div>服务端里面，找到你想要作为nat跳板的peer的allowip改为 <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">AllowedIPs = 10.7.0.0/24, 10.0.0.0/8 </code></pre></td></tr></table> </div> </div>表示10.0.0.0/8使用这个节点 <h2 id="场景一设置校园网内linux-nat"> <a class="header-anchor" href="#%e5%9c%ba%e6%99%af%e4%b8%80%e8%ae%be%e7%bd%ae%e6%a0%a1%e5%9b%ad%e7%bd%91%e5%86%85linux-nat"></a> (场景一)设置校园网内Linux Nat </h2>开启内核转发 <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">echo "net.ipv4.ip_forward = 1" | sudo tee -a /etc/sysctl.conf sudo sysctl -p </code></pre></td></tr></table> </div> </div>将客户端配置文件改成如下格式，其中eth0改为你自己的网口 <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">[Interface] Address = 10.7.0.2/24 PrivateKey = [服务器B的私钥] # 核心：开启转发和 NAT，让电脑 C 能访问内网其他机器 PostUp = iptables -A FORWARD -i wg0 -j ACCEPT; iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE PostDown = iptables -D FORWARD -i wg0 -j ACCEPT; iptables -t nat -D POSTROUTING -o eth0 -j MASQUERADE [Peer] PublicKey = [公钥] PresharedKey = [公钥] Endpoint = 221.12.18.205:51820 # 这里设置 VPN 内部全段 AllowedIPs = 10.7.0.0/24 PersistentKeepalive = 25 </code></pre></td></tr></table> </div> </div>之后把文件放到/etc/wireguard/wg0.conf这里使用命令： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">wg-quick up wg0 </code></pre></td></tr></table> </div> </div>启动该配置文件 <h2 id="场景二设置校园网内windows-nat注意不是开启路由转发开启路由转发需要本地路由器支持"> <a class="header-anchor" href="#%e5%9c%ba%e6%99%af%e4%ba%8c%e8%ae%be%e7%bd%ae%e6%a0%a1%e5%9b%ad%e7%bd%91%e5%86%85windows-nat%e6%b3%a8%e6%84%8f%e4%b8%8d%e6%98%af%e5%bc%80%e5%90%af%e8%b7%af%e7%94%b1%e8%bd%ac%e5%8f%91%e5%bc%80%e5%90%af%e8%b7%af%e7%94%b1%e8%bd%ac%e5%8f%91%e9%9c%80%e8%a6%81%e6%9c%ac%e5%9c%b0%e8%b7%af%e7%94%b1%e5%99%a8%e6%94%af%e6%8c%81"></a> (场景二)设置校园网内windows NAT，注意，不是开启路由转发，开启路由转发需要本地路由器支持 </h2><div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 4 5 6 7 8 9 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-powershell" data-lang="powershell"># 首先，找到你要设置的网卡的 InterfaceIndex，例如这里是 wg_server Get-NetAdapter # 给网卡 wg_server 设置 IP 如果没有需要分配ip，因为前面已经有ip了所以不用 # New-NetIPAddress -IPAddress 172.22.0.1 -PrefixLength 24 -InterfaceIndex 68 # 68 是我的 wg_server 的 InterfaceIndex # 添加 NAT # Name: 设置 NAT的名称，随便起，我这里是 wgservernat。 # InternalIPInterfaceAddressPrefix: CIDR New-NetNat -Name wgservernat -InternalIPInterfaceAddressPrefix 10.7.0.0/24 Get-NetNat </code></pre></td></tr></table> </div> </div> 也可以用这个：https://github.com/micahmo/WgServerforWindows 参考：https://kenvix.com/post/setup-nat-on-windows/ <hr>本文2025-12-31首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2025-12-31 </article> <article> <h1>用python模拟的MultiByteToWideChar然后WideCharToMultiByte出错情况</h1> xxx@example.com (catcatyu) — Mon, 20 Oct 2025 21:49:02 +0800 <h1>用python模拟的MultiByteToWideChar然后WideCharToMultiByte出错情况</h1>作者：catcatyu（xxx@example.com） 最近遇到一个CTF题。只有出错了才能够得到flag 原函数这样： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-c" data-lang="c">int __cdecl sub_401D30(LPCCH lpMultiByteStr, int cbMultiByte, int *a3) { int v3; // eax int v4; // ebx WCHAR *lpWideCharStr; // eax WCHAR *v6; // esi int v7; // eax CHAR *v8; // eax int cchWideChar; // [esp+14h] [ebp-28h] int v11; // [esp+28h] [ebp-14h] int v12; // [esp+28h] [ebp-14h] int v13; // [esp+2Ch] [ebp-10h] *a3 = 0; if ( lpMultiByteStr ) { if ( cbMultiByte ) { v3 = MultiByteToWideChar(0xFDE9u, 0, lpMultiByteStr, cbMultiByte, 0, 0); v4 = v3; if ( v3 ) { lpWideCharStr = (WCHAR *)malloc(2 * v3); v6 = lpWideCharStr; if ( lpWideCharStr ) { MultiByteToWideChar(0xFDE9u, 0, lpMultiByteStr, cbMultiByte, lpWideCharStr, v4); v7 = WideCharToMultiByte(0x4E4u, 0, v6, v4, 0, 0, 0, 0); if ( v7 ) { v11 = v7; v8 = (CHAR *)malloc(v7); if ( v8 ) { cchWideChar = v11; v13 = v11; v12 = (int)v8; WideCharToMultiByte(0x4E4u, 0, v6, v4, v8, cchWideChar, 0, 0); free(v6); *a3 = v12; return v13; } } free(v6); } } } } return 0; } </code></pre></td></tr></table> </div> </div>逻辑先是0xFDE9u的MultiByteToWideChar也是cp65001 utf-8到0x4E4u的WideCharToMultiByte也就是cp1252。其中utf-8遇到不认识的字符会转化为�（U+FFFD）然后转化为cp1252会变成\xFD,认识的宽字节字符也会取后面那个字节，如utf-8的 b’\xc2\x9d’ U+009D 变成’\x9d’，utf-8的b’\xc3\xbd’ U+00FD变成’\xFD' 用python模拟的时候废了很大的劲，主要是 <blockquote> UnicodeEncodeError: ‘charmap’ codec can’t encode character ‘\x9d’ in position 0: character maps to <undefined> </blockquote> U+009D 在cp1252里面识别不了解决方法如下： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-python" data-lang="python"># 原始字节序列 data = bytes([ 0x24, 0x59, 0x19, 0xC3, 0xBD, 0xC2, 0xB6, 0xC2, 0x9D, 0x27, 0x43, 0x1D, 0xC3, 0xA8, 0xC2, 0xBE, 0xC5, 0xA0, 0x1D, 0x58, 0x1D, 0xC3, 0x85, 0xC3, 0xBA, 0xC2, 0x8D, 0x7B, 0x56, 0x49, 0xC2, 0xA9, 0xC2, 0xAC, 0xC3, 0x9D, 0x26, 0x50, 0x19, 0xC3, 0xBE, 0xC2, 0xAF, 0xC5, 0xA0, 0x27, 0x53, 0x05 ] ) # C3 BD C2 def utf8_to_latin1_bytes(utf8_data: bytes) -> bytes: """ 将 UTF-8 编码的字节序列转换为 Latin1 单字节表示。 原理： 1. decode('utf-8') 将 UTF-8 解码为 Unicode 字符串 2. encode('latin1') 将 Unicode 字符编码为单字节 Latin1 """ buffer=utf8_data.decode('utf-8',errors='replace') converted=b'' for a in buffer: try: b=a.encode('cp1252', errors='surrogateescape') converted=converted+b print(converted) except UnicodeEncodeError: b=a.encode() converted=converted+b[-1:] return converted # 测试示例 converted = utf8_to_latin1_bytes(data) print("原始:", data.hex()) print("转换后:", converted.hex()) </code></pre></td></tr></table> </div> </div>根据这个帖子：https://bugs.python.org/issue45120 <a href="https://github.com/python/cpython/issues/89283#issuecomment-1093928525" target="_blank" rel="noopener noreferrer nofollow">https://github.com/python/cpython/issues/89283#issuecomment-1093928525</a> <blockquote> WinAPI WideCharToMultiByte() uses a best-fit encoding unless the flag WC_NO_BEST_FIT_CHARS is passed. </blockquote> 用了bestfit1252算法： <a href="https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt" target="_blank" rel="noopener noreferrer nofollow">https://www.unicode.org/Public/MAPPINGS/VENDORS/MICSFT/WindowsBestFit/bestfit1252.txt</a> 也可以这样模拟： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-python" data-lang="python">import codecs # 原始字节序列 data = bytes([ 0x24, 0x59, 0x19, 0xC3, 0xBD, 0xC2, 0xB6, 0xC2, 0x9D, 0x27, 0x43, 0x1D, 0xC3, 0xA8, 0xC2, 0xBE, 0xC5, 0xA0, 0x1D, 0x58, 0x1D, 0xC3, 0x85, 0xC3, 0xBA, 0xC2, 0x8D, 0x7B, 0x56, 0x49, 0xC2, 0xA9, 0xC2, 0xAC, 0xC3, 0x9D, 0x26, 0x50, 0x19, 0xC3, 0xBE, 0xC2, 0xAF, 0xC5, 0xA0, 0x27, 0x53, 0x05 ] ) # C3 BD C2 def utf8_to_latin1_bytes(utf8_data: bytes) -> bytes: """ 将 UTF-8 编码的字节序列转换为 Latin1 单字节表示。 原理： 1. decode('utf-8') 将 UTF-8 解码为 Unicode 字符串 2. codecs.code_page_encode 将unicode编码为cp1252字节 """ buffer=utf8_data.decode('utf-8',errors='replace') converted=codecs.code_page_encode(1252, buffer, 'replace')[0] return converted # 测试示例 converted = utf8_to_latin1_bytes(data) print("原始:", data.hex()) print("转换后:", converted.hex()) </code></pre></td></tr></table> </div> </div> <hr>本文2025-10-20首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2025-10-20 </article> <article> <h1>阿里云服务器单位网络连不上ssh，但ping的通，手机热点却连得上的解决方法</h1> xxx@example.com (catcatyu) — Wed, 17 Sep 2025 14:18:26 +0800 <h1>阿里云服务器单位网络连不上ssh，但ping的通，手机热点却连得上的解决方法</h1>作者：catcatyu（xxx@example.com） ssh数据包被reset了。抓包发现rst数据包的ttl和【syn，ack】的ttl数据包值相同。应该是阿里那边拦截了。 首先，单位可能有多个出口ip。要双向抓包。服务端和客户端用wireshark抓包。发现真实的出口ip。 之后去登录阿里云云盾安全管控平台管理控制台（https://yundun.console.aliyun.com/?spm=a2c4g.11186623.0.0.769d8da5JMVb3I&p=sc）。在左侧导航栏，单击白名单管理 > IP白名单。单击添加单位的出口ip即可。一开始添加无效，原因是通过查询cip.cc得到的ip不一定是访问阿里云的出口ip. <hr>本文2025-09-17首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2025-09-17 </article> <article> <h1>starting container process caused: exec: “catalina.sh“: executable file not found in $PATH: unknown</h1> xxx@example.com (catcatyu) — Tue, 16 Sep 2025 20:41:22 +0800 <h1>starting container process caused: exec: “catalina.sh“: executable file not found in $PATH: unknown</h1>作者：catcatyu（xxx@example.com） 报错为： docker: Error response from daemon: OCI runtime create failed: container_linux.go:367: starting container process caused: exec: “catalina.sh”: executable file not found in $PATH: unknown. 文件目录如下： . ├── 01.png ├── catalina.sh ├── context.xml ├── docker-compose.yml ├── Dockerfile ├── README.zh-cn.md └── tomcat-users.xml 其中Dockerfile如下： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">FROM vulhub/tomcat:8.5.19 LABEL maintainer="phithon <root@leavesongs.com>" RUN cd /usr/local/tomcat/conf \ && LINE=$(nl -ba web.xml | grep '<load-on-startup>1' | awk '{print $1}') \ && ADDON="<init-param><param-name>readonly</param-name><param-value>false</param-value></init-param>" \ && sed -i "$LINE i $ADDON" web.xml COPY tomcat-users.xml /usr/local/tomcat/conf/tomcat-users.xml COPY context.xml /usr/local/tomcat/webapps/manager/META-INF/context.xml COPY catalina.sh /usr/local/tomcat/bin/catalina.sh </code></pre></td></tr></table> </div> </div>通过检查发现catalina.sh的权限为-rw-rw-rw-，这就导致Dockerfile复制进去之后保留了-rw-rw-rw-权限，其中缺少x权限导致终端无法识别catalina.sh命令。所以修复方法为： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 3 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">chmod +x catalina.sh docker compose build --no-cache docker compose up -d </code></pre></td></tr></table> </div> </div>或者在Dockerfile里面配置： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">COPY catalina.sh /usr/local/tomcat/bin/catalina.sh RUN chmod +x catalina.sh </code></pre></td></tr></table> </div> </div> <hr>本文2025-09-16首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2025-09-16 </article> <article> <h1>新版frps配置文件toml配置多个端口的方法</h1> xxx@example.com (catcatyu) — Tue, 06 May 2025 14:00:54 +0800 <h1>新版frps配置文件toml配置多个端口的方法</h1>作者：catcatyu（xxx@example.com） 根据<a href="https://github.com/fatedier/frp/blob/6cbb26283c3931766216968975c06e03a58a0941/conf/frpc_full_example.toml" target="_blank" rel="noopener noreferrer nofollow">官方配置文档</a> ，方法为加入多个[[proxies]],如： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">serverAddr = "X.X.X.X" serverPort = 7000 [[proxies]] name = "test-tcp" type = "tcp" localIP = "127.0.0.1" localPort = 22 remotePort = 6000 [[proxies]] name="tkctf" type = "tcp" localIP = "127.0.0.1" localPort = 80 remotePort = 80 </code></pre></td></tr></table> </div> </div>警告⚠，frp确实很方便但同时也强烈建议frps配置一下auth-token，不然非常不安全！！！！！！！！！！！！！！！！！ <blockquote> auth.method = “token” auth.token = “12345678” </blockquote> <hr>本文2025-05-06首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2025-05-06 </article> <article> <h1>docker开放端口出现 curl: (56) Recv failure: Connection reset by peer的原因之一</h1> xxx@example.com (catcatyu) — Wed, 29 Jan 2025 01:21:58 +0800 <h1>docker开放端口出现 curl: (56) Recv failure: Connection reset by peer的原因之一</h1>作者：catcatyu（xxx@example.com） docker容器内部服务监听地址为127.0.0.1会出现这种情况，解决方法就是监听到0.0.0.0。 <hr>本文2025-01-29首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2025-01-29 </article> <article> <h1>记一次root无法登录的情况</h1> xxx@example.com (catcatyu) — Wed, 11 Dec 2024 16:48:14 +0800 <h1>记一次root无法登录的情况</h1>作者：catcatyu（xxx@example.com） grub里面改了密码也没用，于是关闭quiet开启日志，结果发现/etc/passwd被selinux拦截了，于是去/etc/selinux/config里面关闭即可。类似这样的错误： audit(1733934483.186:122):avc: denied { open } for pid=814 comme=“dbus-dae mon="/etc/passwd” dev=“dm-0"ino=20088836 scontext=system_u:system r:system_dbusd_t:s0-s0:c1023 tcontext=system_u:object _r:unlabeled_t:s0 tclass=file permissive=8 经过排查，selinux设置错误，正常的是 <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 2 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">$ ls -Z /etc/passwd system_u:object_r:passwd_file_t:s0 /etc/passwd </code></pre></td></tr></table> </div> </div>结果变成他变成system_u:object_r:unlabeled_t:s0 /etc/passwd，ext4扩展属性出现问题 /var/log/secure里面可以看到报错日志：结合unix_chkpwd的selinux属性chkpwd_exec_t 可能由于passwd_file_t标签丢失导致 <hr>本文2024-12-11首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2024-12-11 </article> <article> <h1>teec_initializecontext failed with code 0xffff0008</h1> xxx@example.com (catcatyu) — Thu, 28 Nov 2024 09:40:58 +0800 <h1>teec_initializecontext failed with code 0xffff0008</h1>作者：catcatyu（xxx@example.com） 需要用root运行 <hr>本文2024-11-28首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2024-11-28 </article> <article> <h1>FTP卡在150 Opening ASCII mode data connection”的解决方法</h1> xxx@example.com (catcatyu) — Tue, 19 Nov 2024 20:40:11 +0800 <h1>FTP卡在150 Opening ASCII mode data connection”的解决方法</h1>作者：catcatyu（xxx@example.com） 防火墙都已经开了，但是依然有问题，发现是hyper-v动态端口占用了，设置下即可： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-powershell" data-lang="powershell">netsh int ipv4 set dynamicport tcp 49152 16383 persistent </code></pre></td></tr></table> </div> </div> <hr>本文2024-11-19首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2024-11-19 </article> <article> <h1>解决银河麒麟os上steam++无法启动加速的问题</h1> xxx@example.com (catcatyu) — Tue, 12 Nov 2024 19:38:07 +0800 <h1>解决银河麒麟os上steam++无法启动加速的问题</h1>作者：catcatyu（xxx@example.com） 使用steam++加速github，点启动加速会提示/etc/hosts权限问题，修改了权限之后无效，提示无法写入，换做nano手动写入的时候却可以，经过研究，发现strace的openat系统调用参数一致，但是steam++的却提示无法打开写入，权限不足，猜测是系统内核里面有审计系统，毕竟是信创系统嘛。经过查询，发现确实有一个类似的审计系统kysec，大概是实现了selinux的强制访问原则，于是查资料关闭kysec即可 <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">setstatus softmode -p </code></pre></td></tr></table> </div> </div>安全中心里面也尽可能关闭。如果用自带的奇安信浏览器github提示证书错误，还需要去浏览器设置里面添加信任证书。 <hr>本文2024-11-12首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2024-11-12 </article> <article> <h1>如何挂载容器内的非空目录到宿主机，避免覆盖</h1> xxx@example.com (catcatyu) — Thu, 24 Oct 2024 15:23:50 +0800 <h1>如何挂载容器内的非空目录到宿主机，避免覆盖</h1>作者：catcatyu（xxx@example.com） 一般的docker挂载是需要使用宿主机内的一个目录挂载到容器里面，但是这样会出现一个问题，就是宿主机目录内的文件会覆盖到容器里面的那个目录，如果这个目录是空的，那么容器里面的目录也会被覆盖为空，导致一些异常，之后在网上找到了一个方法： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-yaml" data-lang="yaml">version: '2' services: tomcat: build: . ports: - "8080:8080" - "5005:5005" volumes: - tomcat:/usr/local/tomcat volumes: tomcat: driver: local driver_opts: type: none device: /root/tomcat o: bind </code></pre></td></tr></table> </div> </div>其中/root/tomcat可以修改为你要映射的路径来源：https://stackoverflow.com/a/53200495/10096812 <hr>本文2024-10-24首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2024-10-24 </article> <article> <h1>通过markdown表格批量生成格式化的word教学单元设计表格</h1> xxx@example.com (catcatyu) — Fri, 20 Sep 2024 00:21:02 +0800 <h1>通过markdown表格批量生成格式化的word教学单元设计表格</h1>作者：catcatyu（xxx@example.com） 素材：模板：代码： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-python" data-lang="python">import pandas as pd from python_docx_replace import docx_replace,docx_get_keys from docx import Document from docxcompose.composer import Composer def parse_markdown_tables(file_path): with open(file_path, 'r', encoding='utf-8') as file: lines = file.readlines() current_table = [] for line in lines: current_table.append(line.strip().replace(' ', '\n').split('|')[1:-1]) df = pd.DataFrame(current_table[1:], columns=current_table[0]) return df df=parse_markdown_tables("单元设计.md") def convert(num,df): print(num) doc = Document("template.docx") # keys = docx_get_keys(doc) # Let's suppose the Word document has the keys: ${name} and ${phone} # print(keys) #['name', 'week', 'problem', 'location', 'test', 'obj', 'book', 'date', 'seq', 'homework', 'review', 'goal'] docx_replace(doc, book=df.iloc[num].tolist()[8].strip(), week=df.iloc[num].tolist()[0].strip(), problem=df.iloc[num].tolist()[6].strip(), review=df.iloc[num].tolist()[11].strip(), name=df.iloc[num].tolist()[3].strip(), location=df.iloc[num].tolist()[7].strip(), date=df.iloc[num].tolist()[1].strip(), homework=df.iloc[num].tolist()[10].strip(), seq=df.iloc[num].tolist()[2].strip(), test=df.iloc[num].tolist()[9].strip(), obj=df.iloc[num].tolist()[4].strip(), goal=df.iloc[num].tolist()[5].strip()) return doc master = Document("master.docx")# 任意word文档，里面可以包含封面 composer = Composer(master) for i in range(len(df.axes[0])): unit_doc=convert(i,df) composer.append(unit_doc) composer.save("combined.docx") </code></pre></td></tr></table> </div> </div>效果，16张表： 项目地址：https://github.com/fjh1997/Unit <hr>本文2024-09-20首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2024-09-20 </article> <article> <h1>Fine3399或rk3399\sw799刷armbian创建热点</h1> xxx@example.com (catcatyu) — Wed, 04 Sep 2024 22:55:01 +0800 <h1>Fine3399或rk3399\sw799刷armbian创建热点</h1>作者：catcatyu（xxx@example.com） <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">sudo bash #切换root sudo apt install -y hostapd isc-dhcp-server ifupdown # 配置 hostapd sudo nano /etc/hostapd/hostapd.conf interface=wlan0 driver=nl80211 ssid=hostspot-name macaddr_acl=0 auth_algs=1 #auth_algs=3 ignore_broadcast_ssid=0 hw_mode=bgn channel=6 wpa=2 wpa_passphrase=password wpa_key_mgmt=WPA-PSK wpa_pairwise=CCMP #wpa_pairwise=TKIP #rsn_pairwise=CCMP # 修改 hostapd 默认配置文件路径 sudo nano /etc/default/hostapd DAEMON_CONF=/etc/hostapd/hostapd.conf # 重启 hostapd sudo service hostapd restart sudo service hostapd status # dhcp 配置 sudo nano /etc/dhcp/dhcpd.conf #option domain-name "example.org"; #option domain-name-servers ns1.example.org, ns2.example.org; authoritative; subnet 10.0.0.0 netmask 255.255.255.0 { range 10.0.0.10 10.0.0.200; option broadcast-address 10.0.0.255; option routers 10.0.0.1; default-lease-time 600; max-lease-time 7200; option domain-name "local"; option domain-name-servers 223.5.5.5, 8.8.4.4; } # 设置 dhcp 网口 # 不进行操作会出现错误：Not configured to listen on any interfaces! sudo nano /etc/default/isc-dhcp-server INTERFACESv4="wlan0" INTERFACESv6="wlan0" # 设置 wlan0 地址 # 不进行操作会出现错误：Not configured to listen on any interfaces! sudo ip addr add 10.0.0.1/24 dev wlan0 # 设置开机自动设置 mkdir /etc/network/interfaces.d/ echo -e "# armbian NAT hostapd\nallow-hotplug wlan0\niface wlan0 inet static\n \taddress 10.0.0.1\n\tnetmask 255.255.255.0\n\tnetwork 10.0.0.0\n\tbroadcast 10.0.0.255" > /etc/network/interfaces.d/armbian.ap.nat # 开启转发 sudo sysctl -w net.ipv4.ip_forward=1 sudo iptables -t nat -A POSTROUTING -s 10.0.0.1/24 -o eth0 -j MASQUERADE sudo iptables -A FORWARD -i eth0 -o wlan0 -m state --state RELATED,ESTABLISHED -j ACCEPT sudo iptables -A FORWARD -i wlan0 -o eth0 -j ACCEPT #设置开机启动自动设置 sudo iptables-save > /etc/iptables.ipv4.nat cat <<-EOF > /etc/systemd/system/armbian-restore-iptables.service [Unit] Description="Restore IP tables" [Timer] OnBootSec=20Sec [Service] Type=oneshot ExecStart=/sbin/iptables-restore /etc/iptables.ipv4.nat [Install] WantedBy=sysinit.target EOF systemctl enable armbian-restore-iptables.service # 启动 dhcp 服务 systemctl enable isc-dhcp-server systemctl start isc-dhcp-server </code></pre></td></tr></table> </div> </div>参考：https://gitee.com/xiayang0521/rk3399 <hr>本文2024-09-04首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2024-09-04 </article> <article> <h1>解决windterm莫名其妙输入ctrl+c的问题</h1> xxx@example.com (catcatyu) — Mon, 02 Sep 2024 21:50:32 +0800 <h1>解决windterm莫名其妙输入ctrl+c的问题</h1>作者：catcatyu（xxx@example.com） 原来是钉钉在监控你的鼠标，取消设置即可 来源：https://github.com/kingToolbox/WindTerm/issues/2296 <hr>本文2024-09-02首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2024-09-02 </article> <article> <h1>如何从mssql里面导出程序集ASSEMBLY为dll</h1> xxx@example.com (catcatyu) — Mon, 02 Sep 2024 19:22:01 +0800 <h1>如何从mssql里面导出程序集ASSEMBLY为dll</h1>作者：catcatyu（xxx@example.com） 前段时间服务器被黑客入侵了，发现黑客注入的sql语句是创建了一个程序集ASSEMBLY <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-sql" data-lang="sql">CREATE ASSEMBLY [SweetShellcodeclr35]AUTHORIZATION [dbo] FROM 0xFF……FFFFF WITH PERMISSION_SET = UNSAFE; </code></pre></td></tr></table> </div> </div>，但是光凭sql语句无法逆向，之后在stackoverflow找到了一个方法导出程序集为dll文件的方法：首先查出程序集的编号： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-sql" data-lang="sql"> select * from sys.assembly_files </code></pre></td></tr></table> </div> </div>之后使用以下方法设置assembly_id 导出 <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code> 1 2 3 4 5 6 7 8 9 10 11 12 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-sql" data-lang="sql">DECLARE @IMG_PATH VARBINARY(MAX) DECLARE @ObjectToken INT SELECT @IMG_PATH = content FROM sys.assembly_files WHERE assembly_id = 65536 EXEC sp_OACreate 'ADODB.Stream', @ObjectToken OUTPUT EXEC sp_OASetProperty @ObjectToken, 'Type', 1 EXEC sp_OAMethod @ObjectToken, 'Open' EXEC sp_OAMethod @ObjectToken, 'Write', NULL, @IMG_PATH EXEC sp_OAMethod @ObjectToken, 'SaveToFile', NULL, 'c:\temp\myassembly.dll', 2 EXEC sp_OAMethod @ObjectToken, 'Close' EXEC sp_OADestroy @ObjectToken </code></pre></td></tr></table> </div> </div>有人问为什么我会去找这个方法，直接16进制转化为dll不就行了，原因是我之前用mysql转化的时候出错了。之后发现不能直接16进制转化为dll的原因是我是使用mysql转化的，而mysql里面<code>select 0x20 into outfile</code>和<code> select 0x20 into dumpfile</code>是不一样的，如果是outfile会重新编码，而dumpfile则不用。所以其实直接去掉0x然后16进制转化也是可以的。 参考：https://stackoverflow.com/questions/4103406/extracting-a-net-assembly-from-sql-server-2005 <hr>本文2024-09-02首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2024-09-02 </article> <article> <h1>SW799刷armbian之后一段时间自动关机的解决方法</h1> xxx@example.com (catcatyu) — Thu, 29 Aug 2024 12:50:39 +0800 <h1>SW799刷armbian之后一段时间自动关机的解决方法</h1>作者：catcatyu（xxx@example.com） 主要原因是进入了休眠模式：使用以下命令关闭休眠即可： <div class="highlight"><div class="chroma"> <table class="lntable"><tr><td class="lntd"> <pre tabindex="0" class="chroma"><code>1 </code></pre></td> <td class="lntd"> <pre tabindex="0" class="chroma"><code class="language-bash" data-lang="bash">sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target </code></pre></td></tr></table> </div> </div> <hr>本文2024-08-29首发于<a href='https://csdn.fjh1997.top/'>猫猫鱼的小窝</a>，最后修改于2024-08-29 </article> </main></body></html>