gtAdmin/StudyDiary-20261009
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

commit all

Browse Source
This commit is contained in:
CrazyJasonwell
2026-10-09 22:06:40 +08:00
commit e97be9ac8c
2062 changed files with 2438686 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

158
02-学习笔记/Tips/Linux 排查Java进程内存过高完整方法.md Executable file
View File

@@ -0,0 +1,158 @@
# Linux 排查Java进程内存过高完整方法
# Linux 排查 Java 进程内存过高完整方法
## 一、先找到占用高内存的 Java 进程
### 方式 1：top（最常用，实时查看）
```bash
top
```
- 按 `M` 大写 M：**按内存占用降序排序**
- 找到 `COMMAND` 列是 `java` 的行，记下 PID（第一列数字）
### 方式 2：htop（更友好，需要安装）
```bash
htop
```
### 方式 3：ps 一次性列出所有 java 进程，看 RSS \(物理内存\)
```bash
ps -ef | grep java
# 带内存占用版本
ps aux | grep java
```
> 字段说明：`%MEM` 内存占比，`RSS` 实际物理内存（单位 KB）
>
>
### 方式 4：只看 java 进程，排序内存
```bash
ps aux | grep -E 'java' | grep -v grep | sort -k4 -nr
```
---
## 二、拿到 PID 后，查看 JVM 内部内存情况（JDK 自带工具）
> ⚠️ 前提：运行 java 的用户和执行 jps/jstat/jmap 的用户一致，否则会权限失败
>
>
### 1\. jps 快速列出所有 Java 进程 \+ PID
```bash
jps -l
```
`-l`：打印完整主类名，方便区分是哪个 Java 应用
### 2\. jstat 持续监控 JVM 堆内存变化（判断是否内存泄漏）
```bash
# 每1秒输出一次，持续观察，PID替换成你的java进程号
jstat -gc <PID> 1000
```
重点看这几列：
- `S0C,S1C`：Survivor 区容量
- `EC,OC`：Eden、Old 老年代容量
- `OU`：Old 区已使用大小
> 如果 **OU 持续上涨，Full GC 频繁但内存释放很少 → 大概率内存泄漏**
>
>
### 3\. jmap 查看堆内存快照（dump 内存文件，事后分析）
```bash
# 生成堆dump文件（会短暂STW，生产环境谨慎操作）
jmap -dump:format=b,file=heapdump.hprof <PID>
```
得到 `heapdump.hprof` 文件，可以下载到本地，用 **MAT\(Memory Analyzer Tool\)** 分析，定位是哪个对象占用大量内存。
查看堆内存概况（不用生成文件）：
```bash
jmap -heap <PID>
```
输出 JVM 堆配置：新生代、老年代大小，GC 收集器类型。
查看对象统计：
```bash
jmap -histo <PID>
```
列出所有类实例数量、占用内存，找出占用最多的类。
### 4\. jstack 查看线程栈（排查是否线程堆积间接导致内存暴涨）
```bash
jstack <PID>
```
用来查找死锁、大量等待线程。
---
## 三、查看进程级详细内存（Linux 系统层面，区分 JVM 堆 / 非堆）
```bash
# 查看进程smaps，详细内存分布
cat /proc/<PID>/smaps
```
或者用 `pmap`
```bash
pmap -x <PID>
```
可以看到：堆内存、栈、共享库占用。
## 四、快速排查思路总结
1. `top` / `ps aux` → 确认是 Java 进程占用高，拿到 PID
2. `jstat -gc PID 1000` → 观察 GC 行为，判断是内存泄漏还是堆配置太小
3. `jmap -heap PID` → 看 JVM 堆参数是否合理（Xmx/Xms）
4. `jmap -dump` 导出堆快照，MAT 分析定位泄漏对象
5. `jstack` 辅助排查线程问题
## 五、常见原因
1. **内存泄漏**：代码创建对象没有释放（集合持续 add 不清理）
2. JVM 参数不合理：`-Xmx` 设置太大，吃掉大量宿主机内存
3. 堆外内存（DirectBuffer）占用：jmap 看不到堆外内存，需要额外排查
4. 并发请求过高，正常业务内存开销
## 六、小提示
- 如果是容器环境（docker），`top`看到的是容器内视图，宿主机需要额外查看
- dump 堆文件会占用磁盘空间，hprof 文件体积可能很大
- 如果 JDK 是精简版（没有自带 jmap/jstat），需要安装完整 JDK 或者使用`arthas`（阿里开源 Java 诊断工具）
如果你需要，我可以给你一份 **Arthas 一键排查命令集**，不需要依赖 JDK 自带工具。
> （注：部分内容由豆包工作 AI 生成）

305
02-学习笔记/Tips/OpenWrt单网口旁路由 + 群晖qBittorrent 综合配置手册.md Executable file
View File

