项目看起来是有积极意义，但是这个 token 消耗量我连想都不敢想，以后 token 自由了再说吧。

UCC 114 或者 UCC 117 ，非常方便，开水就能直接泡，比普通的速溶好，看上去像是豆子打碎成粉再固化。自从买了这个我已经不喝瑞幸星巴克了，偶尔在外面才会买。在家在工位都是 UCC 。

wsl 从开始就装了，包括后来的 wsl2 ，安装又放弃无数次，现在我告诉自己绝对不会再装了。
楼上说的 localhostForwarding=true 只是冰山一角

确实，看上去非常厉害，想充钱了

看你今天的发帖，我觉得当务之急是好好吃饭，好好休息，找个班上，俗称沉淀沉淀。现在看你好像是为了做而做，不出意外这个主题也是 AI “润色”的，一股伪人感。

@sangbiao 长按 Capslock 切换大写，轻按切换中英文，自己把握感觉。

最近才试过，standalone + docker ，Dockerfile 里要注意把静态文件也拷贝一份，用的 node:22-alpine 镜像，最终大小在 300M 。
在 vercel 部署的话，好像不遵循 standalone ，我单独做了个 build:vercel 的编译命令

哥飞刻板印象 +1

clash 出事后一直用的 v2rayA ，今天为了这事儿重新换回 clash ，选择了 clash verge

谢谢楼主，又被骗了 99 ，到 27 年了

前几年一个小项目想用 logto 做认证，但是没有集成企业微信，然后自己 fork 了微信的连接器改吧改吧，前后持续了得有 1 个月，logto 项目组非常耐心的帮我修改我的弱智代码，格式检查打回过，测试不完整被打回过。但是最终还是合并了，开心。
但是也是唯一一次提 PR 了 hhh

纯好奇。
域名是 cn 还加了 cloudflare ，是把域名解析到 cloudflare 了吗？
cn 允许运营 blog 吗，我印象中好像不行呃呃。

如果你的 192.168.0.100:10010 能识别 192.168.0.100:10010/book 这个路径，可以试试修改 nginx 的 proxy_pass 配置
proxy_pass http://192.168.0.100:10010 ; --> proxy_pass http://192.168.0.100:10010/book ;
如果你后端真正的服务识别不了 /book 这个路径，你可以在 nginx 额外加 server 配置 book.abc.com proxy_pass 到 192.168.0.100:10010

我看你的 /book 还加了 proxy_set_header ，这样会让你后端真正的服务接收到 {host: abc.com} ，不知道这符不符合你的期望

我启用硬解后体验了两天，然后关闭了硬解，配置太差性能跟不上，客户端解的时候播放更流畅。
如果有不支持的编码，那就放弃这个编码的资源。

Cantook