2026-01-11

发布时间 :
  1. 01月11日
    1. 一、今日完成情况
    2. 二、今日感悟
    3. 三、备注
    4. 四、SMART分解mitmproxy的学习路径
      1. 环境配置流程
    5. 五、梯子坏掉系统排查解决方案一览：
    6. 六、数据抓包解析实战Proxifier初上手
    7. 七、今日技术积累

01月11日

一、今日完成情况

  • 梳理一下mitmproxy的使用方法，快速入门最终目标是，批量爬取公众号消息文章，任务分解如下：
    • 环境准备与安装 (预计 30 分钟)
    • 配置代理与证书安装 (预计 45 分钟)
    • 实战找到一个简单项目尝试（45分钟） 未完成
  • 导出梯子修理和端口重新配置的笔记，未来出问题了可以复用。
  • Smart Connections Obsidian插件配置，妥妥的生产力
    • 两方面，第一是我在搜索内容的时候，它不是僵硬的全词匹配，或者像数据库这样匹配，而是它根据嵌入模型，使用语义分析的方法来模糊匹配。
    • 第二方面，是对当前笔记进行表述的相似度鉴定，从而我在写文章的时候，会有相似表述的文章推荐给我，供我随时借鉴和参考。
  • 申请openaikey，看看是否可以绑定银行卡 ，这是API：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

二、今日感悟

  • 核心业务数据​：
    • 工位装修、mitproxy配置、梯子修理笔记导出、librechat代理配置尝试、微信抓包代码尝试
  • ​今日工作总结：​
    • 比较分散，遇到的问题比较多，层层嵌套，最终问题还是无法解决，微信这方面做的还是太好了
  • ​明日工作计划：
    • 至少把终端快速启动（对应文件路径下）的快速方法配置好
    • 关于数据的审核完成一下，至少完成100条把
  • ​今日学习成长：​
    • 还是通过实践有很多有意思的事情，也是有反馈的，而不是看着网课停留在理论的知识，所以实践的反馈非常及时，非常让人有成就感。

三、备注

  • 无

四、SMART分解mitmproxy的学习路径

环境搭建和安装：

  • S (Specific): 在 macOS 上安装 mitmproxy。
  • M (Measurable): 在终端（Terminal）中输入 mitmweb 或 mitmproxy 命令后，程序能成功启动并看到界面。
  • A (Achievable): 对于 macOS，使用 Homebrew 是最简单的方式。只需一个命令 brew install mitmproxy。
  • R (Relevant): 这是使用该工具的基础，没有安装就无法进行后续任何操作。
  • T (Time-bound): 30分钟内完成（包括处理潜在的网络或环境问题）。

配置代理和证书安装：

  • S (Specific): 配置系统代理，并在 Mac 和手机（如果需要抓取手机流量）上安装 mitmproxy 的 CA 证书，以解密 HTTPS 流量。
  • M (Measurable): 在浏览器中访问一个 HTTPS 网站（如 https://baidu.com），mitmproxy 的界面中能看到解密后的明文请求内容，浏览器没有报告证书错误。
  • A (Achievable): 启动 mitmproxy 后，访问 http://mitm.it 即可下载证书，根据页面指引在 macOS 的“钥匙串访问”和手机的设置中信任该证书。
  • R (Relevant): 微信的通信是基于 HTTPS 的，不安装证书就无法分析其具体内容。
  • T (Time-bound): 45分钟。这一步是新手的常见难点，需要耐心操作。

环境配置流程

mitmproxy 其实包含三个工具：

  1. mitmproxy: 命令行界面（酷炫，但操作复杂）。
  2. mitmweb: 网页界面（强烈推荐新手使用，直观）。
  3. mitmdump: 纯命令行输出（适合写脚本自动化）。

快速安装：

brew install mitmproxy

快速启动：

mitmproxy

启动后，你会看到一个深色的空列表界面，右下角应该显示监听端口 *:8080。

配置代理 (使用终端命令 networksetup)

配置流量的流向（新窗口）：

# 1. 设置 HTTP 代理
sudo networksetup -setwebproxy "Wi-Fi" 127.0.0.1 8080

# 2. 设置 HTTPS 代理
sudo networksetup -setsecurewebproxy "Wi-Fi" 127.0.0.1 8080

证书安装 (核心一步)：

打开证书文件： mitmproxy 首次运行后会在 ~/.mitmproxy/ 下生成证书。直接用命令调用 Keychain Access 打开它：

open ~/.mitmproxy/mitmproxy-ca-cert.pem
Pasted image 20260111155801 Pasted image 20260111155821

证书需要配置为始终允许，这里才算配置完成。

遇到问题：
因为我开启了代理，代理的端口是7897，然后现在使用窗口重新配置了流量的端口是8080，导致我上网就遇到了问题，所以现在需要解决这个问题才行。

7897 端口代理（很可能是 ClashX、V2rayU 等科学上网工具）和 mitmproxy 的 8080 端口代理同时开启，会导致流量路由混乱。

  • 系统代理只能设置一个端口（最后设置的生效）
  • 如果你先设置了 7897，再设置 8080 → 8080 生效
  • 但 7897 的代理服务还在运行，mitmproxy 可能无法正确处理流量

