如果你想直接安装，可以去 Chrome 应用商店里搜 EnvMate，也可以直接点这个链接进去：

https://chromewebstore.google.com/detail/envmate/mccdmjfnlkkjmcioapnehkmpgkblhiei

它本质上是一个给“多环境切换”场景准备的 Chrome 插件，解决的是一个很具体、但又特别容易反复踩坑的问题：很多系统的开发、测试、预发、生产环境长得几乎一模一样，切来切去的时候，人很容易手滑。

所以这次我就想试试看，能不能用一套比较轻的方式，把“看清当前环境”和“顺手切换测试账号”这两件事一起解决掉。

先放一张整体配置页面的截图：

我为什么想做这个插件

这些年做项目时，我越来越明显地感觉到，很多线上事故未必来自多复杂的技术问题，反而经常出在一些很朴素的地方，比如“看错环境了”。

同一个系统挂着好几套环境，页面结构、菜单位置、按钮样式都差不多。你明明以为自己在测试环境里点按钮，结果实际打开的是生产；或者本来只是想随手验证一下，最后却把操作落到了不该落的地方。

这种问题说起来不复杂，但只要你平时需要频繁在多套系统之间来回切换，就知道它有多烦。

另一个很实际的点，是最近一些内部测试系统开始往 HTTPS 迁移，但证书又是自签名的。这样一来，Chrome 原本那套还算顺手的用户名密码记忆和自动填充，在某些场景下就没那么稳定了。你得反复找测试账号、重新填账号密码，节奏很容易被打断。

所以我最后想做的，并不是一个很重的“环境管理平台”，而是一个足够轻、打开就能用的小插件：

1. 先让我一眼看出来当前到底在哪个环境。
2. 再让我在需要的时候，能顺手把对应环境的测试账号填进去。

EnvMate 就是沿着这个思路做出来的。

EnvMate 现在能做什么

这个插件目前做的事情不算复杂，但基本都围着“减少误操作”和“提高切换效率”展开。

1. 按 URL 规则识别当前环境

你可以给不同环境配置 URL 匹配规则，比如通配符、前缀匹配或者正则。只要页面地址命中了对应规则，插件就能识别出当前页面属于哪个环境。

这样做的好处是，它不依赖页面一定要改代码，也不要求系统本身提供什么专门的环境标识。很多时候只要域名或者路径有规律，就已经够用了。

2. 用足够明显的方式把环境标出来

识别出来之后，下一步就是“别让自己看漏”。

所以 EnvMate 现在支持几种比较直接的提示方式：

• 页面角标
• 页面水印
• 页面标题前缀
• 角标和水印组合

这些能力的重点其实不是“做得多精致”，而是“做得足够显眼”。

比如生产环境可以一直挂一个高对比度角标，测试环境可以铺一个淡一点的水印。这样就算页面本身几乎一模一样，你切回标签页或者重新聚焦窗口时，也能很快意识到自己现在到底在操作哪套环境。

3. 给不同环境维护测试账号

光是“认出来”还不够，很多时候你还得“登进去”。

所以插件里也支持给不同环境维护测试账号。切到某个页面之后，可以直接从插件里选择对应账号来填充，不用再去翻文档、翻聊天记录，或者从密码管理器里慢慢找。

这一点对那些用了自签名 HTTPS 的内部系统尤其有用。因为浏览器原生自动填充在这些场景下不一定总是顺手，而把账号和环境绑定在一起，反而更符合日常测试时的使用习惯。

这里也顺便强调一下：插件只负责在你主动操作时填充信息，不会自动提交表单。

4. 用分组管理一批环境

如果你手上的系统不止一个，或者同一条业务线下面挂着开发、测试、预发、生产好几套环境，那配置很快就会变乱。

所以我在插件里也加了分组能力，可以按产品、项目或者业务线去拆开维护。这样后面环境再多一点，也不至于所有配置全堆在一起。

这个插件适合什么人

如果你的日常工作里经常会遇到下面这些情况，那 EnvMate 大概率是有点用的：

• 经常在开发、测试、预发、生产环境之间来回切换
• 多个系统长得太像，容易看错环境
• 需要频繁登录不同测试账号
• 内部系统逐步迁到自签名 HTTPS，浏览器原生自动填充没以前那么顺手

它解决的不是一个特别宏大的问题，而是一个很具体、很高频、而且真的容易让人出错的问题。

这次用 Codex 做，体验也挺有意思

严格来说，这就是一次挺典型的 vibe coding。

因为我这次并不是先把所有细节都设计到很完整，再一点点照着实现，而是先把核心目标盯住，然后让 Codex 跟着我的想法一边写、一边改、一边对齐交互和细节。

这种过程和传统那种“先把需求文档写满，再按计划开发”的节奏不太一样。更像是你先把方向感讲清楚，然后不断把“不够顺手”的地方往前推，直到它真的开始像一个自己会用的工具。

对这种偏个人效率、偏工具型的项目来说，我自己觉得这种方式还挺合适的。它的好处不只是快，更重要的是，你可以比较低成本地把一个原本还只是模糊念头的东西，尽快落成一个能装进浏览器里、可以真用的插件。

安装方法

如果你只是想直接装起来用，可以去 Chrome 商店：

• Chrome Web Store: https://chromewebstore.google.com/detail/envmate/mccdmjfnlkkjmcioapnehkmpgkblhiei

如果你想顺手看看实现方式，也可以直接去 GitHub 上看源码：

• GitHub: https://github.com/knktc/EnvMate

我还额外上传了一份到百度网盘。如果你这边直接下载插件不太方便，也可以用这个链接：

• 百度网盘: https://pan.baidu.com/s/133Z4ofjbWXourmDe2ntzeg?pwd=fg42

如果你是手动安装 crx，可以简单按下面这几个步骤来：

1. 在 Chrome 地址栏打开 chrome://extensions/。
2. 打开右上角的“开发者模式”。
3. 如果浏览器允许直接安装，就把下载好的 crx 文件拖进去，按提示确认安装。
4. 如果你的 Chrome 不允许直接安装 crx，可以先把它解压出来，再点“加载已解压的扩展程序”，选择解压后的目录完成安装。

如果你平时也经常在一堆看起来差不多的系统里切来切去，或者也正好被自签名 HTTPS 环境下不太稳定的账号填充体验折腾过，那这个插件也许正好能帮你少踩几个坑。

后面如果我再补一些更顺手的能力，比如更方便的环境切换辅助、更多页面识别细节，或者更适合团队共享的配置方式，我也会继续把它慢慢迭代下去。

这是我当年用过的一台 PSP 3000。机器本身还在，但电池已经鼓包了，原来的山寨记忆棒也基本报废。换了新电池之后，我又买了一个记忆棒卡套，插上一张 TF 卡，总算把这台老机器重新点亮了。

机器能开机只是第一步。真正麻烦的是系统和破解环境都太老了。