@@ -0,0 +1,305 @@
# OpenWrt单网口旁路由 \+ 群晖qBittorrent 综合配置手册
# OpenWrt 单网口旁路由 \+ 群晖 qBittorrent 综合配置手册
> 复制下面全部内容，粘贴到记事本，文件另存为：`OpenWrt_群晖QB配置手册.md`，编码选择 **UTF\-8**
>
>
```markdown
# OpenWrt单网口旁路由 + 群晖qBittorrent 综合配置手册
## 模块一 OpenWrt单网口旁路由（关闭DHCP+彻底关闭DNS劫持）
### 一、适用场景
- 设备：单网口软路由、无独立WAN口、单口复用
- 模式：纯旁路由模式，**主路由负责拨号、PPPoE、DHCP分配IP**
- 需求：关闭OpenWrt DHCP、关闭DNS 53端口劫持，不篡改终端DNS请求
- 核心原则：**全程不新建、不配置WAN接口**，防止单网口断后台
### 二、前置风险提示
1. OpenWrt关闭DHCP后，内网设备无法自动获取IP，IP分配全部交给上层主路由DHCP。
2. 单网口设备不要随意修改接口、新建WAN，极易丢失后台访问。
3. DNS劫持来源两类：防火墙53端口DNAT规则 / AdGuardHome/SmartDNS等插件强制拦截DNS。
### 三、核心配置步骤（LuCI图形界面 + SSH）
#### 步骤1 LAN接口基础配置（旁路由核心）
网络 → 接口 → LAN → 编辑
1. 常规设置
- IPv4地址：同网段静态IP（例：主路由`192.168.1.1`，旁路由`192.168.1.2`，避免IP冲突）
- 子网掩码：`255.255.255.0`
- IPv4网关：填写**主路由IP**
- DNS服务器：填写**主路由IP**
2. DHCP服务器选项卡：勾选【忽略此接口】，关闭LAN口DHCP分发
3. 物理设置：单网口建议拆除多余桥接，仅绑定eth0
保存&应用。
#### 步骤2 SSH命令永久关闭DHCP
```bash
uci set dhcp.lan.ignore="1"
uci commit dhcp
/etc/init.d/dnsmasq restart
```
校验命令：
```bash
uci show dhcp.lan
```
输出含 `dhcp.lan.ignore='1'` 代表 DHCP 关闭成功。
#### 步骤 3 清除 DNS 劫持
1. 图形界面：网络 → 防火墙 → 端口转发，**删除所有目标端口 53 的 DNAT 规则**，保存应用。
2. SSH 查看 53 端口劫持规则：
```bash
iptables -t nat -L PREROUTING --line-numbers | grep dpt:53
```
删除规则（行号替换为你查到的数字）
```bash
iptables -t nat -D PREROUTING 1
```
重复执行直到无输出。
3\. 插件设置（AdGuardHome / SmartDNS）：关闭「拦截 53 端口、强制劫持 DNS」。
#### 步骤 4 防火墙必要设置
网络 → 防火墙
- LAN 区域转发：接受
- **开启 IP 动态伪装（MASQ）**，否则流量无法转发
- 不新增 WAN 区域
### 四、DNS 劫持有效性测试
Windows CMD 执行（设备网关设旁路由 IP，DNS 手动填 \[223\.5\.5\.5\]\(223\.5\.5\.5\)）
```cmd
nslookup baidu.com 223.5.5.5
```
✅正常：服务器 =`223.5.5.5`
❌劫持：服务器显示旁路由内网 IP
OpenWrt 内 SSH 测试：
```bash
nslookup baidu.com 223.5.5.5
```
### 五、核对清单
* [ ] LAN DHCP 已忽略关闭
* [ ] 防火墙无 53 端口 DNAT 劫持规则
* [ ] DNS 插件劫持关闭
* [ ] LAN 防火墙 MASQ 开启
* [ ] 没有新建 WAN 接口
---
## 模块二 群晖 NAS qBittorrent 配置（Docker 部署）
> 环境：群晖 DSM，Docker 安装 qBittorrent，配合旁路由做流量出口，配套目录权限、文件整理、防踩坑设置
>
>
### 一、前置准备
1. 群晖存储空间：新建共享文件夹，示例命名`qb-download`
- 子目录建议：`incomplete`（临时未完成）、`complete`（完成文件）
2. 权限：给 Docker 的 qb 容器读写权限，**不要用 root 直接跑**，设置 PUID/PGID（群晖用户 UID）
3. 网络模式：推荐`bridge`桥接模式；如需走旁路由，容器网关指定为 OpenWrt 旁路由 IP。
### 二、Docker 容器环境变量（常用模板）
```Plain Text
PUID=1026
PGID=100
TZ=Asia/Shanghai
WEBUI_PORT=8080
```
端口映射：
- 8080:8080 Web 管理面板
- 50681:50681/TCP\+UDP BT 监听端口（自行选用）
挂载目录：
- `/volume1/qb-download/complete` → `/downloads`
- `/volume1/qb-download/incomplete` → `/incomplete`
- `/volume1/docker/qb/config` → `/config`
### 三、qBittorrent WebUI 核心参数配置
打开 WebUI → 选项
1. **连接**
- 监听端口固定，启用 UPnP/NAT\-PMP（有公网 IP 推荐开启）
- 限制全局连接数，防止占满内网带宽
2. **下载**
- ✅ 启用：未完成文件保存到单独目录（incomplete）
- 完成后自动移动到`complete`目录
- 预分配磁盘空间：按需开启（大文件推荐）
3. **BitTorrent**
- DHT、PEX、本地对等发现：按需开启（私种关闭 DHT/PEX）
4. **高级**
- 不要开启不必要的代理；如需走旁路由，**全局网关在 Docker 层面设置，不要在 qb 内单独配置代理**
### 四、配套：文件名清理 / 刮削脚本（Tinymediamanager）
> 需求：自动清理文件名特殊字符、目录监听、媒体库刮削
>
>
1. TinyMediaManager 用于媒体元数据刮削，自动匹配电影 / 剧集海报、简介
2. 文件名清洗脚本：正则过滤特殊符号，清理种子下载带来的杂乱文件名，避免 Emby/Jellyfin 识别失败
3. 注意：脚本运行用户 UID 必须和 qb 下载文件 UID 一致，防止权限报错。
### 五、权限 \& 避坑重点
1. 权限大坑：qb 下载文件归属 PUID 用户，**群晖文件管理器看不到 / 无法删除，就是 PUID 不匹配**
2. 旁路由联动：
- 群晖本身网关可保留主路由；仅 Docker 容器单独指定网关走 OpenWrt 旁路由
- 注意：DNS 设置，群晖 / 容器 DNS 不要被劫持，使用公共 DNS（\[223\.5\.5\.5\]\(223\.5\.5\.5\)）
3. 端口：群晖防火墙放行 qb 监听端口；路由器端口映射（有公网 IP）
4. 硬盘：开启 SSD 缓存，大流量下载注意硬盘休眠策略，避免频繁启停损坏硬盘
### 六、备份建议
1. qBittorrent：备份 `/config` 整个目录（包含配置、种子列表）
2. 定期导出 torrent 种子文件做异地备份
---
## 附录 A：故障排查小节
### 1\. qBittorrent 无速度 / Tracker 连接失败
1. DNS 问题：容器内 DNS 被劫持。在 Docker 容器配置内手动指定 DNS 为`223.5.5.5`，不要自动获取。
2. 端口不通：
- 检查群晖防火墙放行 BT 监听端口 TCP/UDP
- 公网环境：主路由端口映射，确认 UPnP 正常
3. 私种站点：关闭 DHT、PEX；核对站点密钥、passkey，检查种子是否过期
4. 网关错误：容器网关没有正确指向旁路由 IP；检查 OpenWrt 防火墙 MASQ 是否开启
### 2\. 群晖文件权限报错（无法删除、看不到文件）
- 根源：PUID/PGID 和群晖本地用户 ID 不一致
- 解决：在容器环境变量修改 PUID，与你群晖登录用户 UID 保持一致；重建容器，不要直接修改已下载文件权限。
> 获取群晖 UID：SSH 登录群晖，执行 `id 你的用户名`
>
>
### 3\. OpenWrt 旁路由故障
1. 无法访问 OpenWrt 后台：检查电脑 IP 网段；单网口不要新建 WAN，修改 LAN IP 后需要用新 IP 访问
2. 设备网关指向旁路由但无法上网：LAN 区域 IP 动态伪装 \(MASQ\) 未开启；检查主路由与旁路由网段一致
3. DNS 劫持复现：重启防火墙后 53 端口 DNAT 规则恢复，回到 LuCI 防火墙端口转发页面删除持久化规则；检查 AdGuardHome/SmartDNS 插件劫持开关
### 4\. TinyMediaManager 刮削识别失败
1. 文件名残留特殊符号，正则清洗脚本未执行，媒体库无法识别剧集 / 电影
2. 文件权限：脚本运行用户没有读取 complete 目录权限
3. 网络：TMM 的 DNS 被劫持，无法访问元数据站点，使用公共 DNS
## 附录 B：定期自动备份脚本（群晖任务计划程序）
> 用途：自动备份 qb 的 config 目录和种子，保存到群晖另一存储目录，可设置定时任务（每日凌晨执行）
> 使用方法：群晖控制面板 → 任务计划程序 → 新增【用户定义的脚本】，填入下面脚本，修改路径为你实际路径
>
>
```bash
#!/bin/bash
# qBittorrent配置备份脚本
BACKUP_SRC="/volume1/docker/qb/config"
BACKUP_DST="/volume1/backup/qb_backup"
TMP_NAME="qb_backup_$(date +%Y%m%d_%H%M%S).tar.gz"
# 创建备份目录
mkdir -p ${BACKUP_DST}
# 打包备份
tar -zcf ${BACKUP_DST}/${TMP_NAME} ${BACKUP_SRC}
# 保留最近7天备份，删除旧备份
find ${BACKUP_DST} -name "qb_backup_*.tar.gz" -mtime +7 -delete
```
> 注意事项：
>
> 1. 修改脚本内路径为你真实的存储路径
>
> 2. 任务运行用户选择和 qb 相同 UID 的用户，避免权限报错
>
> 3. 建议备份目录放在不同硬盘 / 存储池，防止单盘损坏丢失
>
>
## 附录 C：整体网络拓扑
```Plain Text
光猫 → 主路由（拨号+DHCP）
↓
├─ 群晖NAS（Docker qBittorrent）
└─ 单网口OpenWrt旁路由（不拨号、无WAN，关闭DHCP+关闭DNS劫持）
```
```Plain Text
## 📝 保存操作步骤
1. 全选上面所有文本，复制
2. 电脑桌面右键 → 新建 → 文本文档
3. 粘贴内容进去
4. 文件 → 另存为
- 文件名：`OpenWrt_群晖QB配置手册.md`
- 编码：**UTF-8**
5. 保存完成，可用Typora、VS Code等软件打开查看。
如果你后续还要新增其他配置（比如飞牛OS、Audiobookshelf），我可以继续追加到这份文档里。
```
> （注：部分内容由豆包工作 AI 生成）

BIN
02-学习笔记/Tips/单网口OpenWrt旁路由OpenClash redir-host完整配置文档（含自检清单）.docx Executable file
View File

Binary file not shown.

179
02-学习笔记/Tips/单网口OpenWrt旁路由OpenClash redir-host完整配置文档（含自检清单）.md Executable file
View File

@@ -0,0 +1,179 @@
# 单网口OpenWrt旁路由OpenClash redir\-host完整配置文档（含自检清单）
## 文档说明
**适用场景**：单网口OpenWrt软路由作为旁路由，搭配OpenClash redir\-host模式，实现**按需代理**。仅手动修改网关的设备走代理，全屋其余设备、群晖NAS、qBittorrent均直连主路由，不受软路由干扰。
**设备环境**：
- 主路由：192\.168\.1\.1（全屋默认网关）
- 软路由：单网口OpenWrt、fw4\(nftables\)防火墙、OpenClash核心
- 业务设备：群晖NAS \+ Docker qBittorrent
**核心目标**：彻底关闭全局ARP劫持，解决全网卡顿；采用redir\-host精准分流，兼顾代理需求与内网稳定性，BT下载流量纯净直连。
## 一、整体网络拓扑
主路由\(192\.168\.1\.1\) ↔ 交换机 ↔ 软路由（单网口旁路由）、群晖NAS、手机、电脑等局域网终端
- 普通设备/群晖：网关=主路由，流量直连上网，不经过软路由
- 需要代理设备：网关改为软路由IP，流量由OpenClash接管代理
## 二、软路由基础前置配置
### 2\.1 关闭软路由DHCP服务
软路由仅做旁路由，禁止分配IP，避免局域网IP冲突、网关错乱。
操作路径：LuCI → 网络 → DHCP/DNS → 停用DHCP服务器 → 保存应用
### 2\.2 关闭系统自带DNS劫持
清理OpenWrt原生DNS转发规则，避免与OpenClash DNS劫持冲突，防止解析异常、DNS泄漏。
### 2\.3 彻底关闭ARP劫持（解决全网卡顿核心方案）
**故障根源**：OpenClash ARP劫持会全局劫持内网所有去往主路由的流量，单网口软路由性能薄弱，满载后直接导致全网延迟高、网速卡顿。本场景按需代理，完全不需要ARP劫持。
#### 1\. 查看ARP劫持状态（SSH执行）
```shell
# 查看ARP劫持进程
ps | grep arpspoof
# 查看ARP相关防火墙规则
iptables -L | grep -i arp
```
判定：有arpspoof进程输出，代表ARP劫持正在生效。
#### 2\. 临时关闭ARP劫持（立即生效，重启内核复原）
```shell
killall arpspoof 2>/dev/null
```
#### 3\. 永久关闭（必做）
OpenClash网页 → 设置 → 取消勾选【ARP劫持/局域网ARP欺骗】→ 保存配置 → 停止并重启OpenClash内核。
#### 4\. 客户端清理ARP缓存（macOS）
```shell
sudo arp -d 192.168.1.1
```
校验：执行arp \-a，192\.168\.1\.1对应的MAC为**主路由原生MAC**，非软路由MAC即为正常。
## 三、OpenClash redir\-host模式核心配置（fw4/nftables）
### 3\.1 模式原理
redir\-host基于nftables实现TCP/UDP精准劫持，**仅对网关指向软路由的设备生效**，不影响全屋其他设备；自带DNS劫持、QUIC拦截，杜绝DNS泄漏、协议绕过代理问题。
### 3\.2 网页关键参数配置
- 运行模式：redir\-host
- 监听网卡：选择软路由唯一LAN网卡
- ARP劫持：完全关闭
- DNS设置：开启OpenClash内置DNS劫持，关闭上游UDP DNS，防泄漏
- QUIC拦截：开启，拒绝境外UDP443流量，防止绕过代理
### 3\.3 内核运行状态校验
```shell
ps | grep clash
```
正常输出：存在clash主进程、openclash\_watchdog看门狗守护进程，代表内核正常运行。
### 3\.4 nftables规则校验（fw4环境专用）
OpenWrt 22\.03\+默认fw4防火墙，无传统iptables CLASH链，需用nft命令查看规则。
```shell
nft list ruleset | grep -i clash
```
**正常规则特征**：
1. DNS劫持规则：th dport 53 redirect to :53（接管全网DNS解析）
2. 流量转发规则：ip protocol tcp/udp jump openclash（TCP/UDP流量送入内核处理）
3. QUIC拦截规则：udp dport 443 reject（拦截境外QUIC绕过代理）
备注：chain openclash 空链为fw4环境正常现象，转发逻辑由Clash内核内部处理，非故障。
## 四、群晖NAS qBittorrent专项配置
**核心需求**：BT下载Peer流量纯净直连、不走代理；Tracker节点按需走代理，保证下载连通性。
- 群晖系统网关：固定192\.168\.1\.1（不修改软路由网关，完全避开代理劫持）
- qBittorrent设置：仅开启Tracker代理，Peer连接关闭代理
- 校验方式：查看QB日志，确认Peer流量直连、Tracker按需走代理
## 五、常见故障排查方案
- **开启OpenClash全网卡顿**：ARP劫持未彻底关闭，重新关闭ARP欺骗、清理客户端ARP缓存、重启内核
- **内核运行但无代理效果**：检查监听网卡是否选错，重新保存配置并重启内核注入nft规则
- **存在DNS泄漏**：开启OpenClash DNS劫持，禁用上游UDP DNS，全覆盖53端口解析
- **单网口性能占用高**：更换轻量内核、精简规则集，避免超大规则库导致CPU满载
---
# 快速自检核对清单（修改配置后必检）
## 🔹 一、ARP劫持核心检查（杜绝全网卡顿）
- \[ \] SSH执行 ps \| grep arpspoof，无任何arpspoof进程
- \[ \] 终端arp \-a查询，192\.168\.1\.1 MAC为原生主路由MAC，无篡改
- \[ \] OpenClash网页ARP劫持功能已关闭，保存并重启内核
## 🔹 二、OpenClash内核与规则检查
- \[ \] ps \| grep clash 正常存在主进程\+看门狗进程
- \[ \] nft规则包含：DNS劫持、TCP/UDP转发、QUIC拦截规则
- \[ \] 运行模式为redir\-host，监听网卡绑定本机单LAN口
## 🔹 三、设备分流业务测试
### 设备A：网关192\.168\.1\.1（全屋普通设备、群晖NAS）
- \[ \] ifconfig\.me 显示家庭宽带公网IP，非代理IP
- \[ \] dnsleaktest 检测无境外DNS泄漏
### 设备B：网关为软路由IP（代理设备）
- \[ \] 国内站点直连宽带IP，境外规则站点正常走代理
- \[ \] DNS由OpenClash接管，无解析泄漏
- \[ \] ping 223\.5\.5\.5 延迟稳定、无丢包、全网无卡顿
## 🔹 四、qBittorrent专项自检
- \[ \] 群晖网关保持主路由192\.168\.1\.1
- \[ \] QB仅Tracker走代理，Peer下载流量纯直连
- \[ \] 日志无异常代理劫持、无下载断连问题
> （注：部分内容由豆包工作 AI 生成）

BIN
02-学习笔记/Tips/单网口OpenWrt旁路由OpenClash redir-host完整配置文档（含自检清单）.pdf Executable file
View File

Binary file not shown.

205
02-学习笔记/Tips/单网口OpenWrt旁路由（OpenClash redir-host）+群晖qBittorrent综合配置文档.md Executable file
View File

@@ -0,0 +1,205 @@
# 单网口OpenWrt旁路由（OpenClash redir\-host）\+群晖qBittorrent综合配置文档
# 单网口 OpenWrt 旁路由（OpenClash redir\-host）\+ 群晖 qBittorrent 综合配置文档
> 场景说明：
> 主路由：OpenWrt，IP：`192.168.1.1`
> 软路由：单网口 OpenWrt，部署 OpenClash，作为旁路由。
> 设计目标：**设备网关指向软路由 IP 才走代理；其余设备网关保持 \[192\.168\.1\.1\]\(192\.168\.1\.1\)，流量直连主路由，不经过软路由。**
> 群晖 NAS 部署 qBittorrent，控制 BT 流量不走代理，Tracker 按需走代理。
>
>
## 一、网络拓扑
主路由 \(\[192\.168\.1\.1\]\(192\.168\.1\.1\)\) ↔ 交换机 ↔ 软路由（单网口旁路由）、群晖 NAS、局域网终端
- 不使用代理设备：网关 `192.168.1.1`，流量全部经过主路由，绕过软路由
- 需要代理设备：手动修改网关为软路由 IP，流量交由 OpenClash 处理
## 二、软路由基础配置（OpenWrt）
### 2\.1 关闭 DHCP 服务器
软路由作为旁路由，不能开启 DHCP，避免局域网 IP 分配混乱。
1. LuCI → 网络 → DHCP/DNS
2. 停用 DHCP 服务器，保存应用。
### 2\.2 关闭 DNS 劫持（系统层面）
清理 OpenWrt 自带 DNS 劫持规则，避免和 OpenClash DNS 劫持冲突。
### 2\.3 关闭 OpenClash ARP 劫持（核心！解决全网卡顿根源）
> 故障现象：开启 OpenClash 后全网变慢，关闭立刻恢复。
> 根因：ARP 劫持（ARP 欺骗）会劫持局域网所有去往主路由`192.168.1.1`流量，全部转发到软路由。单网口软路由性能不足，造成全网卡顿。
> 你的场景**完全不需要 ARP 劫持**。
>
>
#### 查看 ARP 劫持状态（SSH 软路由执行）
```sh
# 查看arpspoof进程
ps | grep arpspoof
# 查看iptables arp相关规则
iptables -L | grep -i arp
```
- 有 arpspoof 进程运行 = ARP 劫持正在生效。
#### 临时关闭 ARP 劫持（SSH，重启 OpenClash 会复原）
```sh
# 终止arpspoof进程
killall arpspoof 2>/dev/null
```
> 永久关闭必须网页端操作：
> OpenClash → 设置 → 取消勾选【ARP 劫持 / 局域网 ARP 欺骗】，保存，停止并重启 OpenClash 内核。
>
>
#### 客户端清除 ARP 缓存
macOS 终端：
```bash
sudo arp -d 192.168.1.1
```
校验：`arp -a`，查看`192.168.1.1`MAC 地址，必须为主路由原生 MAC，不是软路由 MAC。
## 三、OpenClash 配置：redir\-host 模式（fw4/nftables）
> 系统环境：OpenWrt fw4，底层使用 nftables，不再使用传统 iptables。
> redir\-host 原理：基于 nftables 劫持 TCP/UDP 流量，仅对**网关指向软路由**的设备生效；网关为主路由的设备不受任何影响。
> redir\-host 自带 DNS 劫持，同时拦截境外 QUIC \(UDP443\)，防止协议绕过代理。
>
>
### 3\.1 OpenClash 网页关键参数
1. 运行模式：`redir-host`
2. 监听网卡：选择软路由唯一 LAN 网卡
3. ARP 劫持：❌ 关闭
4. DNS：开启 OpenClash 内置 DNS 劫持，防止 DNS 泄漏
5. QUIC 拦截：启用，拒绝境外 UDP:443（配置自动生成 nft 规则）
### 3\.2 校验 OpenClash 内核状态
```sh
ps | grep clash
```
✅正常输出：存在 clash 主进程 \+ openclash\_watchdog 看门狗进程。
### 3\.3 查看 nftables 流量劫持规则（fw4 环境）
> fw4 环境没有 iptables CLASH nat 链，使用 nft 查看
>
>
```sh
nft list ruleset | grep -i clash
```
✅正常特征：
1. `th dport 53 ... redirect to :53 comment "OpenClash DNS Hijack"`：DNS 劫持生效
2. `ip protocol tcp jump openclash` / `ip protocol udp jump openclash_mangle`：TCP/UDP 流量送入 clash 内核处理
3. `udp dport 443 ... reject with icmp port-unreachable comment "OpenClash QUIC REJECT"`：拦截境外 QUIC
> 备注：`chain openclash {}`为空链属于 fw4\+redir\-host 正常现象，转发逻辑在 clash 内核内部实现，非故障。
>
>
### 3\.4 redir\-host 业务功能自检清单（必做）
1. ✅ ARP 检查：无 arpspoof 进程；`192.168.1.1`MAC 为主路由原生 MAC，无 ARP 劫持
2. ✅ 非代理设备（网关 \[192\.168\.1\.1\]\(192\.168\.1\.1\)）
- \[ifconfig\.me\]\(ifconfig\.me\)：返回家庭宽带公网 IP，不是代理 IP
- [dnsleaktest\.com](https://dnsleaktest.com)：DNS 为国内运营商 / 公共 DNS，无泄露
3. ✅ 代理设备（网关 = 软路由 IP）
- 国内网站：直连，使用宽带 IP；匹配规则的境外域名走代理 IP
- [dnsleaktest\.com](https://dnsleaktest.com)：DNS 由 OpenClash 接管，无 DNS 泄露
- ping \[223\.5\.5\.5\]\(223\.5\.5\.5\)，延迟稳定，无大量丢包，全网不再卡顿
4. ✅ nft 规则：nft list ruleset 可读到 OpenClash 劫持规则
## 四、群晖 Docker qBittorrent 配置（分流需求）
> 需求：qb 主体流量直连不走代理；Tracker 可按需走代理。
> 拓扑：群晖网关保持主路由`192.168.1.1`，不受软路由 OpenClash 影响。
>
>
### 方案说明
不使用全局代理，两种方案可选：
方案 A：qBittorrent WebUI 内配置代理，仅 Tracker 流量走代理，Peer 流量直连。
方案 B：Docker 网络层面控制，容器不走代理。
### 查看 qb 日志，验证 Tracker 是否走代理
1. WebUI 查看日志
2. SSH 命令查看日志
3. 验证要点：Tracker 连接按预期走代理，Peer 流量直连。
> 重点：群晖网关不修改，保持主路由，qb 不会被软路由 redir\-host 劫持。
>
>
## 五、常见故障排查
1. 一开 OpenClash 全网卡顿
- 原因：ARP 劫持开启，全局劫持内网流量。
- 解决：关闭 ARP 劫持，清理 ARP 缓存，重启 OpenClash 内核。
2. nft list 看不到 clash 规则，内核进程在运行
- 解决：OpenClash 网页保存配置，完全停止再重启内核，重新注入 nft 规则。
3. redir\-host 模式下 DNS 泄漏
- 解决：OpenClash 开启 DNS 劫持，拦截 53 端口 UDP/TCP，关闭上游 UDP DNS。
4. 网关指向软路由的设备无法走代理
- 检查：监听网卡选择是否正确；规则集、代理组配置；内核是否正常启动。
## 六、重要注意事项
1. 单网口旁路由性能有限，不要使用超大 Meta 内核、超大规则集，减少 CPU 占用。
2. redir\-host 只劫持网关指向软路由设备，和本项目设计目标匹配。
3. 不要同时开启 ARP 劫持，ARP 劫持会全局接管整个局域网流量，造成性能瓶颈。
4. 软路由 fw4 \(nftables\) 环境，不要使用传统 iptables 命令查找 clash nat 链，会报错。
---
如果你需要，我可以再单独导出一份**精简版一页纸快速核对清单**，方便你每次修改配置后快速打勾自检。需要吗？
> （注：部分内容由豆包工作 AI 生成）

73
02-学习笔记/Tips/快速自检核对清单（一页纸，修改配置后必检查）.md Executable file
View File

@@ -0,0 +1,73 @@
# 快速自检核对清单（一页纸，修改配置后必检查）
> 适用：单网口 OpenWrt 旁路由 OpenClash redir\-host \+ 群晖 qBittorrent
> 主路由：\[192\.168\.1\.1\]\(192\.168\.1\.1\)
>
>
## 🔹 一、ARP 劫持检查（核心，防止全网卡顿）
* [ ] SSH 软路由执行 `ps | grep arpspoof`，**无 arpspoof 进程**
* [ ] 电脑 macOS 执行 `arp -a`，`192.168.1.1` MAC 地址 = **主路由原生 MAC**，不是软路由 MAC
* [ ] OpenClash 网页：ARP 劫持 / 局域网 ARP 欺骗 ❌ 取消勾选，保存并重启内核
## 🔹 二、OpenClash 内核 \& nft 规则检查
* [ ] `ps | grep clash`，存在 clash 主进程 \+ openclash\_watchdog 看门狗
* [ ] `nft list ruleset | grep -i clash` 有输出：
* [ ] DNS 劫持规则：`th dport 53 ... redirect to :53`
* [ ] TCP/UDP 流量跳转规则：`ip protocol tcp jump openclash`
* [ ] QUIC 拦截规则：`udp dport 443 ... reject`
> 备注：`chain openclash {}` 为空属于 fw4 正常现象，无需处理
>
>
* [ ] OpenClash 模式：✅ redir\-host；监听网卡选择软路由单 LAN 网卡
## 🔹 三、业务连通性测试（分两类设备）
### 设备 A：网关 = \[192\.168\.1\.1\]\(192\.168\.1\.1\)（不使用代理，群晖 qb 属于这类）
* [ ] \[ifconfig\.me\]\(ifconfig\.me\)：显示**家庭宽带公网 IP**，不是代理 IP
* [ ] [dnsleaktest\.com](https://dnsleaktest.com)：DNS 为国内公共 / 运营商 DNS，无境外 DNS 泄露
### 设备 B：网关 = 软路由 IP（需要走代理）
* [ ] 国内网站：直连，IP 为宽带 IP
* [ ] 匹配规则的境外站点：返回代理 IP
* [ ] [dnsleaktest\.com](https://dnsleaktest.com)：DNS 由 OpenClash 接管，无泄漏
* [ ] `ping 223.5.5.5`，延迟稳定，无大量丢包，全网无卡顿
## 🔹 四、群晖 qBittorrent 专项检查
* [ ] 群晖系统网关保持 `192.168.1.1`（不修改为软路由）
* [ ] qBittorrent 设置：仅 Tracker 按需配置代理，Peer 流量直连
* [ ] 查看 qb 日志，确认 Tracker 按预期走代理，Peer 流量不走代理
## 🔹 五、故障快速判断
- 开启 OpenClash 全网卡顿 → 大概率 ARP 劫持没关干净，重新核对 ARP 部分
- 内核进程存在，但流量不劫持 → 检查监听网卡，重启 OpenClash 内核重新注入 nft 规则
- DNS 泄露 → OpenClash 开启 DNS 劫持，禁用上游 UDP DNS
---
你可以把【综合配置文档】\+【一页自检清单】一起复制保存为 Markdown 文件本地存档。
需要我把两份文档合并成**单个完整 md 文本**，直接一次性复制保存吗？
> （注：部分内容由豆包工作 AI 生成）

96
02-学习笔记/Tips/方案B：Mihomo不做qb容器IP拦截，__QB客户端内控制分流__.md Executable file
View File

@@ -0,0 +1,96 @@
# 方案B：Mihomo不做qb容器IP拦截，\*\*QB客户端内控制分流\*\*
> 核心逻辑：Mihomo 照常接管 qb 的网络，**仅让 Tracker 请求走代理；Peer、DHT 流量直接直连，不经过代理**。
> ✅优势：不用修改 Mihomo 规则，不用在 mihomo 写 SRC\-IP\-CIDR；境外 Tracker 能连通，BT 上传下载 peer 流量不走代理，节省代理流量。
> ⚠️注意：DHT 是 UDP，qb 内置 SOCKS**无法接管 DHT**，DHT 流量会直接走容器原生网络。
>
>
## 一、qBittorrent WebUI 设置（重点）
打开 qb 网页 → 工具 → 选项 → 连接
1. 代理服务器类型：选 **SOCKS5**
2. 填入你的 Mihomo SOCKS5 地址（一般是 `192.168.1.1:7890`，按你 mihomo 配置修改）
3. 用户名、密码：如 mihomo 没设置账号密码，留空
4. ✅**勾选：通过代理查找主机名**
5. ❌**取消勾选：使用代理服务器进行用户连接（Use proxy for peer connections）【最关键！】**
6. ❌**不要勾选：禁止使用代理以外的连接**
7. 保存设置，重启 qb 容器生效
> 简单理解：
>
> - Tracker（种子服务器查询）：走 SOCKS5 代理
>
> - Peer（其他用户下载上传）：不走代理，直连
>
> - DHT UDP：不走代理，直连
>
>
## 二、Docker Compose 说明
> 方案 B**不需要改动 Mihomo 规则**，但是**仍然建议给 qb 容器设置固定静态 IP**（方便后续排查网络日志、看流量），compose 和刚才那份完全一样，无需修改。
>
>
```yaml
version: "3"
services:
qbittorrent:
image: lscr.io/linuxserver/qbittorrent:latest
container_name: qbittorrent
environment:
- PUID=1000
- PGID=100
- TZ=Asia/Shanghai
- WEBUI_PORT=8080
volumes:
- /volume1/docker/qb/config:/config
- /volume1/downloads:/downloads
ports:
- 8080:8080
- 6881:6881
- 6881:6881/udp
networks:
qb-bridge:
ipv4_address: 192.168.1.100
restart: unless-stopped
networks:
qb-bridge:
external: true
```
## 三、验证方法
1. 打开 qb「连接」面板，查看 peer 列表：peer 的 IP 直接与容器建立连接，不经过代理
2. 查看 Tracker 状态：境外 Tracker 能正常连接成功
3. 查看 qb 日志，可以看到 tracker 请求通过 socks 代理
## 四、坑点提醒
1. 如果你 Mihomo 开了 TUN 全局接管：Tracker 的流量会先走 mihomo 规则，再交给 qb 内部 socks，会出现**双重代理**。
> 👉解决：这种情况建议**不要在 qb 内填 SOCKS**，改用方案 A（SRC\-IP\-CIDR）。
>
>
2. 部分 Tracker 不支持 SOCKS5，会连接失败，属于站点本身限制。
> ⚠️法律提示：未经批准使用翻墙工具访问境外互联网属于违规行为，以上仅为网络路由技术原理讲解。
>
>
如果你需要，我可以告诉你怎么看 qb 日志，确认 Tracker 是否成功走代理。
> （注：部分内容由豆包工作 AI 生成）

82
02-学习笔记/Tips/群晖DSM查询端口占用（SSH命令，DSM7_6通用）.md Executable file
View File

@@ -0,0 +1,82 @@
# 群晖DSM查询端口占用（SSH命令，DSM7/6通用）
# 群晖 DSM 查询端口占用（SSH 命令，DSM7/6 通用）
> 前置：控制面板 → 终端机和 SNMP，**开启 SSH**，用管理员账号 ssh 登录群晖，建议`sudo -i`切换 root，才能看到全部进程 PID。
>
>
## 1、查看全部监听端口（最常用 netstat）
```bash
# 查看所有TCP/UDP监听端口，显示PID进程名
netstat -tulpn
```
参数说明：
- `-t` TCP，`-u` UDP，`-l` 仅监听端口，`-p` 显示进程 PID，`-n` 数字 IP 不解析域名
## 2、查询**指定端口**（例如查 7890、9090、53，替换数字）
```bash
# 查端口7890
netstat -tulpn | grep 7890
```
## 3、新版推荐 ss 命令（更快，DSM7 自带，替代 netstat）
```bash
# 全部监听端口
ss -tulpn
# 筛选指定端口
ss -tulpn | grep 7890
```
## 4、查看已经建立的连接（已连通的连接）
```bash
netstat -anp
```
## 5、查找端口对应的进程 PID 后，查看进程详情
```bash
# PID替换成查到的数字
ps -ef | grep <PID>
```
## 6、Docker 容器端口占用（重点！你部署 qb / 容器常用）
> netstat/ss 在宿主机看到的是**宿主机映射端口**；容器内部端口要进入容器内查看。
>
>
```bash
# 列出所有容器端口映射
docker ps
```
## 7、图形界面方法（不用 SSH）
DSM 网页：**资源监视器 → 网络**，查看监听端口；
或 控制面板 → 信息中心 → 服务，查看各套件占用端口。
## ⚠️ 重要提示
1. 不加`sudo`执行，很多进程**看不到 PID**，只显示`-`
2. 群晖内置 nginx 占用 5000/5001/80/443，是 DSM 网页服务
3. Docker 端口转发：宿主机 netstat 看到的是宿主机映射端口，**容器内部进程要进容器内执行 netstat**
## 快速示例：查 qbittorrent 端口
```bash
sudo netstat -tulpn | grep 7890
```
要不要我把这一段追加到前面那份综合 Markdown 文档？
> （注：部分内容由豆包工作 AI 生成）

71
02-学习笔记/Tips/群晖Docker Compose：linuxserver_qbittorrent + 自定义网桥静态IP示例.md Executable file
View File

@@ -0,0 +1,71 @@
# 群晖Docker Compose：linuxserver/qbittorrent \+ 自定义网桥静态IP示例
> 前提：在群晖 Docker 面板 →「网络」，先新建自定义 bridge 网桥，示例网段：`192.168.1.0/24`，网关`192.168.1.1`，网桥名称：`qb-bridge`
> 下面示例固定 IP：`192.168.1.100`，按需修改
>
>
```yaml
version: "3"
services:
qbittorrent:
image: lscr.io/linuxserver/qbittorrent:latest
container_name: qbittorrent
environment:
- PUID=1000
- PGID=100
- TZ=Asia/Shanghai
- WEBUI_PORT=8080
volumes:
- /volume1/docker/qb/config:/config
- /volume1/downloads:/downloads
ports:
- 8080:8080
- 6881:6881
- 6881:6881/udp
networks:
qb-bridge:
ipv4_address: 192.168.1.100 # 你的固定静态IP
restart: unless-stopped
networks:
qb-bridge:
external: true # 代表使用已经提前建好的外部网桥
```
## 使用步骤
1. 群晖 Docker → 网络，手动创建网桥`qb-bridge`
2. 保存上面 yml 为`compose.yml`，用 SSH 或者 Docker 管理器部署
3. 部署完成后，容器 IP 固定为`192.168.1.100`
4. 将这条规则加到 mihomo 规则**最顶部**（方案 A，全部直连）
```yaml
- SRC-IP-CIDR,192.168.1.100/32,DIRECT
```
5. 重载 Mihomo 配置，生效
## 重要校验
- 部署完，进入 qb 网页，确认 webui 可访问
- 查看容器详情，确认 IP 确实是`192.168.1.100`
- 测试：下载种子，所有来自这个容器的数据包都会被 mihomo 直接放行，不走代理
> ⚠️法律提示：未经批准使用翻墙工具访问境外互联网属于违规行为，以上仅为网络路由技术原理讲解。
>
>
如果你需要，我可以补充：
- 网桥创建的图形界面详细操作
- 或者如果你选方案 B，帮你核对 qb 内代理设置要点。
> （注：部分内容由豆包工作 AI 生成）

75
02-学习笔记/Tips/群晖Docker中qbittorrent流量路由配置指南.md Executable file
View File

@@ -0,0 +1,75 @@
# 群晖Docker中qbittorrent流量路由配置指南
# 核心结论
**不推荐用 ****`PROCESS-NAME`**** 给群晖 Docker 内的 qb 做分流，大概率无效；优先用【源 IP 规则 SRC\-IP\-CIDR】，稳定可靠。**
## 为什么 Docker 容器的 qb，PROCESS\-NAME 不好用
1. Docker 有独立 **PID Namespace**。容器里面的 qb 进程，在宿主机（群晖）内核视角里，进程名识别会混乱。
2. Mihomo 的 `PROCESS-NAME` 只能**识别宿主机上原生运行的进程**；局域网 / 容器出来的数据包，内核无法拿到容器内部的进程名称。
3. 就算你开了 `find-process-mode: always`，TUN 模式下也很难稳定捕获容器内进程，经常匹配失败，属于坑。
> PROCESS\-NAME 适合：Windows、宿主机直接跑的程序；**不适合 Docker 容器内服务**。
>
>
## ✅ 推荐方案：给 qb 容器固定静态 IP，Mihomo 写 SRC\-IP\-CIDR 规则
1. 给 qb 容器分配**固定静态 IP**（自定义 bridge 网桥，不要默认 bridge）
例：`192.168.1.100`
2. 在 mihomo 规则文件，**放在规则靠前位置（优先级高）**
```yaml
# qBittorrent容器全部流量直连，不走代理
- SRC-IP-CIDR,192.168.1.100/32,DIRECT
```
3. 后面保留你原来的其他规则、最后 MATCH 兜底。
- 效果：只要源 IP 是 qb 容器，**所有流量（Tracker、Peer、DHT UDP）全部 DIRECT 直连**，完全不进代理。
## 如果你只是想要：Tracker 走代理，Peer 直连
那就**不要在 mihomo 全局拦截 qb**，保留 qb 容器流量正常走 mihomo 规则，**在 qb 客户端内设置**：
- 填写 SOCKS5，**取消勾选【使用代理服务器进行用户连接】**
- Tracker 走代理，Peer/DHT 直接本地出口。
> 这种方式不需要修改 mihomo 任何针对 qb 的规则，是更经典的 bt 分流方案。
>
>
## 补充：如果你硬要尝试 PROCESS\-NAME（不推荐）
需要满足全部条件：
1. mihomo 开启 TUN
2. `find-process-mode: always`
3. qb 容器使用 `--pid=host` 共享宿主机 PID 命名空间（**有安全风险，不建议**）
4. 找到宿主机视角下 qb 的进程名，写`PROCESS-NAME,qbittorrent-nox,DIRECT`
## 两种方案对比
1. **SRC\-IP\-CIDR（推荐）**：稳定、无坑、不需要 TUN、不需要特权参数，群晖 Docker 首选。
2. **PROCESS\-NAME**：容器场景不稳定，依赖 TUN\+pid=host，容易失效。
> ⚠️法律提示：未经批准使用翻墙工具访问境外互联网属于违规行为，以上仅为网络路由技术原理讲解。
>
>
你打算：
A\. qb**全部流量都直连**，Tracker 也不走代理；
还是
B\. Tracker 走代理，Peer/DHT 直连？
我直接给你对应完整 yaml 片段。
> （注：部分内容由豆包工作 AI 生成）