解决方法（失败）：

链式代理（高级）

就是让流量首先通过8080端口，然后再通过7897代理端口，从而不仅保证了计算机可以访问外网，也保证了网络流量都可以得到分析。

# 停止现有的 mitmproxy
pkill mitmproxy

# 启动 mitmproxy，指定上游代理为科学上网工具
mitmproxy -p 8080 --mode upstream:http://127.0.0.1:7897

# 或者使用 mitmweb（推荐新手）
mitmweb -p 8080 --mode upstream:http://127.0.0.1:7897

# 设置系统代理指向 mitmproxy
sudo networksetup -setwebproxy "Wi-Fi" 127.0.0.1 8080
sudo networksetup -setsecurewebproxy "Wi-Fi" 127.0.0.1 8080

# 验证设置
networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
Pasted image 20260111160408

现在开启代理，发现无法访问外网了，说明什么环节出了问题。

说明端口配置出现了问题，现在我的系统代理还是属于冲突的状态，端口流量还是指向了8080端口。

尝试通过指令把端口修改过来，先能上网然后再从长计议。

关闭mitmproxy之后，使用以下指令尝试修改系统端口回到7897，发现没有任何效果，依然显示代理错误，不过这次不是502了。

 sudo networksetup -setwebproxy "Wi-Fi" 127.0.0.1 7897

重启clash verge，发现问题解决，代理又回到了原来clash需要的端口了。

再次解决：

停止抓包的相关进程：

pkill mitmproxy

确认系统代理指向 Clash Verge (7897)：

networksetup -getwebproxy "Wi-Fi"
networksetup -getsecurewebproxy "Wi-Fi"
Pasted image 20260111161722

再次访问，网络倒是没问题，不过感觉我账号要被封了：
Pasted image 20260111161857

五、梯子坏掉系统排查解决方案一览：

检查服务器状态

sudo systemctl status hysteria-server
Pasted image 20260111163357

导出日志

sudo journalctl -u hysteria-server -n 50 --no-pager
Pasted image 20260111163606 Pasted image 20260111163629

可以排查客户端连接过程当中出现的问题。

端口占用

sudo ss -lunp | grep :443
Pasted image 20260111163726 发现是旧的进程占用了原来的端口，那就重启吧。 
sudo systemctl restart hysteria-server

再次常看服务器状态：

sudo systemctl status hysteria-server
Pasted image 20260111163840

那就没问题了，客户端再次尝试连接一下试一试。

再次连接失败，不是服务器出现问题，也不是客户端出现问题，而是我的服务器被运营商特殊照顾了，根据日志分析得到结论：

日志问题分析

✅ Hysteria 服务器现在是完全正常运行的
❌ 客户端 Timeout 不是“服务器没起来”
❌ 也不是端口冲突 / NGINX / systemd 问题
🔥 而是：UDP 链路质量 / NAT / GFW 丢包导致的 QUIC 流量超时

这是断开的日志信息

accepting stream failed: timeout: no recent network activity

TCP error ... timeout: no recent network activity

Hysteria → 客户端的 UDP 通道建立了
但 UDP 流量在公网中“断断续续 / 丢失 / 被限速 / 被 QoS”
QUIC 在等包，但等不到