我这台机器当年用的是 PRO CFW，那时候还做不到现在这样省心，每次彻底关机后都得重新刷一次。如今旧卡已经不能用了，原来的破解文件自然也跟着没了。于是我顺手查了一下现在 PSP 还在用什么方案，结果发现这个圈子居然一直还在更新。

现在比较成熟的一条路，是先把系统升级到官方最后一个正式版本 6.61，再安装 ARK-4。我这次就是按这个思路做的，整套流程走下来并不复杂，记录一下，后面如果还有人把老 PSP 翻出来，或许也能少踩点坑。

先确认当前系统版本

开机后先到系统信息里看一眼。

我这台机器当时还是 6.35：

如果你的版本也比较老，建议先别急着折腾自制固件，先把官方系统升级到 6.61。这是索尼给 PSP 发布的最后一个官方固件版本，后面很多教程和工具默认也都是围绕 6.61 来写的。

先升级到官方 6.61 固件

官方固件文件现在网上还能找到，我这次用的是这个整理站点：

https://darthsternie.net/psp-firmwares/

找到 6.61 对应的下载链接即可。有条件的话，下载后顺手校验一下文件 hash 会更稳一点。

在拷文件之前，建议先把 TF 卡插进记忆棒卡套，再插到 PSP 里格式化一次。这样目录结构和文件系统都会干净一点，后面少出一些莫名其妙的问题。

下载到的固件文件名一般是 661.PBP。把卡接到电脑后，在卡里创建下面这个目录：

1

/PSP/GAME/UPDATE

然后把 661.PBP 重命名成 EBOOT.PBP，放到这个目录下面。

之后把卡重新插回 PSP，在“游戏”里的 Memory Stick 下就能看到升级程序了：

按提示一路升级即可。整个过程不算久，完成后再看系统信息，就已经是 6.61 了：

这里多提醒一句：升级固件时一定要保证电量充足，最好插着电源，别在刷机过程中断电。

再安装 ARK-4

系统升完之后，就可以开始装 ARK-4 了。

和很多年前在论坛里到处找破解包不一样，现在 ARK-4 的项目和发布版本都在 GitHub 上，资料也比以前集中得多：

• 项目地址：https://github.com/PSP-Archive/ARK-4
• 发布页面：https://github.com/PSP-Archive/ARK-4/releases

按我写这篇文章时的情况，2026-06-01 能看到的最新正式版是 v4.20.69 r206。发布页面里也明确写了，这是 ARK-4 的最后一个官方版本，后续路线会转向 ARK-5。

下载 release 里的 ARK4.zip 即可：

把 ARK-4 文件复制到记忆卡里

把 TF 卡重新接到电脑上，解压 ARK4.zip，然后把里面几个目录复制到对应位置。

需要的主要是这三项：

1. 把 ARK_01234 复制到 /PSP/SAVEDATA/
2. 把 ARK_Loader 复制到 /PSP/GAME/
3. 把 ARK_cIPL 复制到 /PSP/GAME/（注意这个文件夹在压缩包的 PSP 目录下）

前两步是让系统先跑起来，第三步是给后面的永久破解做准备。

先刷入临时 ARK-4

把卡插回 PSP 后，到“游戏”里的 Memory Stick 下面，可以先看到 ARK Loader。

先运行它，把临时固件刷进去：

刷好之后，再进系统信息，版本号会带上 ARK-4 Live 的标识。这时候其实已经可以正常跑游戏和自制程序了，只是如果彻底关机，下次还得重新执行一次 ARK Loader：

再刷入 cIPL，做成永久破解

如果你也想要“重启之后依然保持破解状态”的效果，就继续运行 ARK cIPL Flasher。

进入之后按照界面提示确认安装即可，整个过程很快，我这台机器大概几秒钟就完成了：

刷完之后再次查看系统信息，就能看到版本后面已经带上了 cIPL：

我这台 PSP 3000 到这里就已经实现了重启后依旧保持 ARK 的状态，不需要每次开机再手动刷一次。

游戏文件放哪里

最后一步就简单了。

把下载好的 PSP .iso 或 .cso 游戏文件放到记忆卡根目录下的 ISO 文件夹里即可。如果没有这个目录，自己新建一个就行：

1

/ISO

放好之后，在机器里就能直接看到游戏：

最后

这次把这台老 PSP 重新折腾起来，最大的感受其实不是“破解终于成功了”，而是很多年前那种熟悉的感觉一下子又回来了。

老机器能重新开机、能重新进游戏，已经很开心；而现在这套升级和破解流程，比我当年折腾的时候也确实成熟了不少。至少对我这台 PSP 3000 来说，从官方 6.35 升到 6.61，再刷入 ARK-4，整个过程比预想中顺利很多。

如果你家里也正好还有一台吃灰的 PSP，不妨找个周末把它翻出来试试。说不定折腾完之后，最先被唤醒的不是主机，而是自己很多年前打游戏时的那段记忆。

虽然这两年越来越多的场景开始用云原生方案，比如 Envoy Proxy 之类的组件来替代部分 Nginx 的工作，但回头看下来，很多问题最早还真就是靠 Nginx 先顶上、先跑通的。

所以想趁着还有印象，整理一下这些年在项目里实际用过的几种 Nginx 用法。它们不一定都算“标准答案”，但在真实环境里，确实都解决过问题。

1. 代理 SMTP 服务，让内网服务也能发邮件

这个场景在客户环境里挺常见的。

有些系统部署在内网，业务服务本身不能直接访问外部网络，但偏偏又需要发邮件。长期来看，当然还是应该让对应节点具备访问 SMTP 服务器的能力；但如果只是临时救急，或者短期内没法推动网络策略调整，也可以让 Nginx 先做一层 TCP 代理。

配置大概像这样：

1
2
3
4
5
6
7
8

load_module /usr/lib/nginx/modules/ngx_stream_module.so;

stream {
    server {
        listen 1587;
        proxy_pass mail.example.com:587;
    }
}

这样一来，内网服务就不需要直接连外部 SMTP 服务器了，只要把 Nginx 所在节点 IP + 1587 当成 SMTP 地址使用即可。

这个方案的核心点在于：这里走的不是 HTTP 代理，而是 stream 模块提供的四层转发能力。

如果你用的是 Ubuntu 里通过 apt 安装的 Nginx，通常 ngx_stream_module 都已经编译进去了；如果是自己编译 Nginx，就要确认编译参数里带了 --with-stream。

2. 代理企业微信、钉钉、飞书这类外部通知接口

和发邮件是同一类问题。

很多部署在内网的服务，不只是要发邮件，还要给企业微信、钉钉、飞书这类企业通信工具发通知消息。服务本身出不了网时，也可以把这些请求统一转到一台可访问外网的 Nginx 节点上。

以企业微信机器人为例，它的 Webhook 地址一般长这样：

1

https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=3e8b437b-419f-46b2-9495-391cf17a6719

如果内网服务不能直接访问外网，可以在 Nginx 上做一个反向代理：

1
2
3
4
5
6
7
8

server {
    listen 80;
    server_name wechat-proxy;

    location /cgi-bin/webhook {
        proxy_pass https://qyapi.weixin.qq.com;
    }
}

