入手了一个支持 OpenWrt 的路由器，并且支持了 OpenWrt 官方的固件，官方的固件可玩性不大，于是便刷到了原生的 OpenWrt 固件，但是由于机器的存储只有 128MB 在刷完固件之后留给插件的空间就剩下了 45MB，几乎丧失了可玩性。
由于这个机器有一个 USB 3.1 的借口，便想着是不是可以使用 U 盘对可用空间进行扩容，经过到网上进行搜索和自己的尝试，将网上的内容进行了整合形成了这篇内容。
如果要对 overlay 进行扩容需要进行一下几步：

1. 安装需要用到的插件。
2. 格式化 sda1 分区(主分区)。
3. 挂载 sda1 到 /mnt 目录。
4. 拷贝 /overlay 目录下的所有内容到 sda1 中。
5. 更新 fstab，使用 sda1 的 overlay 进行系统的启动。

opkg update
opkg install block-mount kmod-usb-storage kmod-usb-storage-uas kmod-fs-ext4 e2fsprogs cfdisk

mkfs.ext4 /dev/sda1

mount -t ext4 /dev/sda1 /mnt
cp /overlay/* /mnt -a
umount /mnt

block detect > /etc/config/fstab
uci set fstab.@mount[0].target='/overlay'
uci set fstab.@mount[0].enabled='1'
uci commit fstab

reboot

由于 sda1 是原始 overlay 的一个拷贝，那么在使用 sda1 中的 overlay 运行的过程中出现了什么问题，可以拔掉 u 盘重启，就会启动到原来的 overlay，此时在插入 u 盘，重新执行上面的操作就能将系统原来的 overlay。

如果不想拔掉 u 盘恢复到原来的 overlay，此时需要知道原来的 overlay 在什么盘的分区，在确定之后可以执行下面的命令，其中 ubi0_2 为原始 overlay 的分区。

rm -rf /overlay/*
mount -t ubifs -o ro /dev/ubi0_2 /mnt/original_overlay
cp -a /mnt/original_overlay/* /overlay/

reboot

对 swap 进行扩容(如果 ram 的大小是 512MB 及以上并不推荐设置 swap)

对 swap 进行扩容并不建议在 u 盘上面创建一个 sda2 然后格式化为 swap 分区的方法，推荐使用 zram 的方法。
安装完成之后在 System -> System -> ZRam Settings 中设置 zram 的大小和压缩算法。

opkg update
opkg install kmod-zram zram-swap

swapon -s
cat /sys/block/zram0/comp_algorithm
cat /sys/block/zram0/disksize

sing-box 入站 tun 的配置如下，其中，sniff 表示开启域名嗅探，sniff_override_destination 表示开启域名复写。
有些 vps 或者节点提供商可以通过 dns 解锁 chatgpt 服务，不开启复写的情况下，一般的网络访问为本地通过 dns 解析到域名对应的 ip，然后将 ip 和端口发送到节点服务器进行访问，节点接到要访问的 ip 和端口之后，如果节点没有开启嗅探复写就会直接访问 ip 和端口，如果节点开启了嗅探复写就会从接收到的内容中嗅探到要访问的域名，并在节点服务器进行 dns 解析，然后用节点服务器解析到的 ip 进行访问。
如果本地开启了嗅探复写那么客户端会讲嗅探到的域名交给节点服务器去访问，节点服务器在接收到客户端发过来的域名之后，会先进性 dns 查询，然后用查询到的 ip 和端口进行访问。
嗅探主要用来进行域名分流规则匹配，复写主要用嗅探到的域名替换掉访问目标 ip，如果节点开启了嗅探复写也可以正常解锁 chatgpt 服务。
开启嗅探复写导致无法连接智能家居和无法连接 tor 网络（对于 tor 网络本地和节点都不能开启嗅探复写，如果无法关闭嗅探复写则可以开启 tor 的 obfs4 混淆，这样就会嗅探不到域名）。

{
  "type": "tun",
  "tag": "tun-in",
  "inet4_address": "172.19.0.1/30",
  "mtu": 9000,
  "gso": true,
  "auto_route": true,
  "stack": "system",
  "sniff": true,
  "sniff_override_destination": false
}

---

通过 HTTP3 或者 QUIC 协议访问网站会导致即使开启嗅探也无法嗅探到域名，QUIC 会导致代理连接缓慢的问题，所以一般都会关闭 QUIC 协议的网络连接，在 sing-box 中关闭 QUIC 连接的方法是在 route 中屏蔽 QUIC 协议，或者在 dns 规则 rules 中平屏蔽 HTTPS 查询类型，这两种方法都会屏蔽掉 QUIC。

# 在 route 中屏蔽 quic 协议
{
  "protocol": "quic",
  "outbound": "block-out"
}

# 在 dns rules 中屏蔽 HTTPS 查询类型
{
  "query_type": "HTTPS",
  "server": "block-dns"
}

如果是在 docker 中搭建的服务要想实现 fullcone，容器的网络模式需要是 host。

最近由于我这里移动的宽带无法通过 vmess 访问网页，而国内的网站却不受影响，想到有可能是域名的问题，国内的域名或者常见的域名就不受影响，所以想着是不是可以使用 vless-reality-vision 避开这个限制。而且根据理解 vless-reality-vision 使用 443 端口可能是更好的选择，但是机子上面的 443 端口已经被 nginx 占用了，通过搜索在网上找到了别人分享的可以通过 nginx 的 steam 模块进行分流，由于我机子上的服务都是使用 docker 启动的，分析下来发现使用 docker 的情况下可以实现非常完美的效果。

首先机子上面要先安装 docker，然后需要创建一张 docker 内部用来通信的网卡(命名为 internal)：

docker network create internal

准备 vless-reality-vision 的配置文件，在配置文件中有一些参数需要自定义，分别是：

1. id，uuid 生成可以使用 xray 的命令来生成，windows 下的命令是 xray.exe uuid。
2. privateKey，也需要去替换，这个参数和客户端的 publicKey 是对应的，通过命令 xray.exe x25519 生成，执行这个命令之后会同时输出这两个 key。
3. shortIds（可选），用来区分不同的客户端，在服务端可以填写多个，客户端中填写服务端中填写的任一个就行，可以通过 openssl rand -hex 3 生成，命令中的 3 可以替换成 1 到 8 中的任意一个数字。
4. dest 和 serverNames（可选），dest 中的值需要填写可以正常访问的境外支持 tls1.3(通过 F12 - Security - Overiew 查看) 和 h2(通过 F12 - Network - Protocol 查看) 的网站。serverNames 填写与 dest 域名共用同一个证书的网站(通过 F12 - Security - Main origin 下的网站中的 SAN 查看)，但是暂不支持填写 * 通配符，serverNames 中填写的域名任一个都可以填写到客户端中的 serverName 中，serverNames 也可以简化到只填写和 dest 相同的一个域名。

我这里提供了一个 API 可以生成一个直接用的 vless-reality-vision 的配置文件。

https://workflow.xinebf.com/webhook/domain-san?d=support.microsoft.com

其中：d= 后面填写配置文件中的 dest。

在修改好 vless-reality-vision 的配置文件（保存在 ~/app/back/xray-vless-reality-vision.json）之后，就可以启动 docker 命令了。

在这个 docker 的启动命令中并没有将端口映射到容器外，此时的 vless-reality-vision 并不能被连接，需要创建一个 nginx 的容器通过其中的 stream 模块分流，创建 nginx 的配置文件（保存在 ~/data/nginx/nginx_stream.conf）通过命令启动 nginx stream 的容器，在这个 nginx stream 的配置文件中包含了所有服务端设置的 serverNames，即客户端可以填写任意服务端 serverNames 中包含的域名。可以在 nginx 的容器中对外映射 80 端口，nginx stream 的容器对外映射 443 端口。

至此，就可以通过 443 端口使用 vless-reality-vision 了。

我是用 Bitwarden 有一段时间了，之前也将 Steam 账号添加到了里面，但是后面再次将添加 Steam 账号的时候已经完全忘记了之前是怎么添加的，则此在查阅了网上的信息之后做一个记录总结。

通过 Bitwarden 的帮助文档可以知道，Bitwarden 是可以为 Steam 账号添加 Steam Guard TOTPS 的，但是需要获取账号的 secret key，在帮助文档里面提到了两个工具可以获取 secret key，分别是 SteamTimeIdler and Steam Desktop Authenticator。我使用的是 Steam Desktop Authenticator，在此时的最新版本是 1.0.14，具体的使用方法参考如下：

1. This is my first time and I just want to sign into my Steam Account(s);
2. Setup New Account;
3. Steam Login. 分别输入账号密码；
4. Enter the code sent to your email. 此时会发到你邮箱一个验证码，把验证码填到输入框;
5. 会提示登录成功；
6. Please enter an encryption passkey. Leave blank or hit cancel to not encrypt(VERY INSECURE). 提示输入加密密钥，因为我要在 Bitwarden 里面使用，所以此处点了 Cancel;
7. Please input the SMS code sent to your phone. 提示输出发送到手机短信的验证码，如果没有绑定手机号，验证码也会发送到邮箱;

登录完成之后会在运行程序的当前目录生成一个 maFiles 文件夹，里面会产生一个 .maFile 的文件，里面保存的是一个字典文件，使用文本编辑器打开并找到 uri 的值，其中 secret= 的值就是需要的 secret key，拼接成 steam://<secret key> 的形式。填到 Bitwarden 的验证器密码(TOTP) 下即可。

最近在使用 ChatGPT 的过程中，平时由于有对 API 的需求，但是 GPT4 API 的使用量一上来价格就有点超出预期，看到知了对 PandoraNext 的介绍，有了跃跃欲试的感觉，印象中在 2023 年上半年就有搭建过，但是当时只是感觉和 ChatGPT 官网的样式完全一样之外，并没有其他特别之处，而且当时 ChatGPT Web UI 处于百花齐放的时候，之后也就没有深入去体验，由于最近对 GPT4 API 的需求量有所提升，而且 PandoraNext 可以将 GPT web 的聊天转为 API 的调用方式，所以就有了这次深入的体验。

PandoraNext 的搭建已经非常的简单，对照着文档可以很方便的跑起来，在开启了 Proxy 模式之后，就能够通过 API 的方式对 ChatGPT web 进行访问，由于使用的是 Web 的聊天，对于 GPT3.5 是完全免费的，而对于 GPT4 则只有数量上的限制，不会再单独的收费。PandoraNext 的 token 可以分为 refresh token，session token，access token，share token 和 pool token，通过 PandoraNext 的 api 接口可以使用用户名和密码 refresh token，session token 和 access token，这三种 token 的作用和有效期是不一样的，refresh token 和 session token 可以用来生成新的 access token，生成的所有 token 并不是保存在自己搭建的 PandoraNext 节点上，获取的这些 token 可以在任何一个搭建了 PandoraNext 节点上面使用，这几种 token 更推荐通过账号密码获取 refresh token，通过 refresh token 获取 access token，在通过 access token 获得 share token，获取了 share token 之后就可以直接使用了，但是假如有多个 GPT 账号，每个账号的额度都是一定的，如果使用量比较大，单个账号就可能会达到使用的限额，此时在每个账号获取了 share token 之后，可以将多个 share token 组成一个 pool token，只要 pool token 中的 share token 还有一个可用，那么这个 pool token 就是可用的。

由于 share token 的有效期可以自定义，最长是和生成 share token 的 access token 一样长，现在知道的大概是 10 天，但是在实际中一般会小于 10 天就失效了。session token 的有效期会更长一点，据传大概是 90 天，由于已经有了 refresh token，平时 session token 很少使用，session token 可以在 OpenAI 官网和 GPT 聊天时在 Cookie 中获取。并且 session token 可以用来更新 session token 和 access token。

PandoraNext 提供了很多的 API 用来管理这些 token，我的思路是先通过账号密码，获取 refresh token，将 refresh token 对应账号保存下来，后面通过 refresh token 获取 access token，再通过 access token 获取 share token，再将 share token 也保存下来，将所有账号的 share token 都生成完毕之后，再将所有的 share token 组成一个大的 pool token，而这个 pool token 是不变的，这样就可以保证在接入其他程序之后不用频繁的重新设置 token。

其实 PandoraNext 并不需要我来介绍，网上有铺天盖地的溢美之词，但是这个项目确实解决了我在使用 ChatGPT 时的需求，所以有必要记下自己的使用体验。

就在我着手写这篇介绍的时候，PandoraNext 作者决定放弃这个项目了，这个月底(20240131)之后就用不了了。

---

使用 PandoraNext 获取的 Refresh Token 依然可以通过 OpenAi 的接口获取 Access Token，还是引用知了的文章。

POST 请求： https://auth0.openai.com/oauth/token

请求 Body 为 Json

{
    "redirect_uri": "com.openai.chat://auth0.openai.com/ios/com.openai.chat/callback",
    "grant_type": "refresh_token",
    "client_id": "pdlLIX2Y72MIl2rhLhTE9VV9bN905kBh",
    "refresh_token": "上步获取的refresh token"
}

---

PandoraNext 的作者也提供了一个 DeepL 的接口服务 DeepLX，可以用在其他的翻译软件上面接口地址如下，如果用不了了，需要手动访问一次接口地址，过一下 CF 的盾，我使用这个接口也有一段时间了，还没有遇到需要手动过 CF 盾的时候。

https://api.deeplx.org/translate

距离上次使用 WordPress 应该有十年的时间了，中间走马灯一样的换博客软件，像 Jekyll, Hexo, Hugo 等等，乐此不疲的享受着中间折腾的过程，很少能坚持下来写一些文字。如今放弃折腾这些花里胡哨的软件，重新回到 WordPress，做一些简单的记录。