你日志里的目标地址：

  • graph.microsoft.com
  • `self.events.data.microsoft.com
  • mtalk.google.com
  • a-api.anthropic.com
  • www.google-analytics.com

这说明两点：
客户端的系统流量已经走进了 Hysteria
不是某个特定网站问题，而是“所有 TCP over UDP 都在 timeout”

得出结论：
UDP 443 在这条链路上质量极差，原因如下：

  • 本地网络 / ISP 对 UDP 443 严重 QoS
  • GFW 对 QUIC/UDP 443 限速或丢包
  • Vultr 这个 IP 的 UDP 回程质量差
  • 客户端在 NAT / 防火墙 后，UDP 不稳定

很多网络对 UDP 443 特别不友好，尝试修改服务器和客户端配置文件的端口即可：

服务器端修改端口，指令如下：

sudo nano /etc/hysteria/config.yaml
Pasted image 20260111165024 重启服务，检查端口，确认已经被修改： 
sudo systemctl restart hysteria-server

sudo ss -lunp | grep 8443
Pasted image 20260111165424

修改客户端的配置文件：

Pasted image 20260111165233 Pasted image 20260111165323

云服务器端口特殊配置

因为vultr是云服务器，我需要再服务器防火墙配置界面配置TCP放行，还需要在终端也配置防火墙，对8443端口方向，这样才完全配置好，仅仅在服务器配置文件配置是远远不够的。

在服务器上执行：

sudo iptables -L -n -v

或者如果用的是 UFW：

sudo ufw status verbose

必须看到类似：

ALLOW UDP 8443

如果没有，直接放行：

sudo ufw allow 8443/udp sudo ufw reload

再次查看8443端口

sudo ss -u -lpn | grep 8443

你应该看到类似：

udp   UNCONN  0  0  0.0.0.0:8443   users:(("hysteria",pid=xxxx))

没有 → 服务没真监听
有 → 继续下一步

443 / 8443 是最容易出问题的
2096 / 2087 / 5353 / 10000+ 反而更稳

Pasted image 20260111184709

在服务器端需要放行这两个端口，不然无法通行的。最后连接上了，继续配置我的抓包项目把。

Pasted image 20260111185435

六、数据抓包解析实战Proxifier初上手

Proxifier软件，我今天为了抓微信的数据包，尝试了一下让微信强制走代理的效果，所以我简单的了解了一下这个软件的作用是什么：

实现极其精细的“分流” (办公/生活互不干扰)，这是 Proxifier 最强大的功能。你可以根据应用程序、目标域名、目标端口来制定复杂的路由规则。

可以让电脑的不同软件网页访问不同的代理和不同的端口。可以定制化软件访问路由的个性化操作。

规则名称 应用程序 (Applications) 目标主机 (Target Hosts) 动作 (Action) 解释
公司内网 java; idea; eclipse 192.168.*; *.corp.com Proxy (公司VPN) 开发工具访问内网走 VPN
外网资源 java; chrome github.com; stackoverflow.com Proxy (Clash) 查资料、下依赖走翻墙
日常娱乐 Spotify; NetEaseMusic * Direct 听歌走直连，省流量且快
默认规则 Any Any Direct 其他没定义的都直连
代理链 (Proxy Chain) —— 黑客级玩法

Proxifier 的玩法： 你可以设置 Chain (代理链)。

你的电脑 -> 代理服务器 A (香港) -> 代理服务器 B (美国) -> 目标网站 (Google)

  • 你的收益：
    • 目标网站看到的 IP 是代理 B 的，追踪难度指数级上升。
    • 突破某些极其严格的公司防火墙限制。

解决 DNS 污染

场景：有时候你能连上 Google 的 IP，但因为 DNS 被污染，浏览器还是打不开。

Proxifier 的作用： 在 Proxifier 的 Name Resolution (域名解析) 设置中，你可以勾选 “Resolve hostnames through proxy” (通过代理远程解析域名)。

所以总体来说，这个软件可以从底层访问我的网卡，然后让我的流量可以按照自定义的方法走，从而实现一些个人的需求，这里按下不表，未来需要的时候，自然会想到这个网站。

https://blog.zgsec.cn/archives/278.html 此网页是简单的介绍。

七、今日技术积累

流量分流策略

为了防止抓包导致 AI 工具（ChatGPT/Claude）断连，采用了两种分流方案：

  1. Mitmproxy 白名单：使用 --ignore-hosts 参数让特定域名直通，不进行 SSL 解密。
  2. 浏览器独立代理：Firefox 配合 FoxyProxy 插件，绕过系统代理直接连接 Clash (:7897)。

今日遇到的问题如下：

问题现象 原因分析 解决方案
无法上网/断网 端口冲突或流量死循环 明确分层：系统代理给 mitmproxy，mitmproxy 上游给 Clash，Clash 关闭系统代理权限。
端口被占用 (Errno 48) 进程未正常退出 (僵尸进程) 使用 lsof -i :8080 查占用，pkill mitmproxy 强杀。
HTTPS 握手失败 客户端不信任自签证书 导入 ~/.mitmproxy/mitmproxy-ca-cert.pem 至钥匙串并设为**“始终信任”**。
微信不走代理 Mac 微信忽略系统代理设置 使用 Proxifier 强制接管 WeChat 进程流量转发至 127.0.0.1:8080。
抓不到 JSON 数据 微信使用 MMTLS 加密协议 尝试阻断 /mmtls/ 迫使降级（失败）；尝试关闭 IPv6。 微信s
微信使用的MMTLS加密协议我无法绕过去，即使尝试了系统配置关闭IPV6分发，然后关闭微信的mmtls，最后的结果就是微信访问不了公众号文章了，无法解析文章，却依然绕不开这个该死的协议。

关于技术方面的三点理解：

  • Mitmproxy：掌握了 Upstream 模式、Addon 脚本开发、请求拦截与篡改。
  • Proxifier：学会了进程级的流量强制调度和规则配置（Rules），这是调试网络和“驯服”不听话软件的神器。
  • Clash：理解了 TUN 模式与系统代理的区别，以及作为上游代理的配置。

自我评价： 虽然没有抓到那一串 CSV 列表，但今天打通了全链路代理调试环境。这套环境（Proxifier + Mitmproxy + Clash）是通用的，未来无论是调试 Android App、分析流媒体接口还是开发爬虫，都可以直接复用这套基建。

转载请注明来源，欢迎对文章中的引用来源进行考证，欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论，也可以邮件至 kipleyarch@gmail.com

浙ICP备2025181060号-2 © litearch

Built with Hexo and 3-hexo theme

Obsidian