这样，内网服务发送消息时，就可以把原始地址替换成类似下面这个内部地址：

1

https://wechat-proxy/cgi-bin/webhook/send?key=3e8b437b-419f-46b2-9495-391cf17a6719

本质上，这还是“把不能出网的服务请求，借道一台能出网的节点发出去”。

这种做法的好处是落地快，应用侧改动也不大；缺点也很明显，它更像一种工程上的折中方案。如果后面这类依赖越来越多，还是应该把统一出口、代理策略或者网络规划做得更正式一些。

3. 用 auth_request 给静态资源和内部服务补一层认证

还有一种情况也挺常见：有些内容本身很简单，比如 API 文档、模板文件、安装包，甚至是某个前端直接托管出来的小工具页。开发时大家往往觉得“这就是个静态文件”，于是直接通过 Nginx 暴露了。

但到了客户环境里，这类路径经常会被安全扫描盯上。哪怕文件本身不敏感，只要是“未认证即可访问”，往往就容易被判定为风险项。

这时候，auth_request 就很实用了。它可以让 Nginx 在真正返回资源之前，先去请求一个认证接口，认证通过后再继续返回内容。

例如：

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

location /docs {
    auth_request /auth;
    proxy_pass http://frontend/docs;
    proxy_set_header Host $host;
    error_page 401 = @error401;
}

location = /auth {
    proxy_pass http://backend/auth;
    proxy_pass_request_body off;
    proxy_set_header Content-Length "";
    proxy_set_header X-Original-URI $request_uri;
}

location @error401 {
    return 302 /login;
}

这个思路的好处是，后端只需要提供一个专门的鉴权接口，Nginx 就可以把认证逻辑挂到多个入口前面。

除了静态资源，这个方案也很适合那些“不想自己重复造认证逻辑”的内部服务。服务本身只管功能，对外访问统一经过 Nginx，由 Nginx 先做认证，再把请求放进去。

另外，认证接口还可以顺便返回一些认证后的上下文信息，再由 Nginx 透传给后端使用。比如认证接口返回了用户名：

1
2

auth_request_set $username $upstream_http_x_username;
proxy_set_header X-Username $username;

这样后面的服务就可以直接读取 X-Username，不需要自己再重复解析一遍登录态。

4. 用 add_header Set-Cookie 做一层够用的单点登录

这些年接过不少客户环境里的单点登录需求，最大的感受其实不是“标准方案很多”，而是“真正完全按标准落地的并不多”。

很多项目一到集成阶段，认证链路里总会被加上各种定制要求。理论上可以讲 OAuth2、OIDC、SAML，但真到现场，往往还是得围着客户现有流程做适配。

在这种背景下，我们有时会采用一个比较直接的办法：让系统后端先为指定用户创建好登录态，再通过 Nginx 返回 Set-Cookie，把 session 强行种到当前域下，达到“点一个链接就登录”的效果。

假设系统用 session_key 这个 Cookie 保存登录态，那么可以在 Nginx 里加一个类似的入口：

1
2
3
4

location ~ ^/set-session/(?<session_key>\w+)$ {
    add_header Set-Cookie "session_key=$session_key; HttpOnly; Max-Age=21600; Path=/; SameSite=Lax";
    return 302 /;
}

配合方式也很直接：

1. 业务后端提供一个管理员接口，用来为指定用户创建 session。
2. 这个接口返回生成好的 session_key。
3. 调用方把 session_key 拼到 /set-session/<session_key> 这个地址里。
4. 用户浏览器访问该地址后，Nginx 回写 Cookie，并跳转到首页。

例如系统地址是：

1

http://example.com

如果生成的 session_key 是：

1

d79769307e7e443ca7abfd780e89217e

那么最终访问的地址就会是：

1

http://example.com/set-session/d79769307e7e443ca7abfd780e89217e

浏览器访问后，就会在当前域下写入对应的 session_key，随后跳回首页，从用户视角看起来就像一次“无感登录”。

这套方式当然谈不上通用，也不一定适合所有系统，但在一些强定制、强集成、时间又比较紧的项目里，确实很好用。它最大的价值不在于优雅，而在于实现简单、改动集中，而且足够可控。

最后

回头看这些例子，会发现 Nginx 在项目里真正有价值的地方，往往不是“它能不能把请求转过去”，而是它能不能在系统边界上帮你快速补上一层能力。

有时候是补网络出口，有时候是补认证，有时候是补一段不那么标准、但又必须落地的集成逻辑。

所以我现在对 Nginx 的感觉一直挺朴素的：它未必是每个问题的最终解法，但在很多实际项目里，它确实是那个最先把事情顶起来的工具。

如果你用的是 iPhone，那准备一个美区 Apple 账号，基本就成了绕不过去的事。

我这次用下来，比较省事的一条路不是直接注册美区账号，而是先搞一个全新的国区账号，再把地区切到美国。这样至少不用一上来就想办法找美国手机号接码，整体会顺不少。

先说两个前提：

1. Apple 这类策略变得挺快的，今天能走通，不代表之后一直都能走通。
2. 最好直接用新号折腾。老号如果挂着订阅、余额或者购买记录，换区的时候往往会很麻烦。

Apple 账号注册地址：

https://account.apple.com/account

先注册一个新的国区账号

不要一开始就直接选美国地区注册。现在如果这么干，很多时候会要求你用美国手机号验证，门槛一下就上去了。

所以更稳一点的办法，是先正常注册一个国区账号，用自己的手机号完成验证。

在 iPhone 上登录这个新账号

注册完之后，打开 iPhone 上的 App Store，点右上角头像进去。

先把当前正在用的账号退出掉，再登录刚注册的这个新账号。

登进去之后可以先看一眼区域，这时候正常还是中国区。

再把地区切到美国

这一步才是关键。

切之前，一定注意要让手机全局翻墙到美国 IP，然后再进入账号设置里的“国家/地区”，把地区改成“美国”。

这里最重要的是“付款方式”这一项。如果你能看到“无”，直接选“无”就行，这样就不用填信用卡或者 PayPal 了。

如果没有看到“无”，那就表明你的 IP 还没翻到美国，可以检查下当前的网络，不行重启试试。

另外有几个细节也顺手注意一下：

1. 账单地址可以找个美国地址生成器随便生成一个能用的。
2. 最好选免税州，比如俄勒冈州，后面真要付费会省一点事。
3. 名字也尽量写成英文，能少掉一些奇怪的校验问题。

把这些都填完保存，如果没报错，基本就已经切到美区了。

看下是不是已经变成美区了

切完以后再回到 App Store 搜一下，一般就能看到国区里没有的应用了，比如 ChatGPT 和 Gemini。

像 Apple Arcade 这种内容，这时候通常也已经能看到了。

顺便说一句，应用下载的时候一般不需要一直全局代理，所以也不用太担心流量问题。

最后补几句

1. 这个美区账号的密码一定要记好，后面更新应用时大概率还会让你重新登录。
2. 这种口子什么时候被 Apple 收紧不好说，能注册的时候尽早注册。
3. 如果你只是为了下载少数几个应用，平时把主账号和这个外区账号分开用，会省心很多。

如果你的目的就是装个 ChatGPT、Gemini 之类的应用，这套办法现在看下来还是比较直接的。

于是这次我换了个思路：不如直接用 Codex 来一把 vibe coding，把这些高频小工具收拢成一个自己看着顺眼、用起来顺手的小站。

它现在就在这里：

https://tools.knktc.com

先放一张首页截图：

这个站目前不追求“大而全”，更像一个我自己会长期开着用的工具抽屉。思路很简单：

1. 常用的小工具尽量放在一个页面里，少跳转，少找书签。
2. 能在浏览器本地完成的事情，就尽量本地完成。
3. 少一点花里胡哨，多一点“打开就能用”。

现在已经放进去的工具，基本都是平时开发和排查时最容易顺手掏出来的那些，比如：

• 客户端 IP
• IP 与掩码检查
• Base64 转换
• JSON Pretty
• URL 编解码
• 时间戳转换
• 本地时间检测
• 浏览器信息与时区
• UUID 生成器

其中有几个我自己还挺喜欢。

先说“本地时间检测”。这个工具是拿浏览器当前时间去和服务端标准时间做对比，适合排查一些看起来莫名其妙、实际上和时间有关的问题，比如登录异常、接口签名失效、证书时间不对之类。

这种工具的乐趣就在于：平时你未必天天用，但真碰上问题的时候，它能帮你少绕两圈。

另一个我挺常用的是“浏览器信息与时区”。有时候用户反馈“我这里时间不对”“页面显示怪怪的”“怎么跟你那边不一样”，很多时候先看一下浏览器时区、语言、UA、屏幕尺寸，心里就会有底。

而且这块我顺手把 Clock drift 也塞进去了。也就是说，不只是看浏览器报了什么，还能顺便看一下它和服务端参考时间差了多少毫秒。这个细节很小，但排查起来挺省心。

这次用 Codex 来做，体验也挺有意思。和传统那种“先列个很完整的需求文档，再慢慢开工”的方式相比，vibe coding 更像是：

• 先把想法说清楚；
• 再让 Codex 一边写，一边改，一边对齐细节；
• 不满意就继续调，直到页面、交互和功能都顺眼为止。

整个过程有点像和一个不会喊累的搭子结对编程。你负责提出“这个地方应该再顺一点”“这里应该更直观”，它负责快速把想法变成能跑的东西。节奏对了以后，推进速度确实很舒服。

当然，这个站现在也还远没到“完成体”。我更愿意把它当成一个会持续长大的小工具箱：谁知道后面还会不会继续往里面塞一些更奇怪但又真的有用的小玩意。

如果你也刚好经常要查这些东西，可以直接收藏一下：

https://tools.knktc.com

至少以后想查个 IP、转个时间戳、看下本地时间是不是飘了，不用再满世界翻页面了。

1

Co-authored-by: Copilot <copilot@github.com>

现象大概是这样：

我第一反应是：原来微软又偷偷搞了点小动作。

这个设置的意思是，当你使用 VS Code 里的 Copilot Chat 或 Agent 参与代码修改并提交时，VS Code 会自动给 commit message 加上 AI co-author 信息。对于某些协作场景，这也许算是一种透明披露；但对于日常个人提交来说，它很容易让提交历史变得有点吵，而且这个行为默认开启时并不算特别显眼。

关闭方法也很简单：

1. 打开 VS Code Settings。
2. 搜索 Add AI Co Author。
3. 找到 Git: Add AI Co Author。
4. 将默认的 chatAndAgent 改成 off。

配置界面如下：

改完以后，再通过 VS Code 提交代码，就不会继续自动追加这行：

1

Co-authored-by: Copilot <copilot@github.com>

如果团队本来就希望保留 AI 参与痕迹，那可以继续开着；如果只是想保持提交信息干净一点，把它关掉就好。

如果你经常需要验证第三方回调、调试自建服务的入站请求，或者只是想临时抓一把 HTTP 请求看看内容，那它应该会很顺手。

这个项目是做什么的

tiny-requestbin 是一个 轻量级 HTTP 请求检查与调试工具。启动之后，它会捕获发往当前服务的 HTTP 请求，并把这些请求展示出来，方便开发者查看：

• 请求方法
• 请求路径
• 请求头
• 请求体
• 以及整体请求的详细内容

项目当前的几个核心特点也在 README 里写得很清楚：

• 轻量且快速：实现简单，依赖极少
• 请求检查：可以查看传入 HTTP 请求的详细信息
• Web 界面：通过浏览器查看捕获的请求
• CLI 模式：也可以直接在终端打印请求内容
• 本地运行：所有数据都留在本机，无需依赖外部服务

我自己很喜欢这类“功能边界清晰”的工具：不追求大而全，而是把“看请求”这件事做好。

安装方式很全

tiny-requestbin 的仓库首页提供了几种常见安装方式，基本覆盖了本地调试和服务部署的主要场景。

1. Docker 方式

如果只是想快速跑起来，README 推荐直接使用 Docker：

1

docker run -p 8282:8282 knktc/tiny-requestbin

也可以带上自定义参数运行，例如自定义监听地址、端口和最大保存请求数：

1

docker run -p 8282:8282 knktc/tiny-requestbin -port 8282 -listen 0.0.0.0 -max 1000

此外仓库里也提供了 docker-compose.yml，所以用 docker-compose up -d 也能直接启动。

2. Helm 安装

如果你有 Kubernetes 环境，项目还提供了 Helm Chart，可以直接安装：

1

helm install my-requestbin helm/tiny-requestbin/

README 里还给了自定义 config.max、service.type 和启用 HTTPRoute 的示例，对 K8s 用户来说很友好。

3. go install

既然它本身就是 Go 项目，直接安装也很自然：

1

go install github.com/knktc/tiny-requestbin@latest

4. 从源码构建

如果你想自己编译，也很简单：

1
2
3

git clone https://github.com/knktc/tiny-requestbin.git
cd tiny-requestbin
go build

怎么使用

项目默认启动方式非常直接：

1

tiny-requestbin

默认参数如下：

• -port：监听端口，默认 8282
• -listen：监听地址，默认 127.0.0.1
• -max：最大保存请求数量，默认 100
• -cli：是否启用 CLI 输出模式，默认 false

比如下面这个命令，会把服务监听在 0.0.0.0:9000，最多保存 1000 条请求，同时把请求内容打印到终端：

1

tiny-requestbin -port 9000 -listen 0.0.0.0 -max 1000 -cli

它的工作流程也很简单：

1. 启动服务
2. 把请求发到 http://[监听地址]:[端口]/任意路径
3. 在浏览器访问根路径查看已捕获请求
4. 如果开启了 -cli，终端里也会同步输出请求内容

这意味着它既适合本地临时排查，也很适合作为内网环境中的一个“小型请求接收站”。

两种使用体验：终端和 Web

仓库首页给了两张截图，我也顺手放到这篇文章里，方便直接感受它的实际效果。

CLI 模式截图

启用 -cli 后，收到的 HTTP 请求会直接以格式化后的方式打印在终端里：

这个模式特别适合在服务器、容器或远程终端里快速观察请求，不需要额外打开浏览器。

Web 界面截图

如果更喜欢图形化浏览方式，可以直接访问 Web 页面查看历史请求：

从截图来看，界面风格非常克制，重点就是把请求内容清楚地展示出来，没有多余干扰。

适合哪些场景

结合仓库首页信息，我觉得 tiny-requestbin 很适合下面这些场景：

• 调试第三方平台的 Webhook 回调
• 验证某个服务到底发了什么 HTTP 请求
• 本地开发时快速搭一个请求接收端
• 在容器/Kubernetes 环境中临时观察请求流量
• 在终端环境下通过 -cli 模式直接查看请求细节

尤其是它强调 Local Only，所有数据都保留在本机，这一点对很多内部调试场景来说非常安心。

额外值得一提的几点

GitHub 页面里还有几个我觉得挺加分的信息：

• 项目镜像支持 多架构，包括 linux/amd64 和 linux/arm64
• 多架构镜像会通过 GitHub Actions 自动构建发布
• 仓库里同时提供了 Docker、Helm、源码构建几种入口
• 项目采用 MIT License，使用和二次分发都比较友好

另外，README 里还提到这个项目最开始由 Gemini 起步，后续由 GitHub Copilot 持续修改，这一点也挺符合这个项目本身“轻量、直接、快速迭代”的气质。

最后

如果你正好在找一个 Go 写的、轻量、可本地运行、同时支持 Web 和 CLI 的 HTTP 请求调试工具，那我觉得 tiny-requestbin 值得试一试。

项目地址：

• GitHub: https://github.com/knktc/tiny-requestbin

欢迎去点个 star，也欢迎提 Issue 或 PR，一起把这个小工具打磨得更顺手。

查了下官方文档才发现，pymemcache 默认情况下遇到连接失败就是会抛出异常，除非是手动指定下 ignore_exc = True。

于是，将 Django CACHES 的配置修改成这样，在 OPTION 中加入相关配置就好了：

1
2
3
4
5
6
7
8
9
10
11

CACHES = {
    'default': {
        'BACKEND': 'django.core.cache.backends.memcached.PyMemcacheCache',
        'LOCATION': [
            'host1:11211',
            'host2':11211,
        ],
        'OPTIONS': {
            'ignore_exc': True,  # 设置成 True
        }
    }

申威架构的CPU与ARM架构的CPU不同，更加小众，国内也就UOS和Kylin对其有支持。客户提供的操作系统是Kylin V10的SW_64版本，本文就记录下在这个架构CPU+Kylin V10环境下装Pandas遇到的问题。

创建venv

Kylin V10自带的python3版本是3.7.4，先创建个venv:

1
2

python3 -m venv --copies knktc-env
source knktc-env/bin/active

安装numpy

下意识地直接用pip来安装numpy:

1

pip install numpy

一顿输出后，报错了：

error: #error Unknown CPU, please report this to numpy maintainers with information about your platform (OS, CPU and compiler)

果然有够小众的，识别不出来这个CPU，所以编译无法进行。

网上查了半天，在UOS的论坛上发现有人讨论过，说无法用pip来编译，只能下载UOS预编译好的包。然后在Kylin这个系统上也搜索了下，果然有：

1
2
3
4
5
6

yum search numpy

输出：
Last metadata expiration check: 5 days, 16:43:36 ago on Fri 05 May 2023 04:06:16 PM CST.
============================================================== Name Matched: numpy ===============================================================
python3-numpy.sw_64 : A fast multidimensional array facility for Python

于是先装下这个系统厂商提供的包：

1

yum install python3-numpy

装好后需要手动拷贝下，把装到系统目录中的numpy给拷到venv中：

1

cp -r /usr/lib/python3.7/site-packages/numpy* knktc-env/lib/python3.7/site-packages

尝试看下版本:

1
2
3

>>> import numpy
>>> numpy.__version__
'1.16.5'

好了，先把numpy的问题给解决了。

安装Pandas

要安装Pandas的话，这一步只好使用源码来编译了。

先把依赖给装下：

1
2
3
4
5

pip install setuptools --upgrade -i https://pypi.tuna.tsinghua.edu.cn/simple
pip install wheel --upgrade -i https://pypi.tuna.tsinghua.edu.cn/simple
pip install Cython --upgrade -i https://pypi.tuna.tsinghua.edu.cn/simple
pip install pytz==2018.7 -i https://pypi.tuna.tsinghua.edu.cn/simple
pip install python-dateutil -i https://pypi.tuna.tsinghua.edu.cn/simple

然后去以下地址下载源码包：

https://github.com/pandas-dev/pandas/releases

我们还在用1.1.5版本，就用这个地址来下载：

https://github.com/pandas-dev/pandas/releases/download/v1.1.5/pandas-1.1.5.tar.gz

下载后解压，随后进入到目录用最传统的方式安装即可：

1
2

cd pandas-1.1.5/
python setup.py install

注意，这个过程有点漫长，建议开个screen来进行编译安装。

虽然过程漫长，但居然没啥报错地就完成了。

最后再试试panda的版本：

1
2
3

>>> import pandas
>>> pandas.__version__
'1.1.5'

嗯，应该可以了。

1
2
3
4

Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights

在反复确认自己的公钥已经放到gitlab上后，开始google，参考了下网上的讨论：https://superuser.com/questions/1749364/git-ssh-permission-denied-in-macos-13-ventura

应该是因为mac os 13中自带的OpenSSH_9.0p1默认禁止了RSA/SHA-1算法导致的。

解决方法的话，要么是生成一个新的ssh密钥，替换下（成本可能有点高）：

1

ssh-keygen -t ed25519

要么就是编辑 ~/.ssh/config配置文件，在文件中加入以下的配置即可(还可以应对服务端太老不支持新的加密算法的情况)：

1
2
3

Host *
    HostkeyAlgorithms +ssh-rsa
    PubkeyAcceptedAlgorithms +ssh-rsa

1
2
3
4

memcache.py:1303: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if key is '':
memcache.py:1304: SyntaxWarning: "is" with a literal. Did you mean "=="?
  if key_extra_len is 0:

查了下python-memcached的源码(其实也就一个文件)，定位到1303和1304行，代码如下：

1
2

if key is '':
    if key_extra_len is 0:

看来这样的使用方法在python3.8里面是不被接受的。

虽然只是warning，但日志中打印这些信息总归让人感觉很不爽，所以得想法修复下。

查到官方的github仓库，发现这个库已经有年头没有人管了，即使有人提出了修改的PR(https://github.com/linsomniac/python-memcached/issues/176)，也没有人来合并。

于是两条路：

1. 在项目中直接修改memcache.py文件，改掉这两行的问题，把is改成==就可以了。
2. 因为我们会发个requirements.txt，所以我自己做了个修改的版本，放到了pypi上(https://pypi.org/project/python-memcached-py38fix/)，如果有需要的可以直接下载：

1

pip install python-memcached-py38fix

看来下一步必须得考虑换成pymemcache了，毕竟Django都抛弃了对python-memcached的支持了。

1
2
3

location ~ ^/myconf/(?<filename>.*)$ {
    alias /home/knktc/myconf/$filename;
}

但是问题来了，如果匹配不到配置文件的话，直接返回的是nginx的404页面，为了能让前端代码更容易地处理下这种情况，可以加点配置，让文件找不到的时候直接返回空的json对象，于是配置可以改成下面的这样:

1
2
3
4
5
6
7
8
9

location ~ ^/myconf/(?<filename>.*)$ {
    alias /home/knktc/myconf/$filename;
    error_page 404 = @not_found_fallback;
}

location @not_found_fallback {
        add_header Content-Type text/plain;
        return 200 "{}";
}

现在的话，如果文件不存在的话，就可以返回一个空的json对象了。

但是问题又来了：这种情况下nginx的error.log里面又记录了一次404的错误事件，于是还需要继续改下配置，把not found的日志给关掉：

1
2
3
4
5
6
7
8
9
10

location ~ ^/myconf/(?<filename>.*)$ {
    alias /home/knktc/myconf/$filename;
    error_page 404 = @not_found_fallback;
    log_not_found off;
}

location @not_found_fallback {
        add_header Content-Type text/plain;
        return 200 "{}";
}

这下就OK了。使用Nginx静态文件能力来做一些简单的接口还是很方便的。

本文用的操作系统是ubuntu 20.04，DNS的话用的是Cloudflare的服务，web服务使用nginx来提供。然后，按照以下步骤进行就可以了。

安装Certbot

用以下命令安装就可以了，某些时候snap install的时候可能比较慢，有时候还可能需要重试几次：

1
2
3
4

apt install snapd
snap install core
snap refresh core
snap install --classic certbot

安装完成后，运行下certbot --version命令，如果有版本号输出，就表明安装成功了。

安装Cloudflare插件

为了实现自动化地续签证书，需要安装下对应DNS服务商的插件才可以。我使用Cloudflare来做DNS解析，所以可以使用以下的命令来安装Cloudflare插件：

1
2
3

snap set certbot trust-plugin-with-root=ok

snap install certbot-dns-cloudflare

设置Cloudflare API令牌

要使用Cloudflare插件，需要先登录到Cloudflare控制台来生成一个仅可操作DNS解析的API 令牌。可在登录Cloudflare后，跳转到这个地址来进行创建：https://dash.cloudflare.com/profile/api-tokens

以下是操作过程的简单演示：

创建完成后记得将出现的令牌复制下来。然后使用以下命令来创建配置文件：

1
2
3

mkdir -p ~/.secrets/certbot

vim ~/.secrets/certbot/cloudflare.ini

填入如下格式的配置就可以了：

1

dns_cloudflare_api_token = 刚才获取到的API令牌

编辑完成后，可以修改下这个文件的权限，否则执行certbot命令时会报一个警告说文件权限不安全：

1

chmod 600 ~/.secrets/certbot/cloudflare.ini

获取证书

现在通过运行以下的命令就可以生成nginx所需的证书了：

1
2
3
4
5

certbot certonly \
  --dns-cloudflare \
  --dns-cloudflare-credentials ~/.secrets/certbot/cloudflare.ini \
  --dns-cloudflare-propagation-seconds 60 \
  -d knktc.com

注意，这里用了--dns-cloudflare-propagation-seconds 60把等待时间延长到了60秒，否则默认的10秒有些时候会导致校验失败。

生成的证书和私钥会放到/etc/letsencrypt/live/YOUR_HOST目录下。

贴一段nginx相关配置，备查：

1
2
3
4
5
6
7
8
9

listen 443 ssl http2;
server_name knktc.com;
ssl_certificate /etc/letsencrypt/live/knktc.com/fullchain.pem; # managed by Certbot
ssl_certificate_key /etc/letsencrypt/live/knktc.com/privkey.pem; # managed by Certbot

ssl_protocols       TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers         HIGH:!aNULL:!MD5;
keepalive_timeout   70;
ssl_session_timeout  5m;

定时任务

通过以下命令可以查看certbot的定时任务是否添加成功了：

1

systemctl list-timers

如果要在每次生成新的证书后自动reload下nginx，可以加个hook脚本：

1

vim /etc/letsencrypt/renewal-hooks/post/reload-nginx

加入以下的脚本：

1
2
3

#!/bin/sh

systemctl reload nginx

然后给这个脚本文件加上权限：

1

chmod +x /etc/letsencrypt/renewal-hooks/post/reload-nginx

这样的话，每次生成新的证书后，就会自动reload下nginx让新的证书生效了。

1

pip config --user setglobal.index-url https://pypi.tuna.tsinghua.edu.cn/simple

然后下载安装脚本到本地(比如保存成install-poetry.py文件)：

1

curl -sSL https://install.python-poetry.org -o install-poetry.py

打开脚本进行编辑，找到如下这段代码：

1
2

def pip(self, *args, **kwargs) -> subprocess.CompletedProcess:
        return self.python("-m", "pip", "--isolated", *args, **kwargs)

把里面的”–isolated”删除掉，然后安装脚本使用pip时就会自动使用之前配置好的镜像了:

1

python3 install install-poetry.py

为了测试下广播任务的效果，先写个示例任务：

1
2
3
4
5
6
7
8
9

# filename: agent.py
import datetime
from celery import shared_task

@shared_task(bind=True)
def test(self):
    name = self.request.hostname
    with open(f'/tmp/{name}', 'w') as f:
        f.write(str(datetime.datetime.now()))

稍微解释下，test这个任务会获取执行该任务的worker的hostname，然后以该hostname为文件名在/tmp目录下创建出来文件，文件中包含有执行任务的时间。

也就是说，如果测试ok的话，在这个test任务执行的时候，在/tmp目录下应该会同时生成多个文件：有几个worker绑定到这个队列就会有几个文件。

然后在celery的app配置代码中加入以下的代码：

1
2
3
4
5
6
7
8
9

from kombu.common import Broadcast

app.conf.task_queues = (Broadcast('broadcast_tasks'),)
app.conf.task_routes = {
    'agent.test': {
        'queue': 'broadcast_tasks',
        'exchange': 'broadcast_tasks'
    }
}

这里定义了一个名为broadcast_tasks的队列，然后agent.test的任务都会通过broadcast_tasks这个exchange来发出。

在celery worker方面，试着启动这么两个worker绑定broadcast_tasks队列，这两个worker一个叫agent1，一个叫agent2：

1
2

celery -A boss2_manager worker --pidfile=/var/run/celeryworker_agent1.pid -Q broadcast_tasks -n agent1@%h
celery -A boss2_manager worker --pidfile=/var/run/celeryworker_agent2.pid -Q broadcast_tasks -n agent2@%h

celery worker启动后，如果使用了RabbitMQ作为broker的话，可以在管理界面中看到，广播类型的队列对于RabbitMQ来说就是一个fanout类型的exchange外加多个队列：启动一个worker就创建一个队列绑定到这个fanout exchange上。

试着直接用delay方法调用下这个test任务：

1
2
3

from agent import test

test.delay()

然后去/tmp目录下看看，发现已经出现了两个文件，命名分别为：

1
2

agent1@knktc-rmbp.local
agent2@knktc-rmbp.local

打开文件看看内容，两个文件中记录的时间相差不大。

OK，就用这个方法来做Agent吧。

参考

• Celery Broadcast的官方文档(吐槽下，最近官方把原来的celeryproject.org域名给搞丢了，最后只好搞了个新的~)：https://docs.celeryq.dev/en/stable/userguide/routing.html#broadcast

配置前

在进行配置前，可以先尝试运行下snmptranslate命令(注意，这里的-L n参数可以忽略输出的错误信息)：

1

snmptranslate -L n .1.3.6.1.4.1.25506.2.38.1.6.3.0.1

这个示例中的OID来自H3C的交换机设备，如果没导入MIB库的话，结果只会是：

1

SNMPv2-SMI::enterprises.25506.2.38.1.6.3.0.1

很明显，光看这个还是没法知道设备发了个啥信息过来。

导入和配置

先从H3C官方搞到MIB库文件，然后把这些mib文件解压到一个目录中。在这个示例中，我们把这些mib文件都放置到/usr/share/mibs/h3c_mibs目录下。

放好MIB库文件后，就可以开始配置snmp.conf这个配置文件了：

1

vim /etc/snmp/snmp.conf

(如果没有这个文件，可能需要先使用apt install snmp命令来安装下相关的组件。)

配置文件中原始的配置内容是这样的：

1
2
3
4

# As the snmp packages come without MIB files due to license reasons, loading
# of MIBs is disabled by default. If you added the MIBs you can reenable
# loading them by commenting out the following line.
mibs :

为了能让新加的MIB库生效，需要做下修改：

1
2
3
4
5
6

# mibs :

mibdirs +/usr/share/mibs/h3c_mibs
mibdirs +/usr/share/mibs/another_mib_dir  # for example

mibs +ALL

稍微解释下：

• 注释掉了原有的mib : 这行，让系统可以加载第三方的库；
• mibdirs参数用于指定加载的MIB库路径，如果有多个MIB库的目录，可以多次使用这个参数
• mibs +ALL参数指定了在所有的mib文件中来进行查找。

配置文件修改完成后，保存退出即可，无需重启啥服务。

测试

再次测试翻译OID，在正确放置mib文件和正确配置的情况下，是可以成功翻译出结果的：

1
2

root@knktc.com:/root# snmptranslate -L n .1.3.6.1.4.1.25506.2.38.1.6.3.0.1
HH3C-TRAP-MIB::hh3cPeriodicalTrap

参考

• telegraf的snmp trap插件官网是：https://github.com/influxdata/telegraf/tree/master/plugins/inputs/snmp_trap
• snmp.conf配置文件的更多内容可参考man page的帮助：https://linux.die.net/man/5/snmp.conf

以下的示例假设我们要访问的git服务器地址为：gitlab.knktc.com 。

首先使用以下命令创建一个新的SSH密钥对：

1
2

mkdir -p /home/knktc/gitlab_ssh_keys
ssh-keygen -f /home/knktc/gitlab_ssh_keys/id_rsa

这个示例中，新的SSH私钥已经存储到了/home/knktc/gitlab_ssh_keys/id_rsa这个路径了。

然后在当前用户的根目录下创建ssh config文件：

1

vim ~/ssh/config

填入以下的配置：

1
2

Host gitlab.knktc.com
    IdentityFile /home/knktc/gitlab_ssh_keys/id_rsa

这个配置的意思是：如果使用ssh访问主机名为gitlab.knktc.com，则使用刚才新创建的密钥。

最后测试下clone项目：

1

git clone git@gitlab.knktc.com:blog/knktc-com.git

OK，已经成功了。

更多关于ssh config配置文件的细节，可参考：https://linux.die.net/man/5/ssh_config

阅读了下celery beat的源码，使用celery命令行工具启动beat worker的时候，调用的是celery.beat下的Service类中的start方法，应该只需要修改下这里，让beat空跑起来就可以了。

简单写了下Monkey Patch相关的代码，贴出来如下：

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

import os
import time
from celery.beat import info, debug, humanize_seconds, signals, platforms

STANDBY_CHECK_INTERVAL = 5

def is_standby():
    return True if os.path.isfile('/tmp/standby.flag') else False

def patched_start(self, embedded_process=False):
    """ monkey patched start method, will skip tasks when standby flag is setted """
    info('beat: Starting...')
    debug('beat: Ticking with max interval->%s',
          humanize_seconds(self.scheduler.max_interval))

    signals.beat_init.send(sender=self)
    if embedded_process:
        signals.beat_embedded_init.send(sender=self)
        platforms.set_process_title('celery beat')

    try:
        while not self._is_shutdown.is_set():
            
            # patch starts from here
            if is_standby():
                debug(f'beat: in standby mode, all tasks will be skipped, '
                      f'will check in [{STANDBY_CHECK_INTERVAL}] seconds')
                time.sleep(STANDBY_CHECK_INTERVAL)
                continue
            # patch ends
            
            interval = self.scheduler.tick()
            if interval and interval > 0.0:
                debug('beat: Waking up %s.',
                      humanize_seconds(interval, prefix='in '))
                time.sleep(interval)
                if self.scheduler.should_sync():
                    self.scheduler._do_sync()
    except (KeyboardInterrupt, SystemExit):
        self._is_shutdown.set()
    finally:
        self.sync()

简单说明下：

• 这个示例中检查了/tmp目录中是否有standby.flag文件，如果有的话就算是进入了待命的状态；
• 在while循环中先检查了这个文件是否存在，如果存在，则sleep 5秒钟，然后再次检查。

在使用的时候只需要在代码入口处应用这个patch就可以了，例如：

1
2
3

from celery.beat import Service

Service.start = patched_start

测试运行下，当celery beat启动后，只需要touch /tmp/standby.flag，创建标志文件，可以看到celery beat进入待命模式，不再生成定时任务。删除这个文件后，等待几秒钟，celery beat将会继续开始生成定时任务。

怪不得我的blog来源基本都是google和bing，合着百度完全没收录过我的文章~那就只好主动提交咯，但是查了半天，百度也没有google这种主动提交sitemap的接口，只有一个接口来接收url。只好边吐槽百度资源站的原始，边写点东西，让这个博客可以通过github actions来给百度提交sitemap。

准备脚本

先使用python编写一个脚本，可以解析指定的sitemap.xml文件，提取其中的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
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

#!/usr/bin/env python3

"""
向百度提交sitemap的脚本

visit: https://knktc.com

@author:knktc
@contact:me@knktc.com
@create:2022-02-12 22:49
"""

import time
import argparse
from urllib import request
from urllib.parse import urljoin
import xml.etree.ElementTree as ET


def chunker(seq, size):
    """ iterate list by chunk """
    return (seq[pos:pos + size] for pos in range(0, len(seq), size))


class BaiduSubmitter:
    def __init__(self, site: str, token: str, sitemap: str):
        self.submit_url = self.gen_submit_url(site, token)
        self.sitemap_url = self.gen_sitemap_url(site, sitemap)

    @staticmethod
    def gen_submit_url(site: str, token: str) -> str:
        """ generate url to submit to """
        return f'http://data.zz.baidu.com/urls?site={site}&token={token}'

    @staticmethod
    def gen_sitemap_url(site: str, sitemap: str) -> str:
        """ generate url path to get sitemap """
        return urljoin(site, sitemap)

    @staticmethod
    def get_links_from_sitemap(sitemap_url) -> list:
        """ download sitemap, parse and get urls """
        with request.urlopen(sitemap_url) as resp:
            data = resp.read()

        root = ET.fromstring(data)
        return [_.text for
                _ in root.findall('./{http://www.sitemaps.org/schemas/sitemap/0.9}url/{http://www.sitemaps.org/schemas/sitemap/0.9}loc')]

    @staticmethod
    def submit(submit_url: str, links: list):
        """ submit to baidu """
        data = '\n'.join(links).encode('utf8')
        req = request.Request(submit_url, data=data)
        return request.urlopen(req).read().decode()

    def run(self, chunk_size=20, sleep_time=0.1):
        """ submit process """
        links = self.get_links_from_sitemap(self.sitemap_url)
        print(f'Get {len(links)} links from sitemap: [{self.sitemap_url}]')

        for chunk in chunker(links, chunk_size):
            resp = self.submit(self.submit_url, chunk)
            print(resp)
            if sleep_time:
                time.sleep(sleep_time)

            time.sleep(1)


def get_args():
    """ get cli args """
    parser = argparse.ArgumentParser(description='Submit sitemap to Baidu')
    parser.add_argument('--site', '-s', type=str, dest='site', required=True,
                        help='your site, eg: https://knktc.com')
    parser.add_argument('--token', '-t', type=str, dest='token', required=True,
                        help='baidu ziyuan token, you may find your token in https://ziyuan.baidu.com/linksubmit')
    parser.add_argument('--sitemap', '-p', type=str, dest='sitemap', default='sitemap.xml',
                        help='url path to get sitemap.xml file, default: sitemap.xml')
    parser.add_argument('--chunk', '-c', type=int, dest='chunk_size', default=100,
                        help='how many urls should be submitted each time')

    args = parser.parse_args()

    return args


def main():
    """
    main process

    """
    args = get_args()
    site = args.site
    token = args.token
    sitemap_path = args.sitemap
    chunk_size = args.chunk_size

    submitter = BaiduSubmitter(site, token, sitemap_path)
    submitter.run(chunk_size=chunk_size)


if __name__ == '__main__':
    main()

这个脚本编写的时候都使用了标准库的东西，不需要再安装额外的依赖了。

可以把这个脚本保存到本地，使用的时候，先在百度搜索资源平台获取到资源提交用的token(就是这个地方https://ziyuan.baidu.com/linksubmit)，然后按照以下形式来进行请求就可以了：

1

python3 baidu_submit.py --site https://knktc.com --token AABBCCDD --sitemap sitemap.xml --chunk 100

对命令中的几个参数简单说明下：

• –site(或是-s)：这个用来指定blog的网址；
• –token(或是-t): 用来指定刚才获取到的token；
• –sitemap(或是-p): 可以指定下sitemap的路径，比如我的sitemap在https://knktc.com/sitemap.xml，那这里就可以写sitemap.xml就可以了；
• –chunk(或是-c): 这个地方用来指定给百度发送请求时每批传多少个url过去，默认是100个。

运行的结果类似下面的样子：

1
2
3
4

Get 235 links from sitemap: [https://knktc.com/sitemap.xml]
{"remain":2585,"success":100}
{"remain":2485,"success":100}
{"remain":2450,"success":35}

为了方便分享和维护，我也把这个脚本放到了github gist上，地址是: https://gist.github.com/knktc/846950067e60a92612c1befbe4213a32

后面在github上写workflow的时候直接拉取这个脚本就可以了。

Github Actions

在hexo中添加github actions的配置文件有点小技巧，请先参考我之前写的一篇blog：Hexo博客使用GitHub Actions来自动提交Sitemap 。

这次可以添加一个baidu_sitemap.yml的配置文件：

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

# workflow to summit urls from sitemap to baidu

name: Submit baidu Sitemap

on:
  schedule:
    - cron: '15 2 * * *'

jobs:
  submit:
    runs-on: ubuntu-latest

    steps:
      - name: get gist
        uses: andymckay/get-gist-action@0.1
        with:
          gistURL: https://gist.github.com/knktc/846950067e60a92612c1befbe4213a32
      
      - name: run script
        env:
          BAIDU_TOKEN: ${{ secrets.BAIDU_TOKEN }}
        run: python3 /tmp/baidu_submit.py --site https://knktc.com --token $BAIDU_TOKEN

在这个任务配置中有几个点：

• 我们指定了UTC时间每天的2:15(也就是北京时间的10:15)运行任务；
• 运行的脚本是直接从gist上拉取的，没有放到hexo的项目中；
• 运行脚本时用的百度token需要先在项目的settings中配置下secrets，参考下面的图片设置即可：

然后就可以使用github workflow每天自动给百度提交url了。

到网上查了下nginx etag的算法，才发现，nginx是通过文件的大小和文件的修改时间来计算etag的，nginx的源码中ngx_http_set_etag函数中有这样的代码：

1
2
3
4
5
6

etag->value.len = ngx_sprintf(etag->value.data, "\"%xT-%xO\"",
                                  r->headers_out.last_modified_time,
                                  r->headers_out.content_length_n)
                      - etag->value.data;

    r->headers_out.etag = etag;

完整的源码可参考：https://github.com/nginx/nginx/blob/1f01183b9e6658749934313fd72f7f16c1918b54/src/http/ngx_http_core_module.c#L1673

这样看来，两个nginx返回的etag不同，可能就是因为两边文件的修改时间不同。

变更文件的修改时间还是挺容易的，可以直接用touch命令。在touch命令的man文档中描述了-t参数的用法：

-t STAMP
use [[CC]YY]MMDDhhmm[.ss] instead of current time

那么在两个节点上都用以下的命令就可以将文件的修改时间都设置为2022年2月25日13:13分了：

1

touch -t 202202251313 myconf.json

如果要用python写代码的话，可以用os.utime来设置文件的修改时间：

1
2

import os
os.utime('myconf.json', (1645806368, 1645806368))

此时再进行下测试，两个节点上nginx返回的etag就一致了，第二次请求的时候就可以看到响应是304而不是200了。

参考文档：

• serverfault上对nginx etag算法的讨论