建议端口穿透到内网 nginx 的 https 端口，一条隧道就可以无限域名了。

你的 Chatbox 应该集成一个“处理这些烂事的 MCP 代理”，而不是在 Chatbox 里面处理这些和对话无关的细节。
你只需要支持 Streamable HTTP 格式即可。目前 lobechat 就是这样做的。

HTTP2 的 QUIC 协议，防火墙未识别。

https://www.sordum.org/14327/network-profile-name-changer-v1-4/

这个小工具可以为你快速更改网络类型，值得一提的是 sordum.org 提供了一系列的好东西。以下是我常用的：

HostsEditor 快速编辑 hosts
USB 设备禁用器-防止 U 盘读写 Ratool
Windows Defender 杀毒禁用程序 dControl
Windows 网络配置编辑器
Windows 更新禁用程序-Wub
右键菜单管理 ec_menu
经典右键菜单 W11ClassicMenu
网络禁用工具 NetDisabler
跳过指定程序的 UAC 提示 SkipUAC

该项目自 2022 年起已停止维护，按照 README 也运行不起来。
当前建议使用基于 clash(mihomo)的 https://github.com/nelvko/clash-for-linux-install

推荐一下一键管理脚本

https://github.com/nelvko/clash-for-linux-install

使用订阅地址，基于 clash ，支持 tun 和环境变量方式使用。

https://github.com/shellus/qiye_wechat_mcp

对于慢速的，需要几分钟的 ai agent 任务，或者让 agent 编译几分钟的代码。

在此期间你可以轻松愉快的逛逛 V2EX 。

然后你会收到企业微信通知你去验收成果。

祝你摸鱼开心

@dashsoap97 使用 mcp

aws 的免费 vps ，需要信用卡
两个免费内网穿透
chmlfrp.cn ChmlFrp v2
小鸡 FRP 内网穿透 chickfrp.com

1. 集成多个内网穿透服务。
2. 使用负载均衡和健康检查来连接到多个内网穿透服务的外网端口。
3. 不希望那么麻烦的话可以只是使用 cname 指向，当一个穿透服务出故障，手动切换到可用的 cname
4. 看了一下 cpolar ，性价比极低，推荐一些性价比高的或按量计费的[内网穿透联盟]https://www.xn--v6qw21h0gd43u.xn--fiqs8s/)

总而言之，不要绑定到某个固定的供应商，强如谷歌、阿里也有宕机的时候。而通过 dns 切换不同的供应商，可以让你的服务保持稳定。

另外，你的交流电电也需要考虑配置冗余的供应商

付费 cursor ，在 ide 里面用 Claude

自己给出答案：
路由器、光猫、操作系统，都有一层防火墙，需要一个端口主动对外联系了，外界才可以对我发起连接。

例如我有公网 IPV6 地址"A"，我使用 A 地址的 1001 端口访问了网站 B ，网站 B 的地址是 B:80 ，那么 B:80 可以对我的 A:1001 发起连接，但是无法对我的其他端口发起连接。
上面说的是 UDP 的情况，如果是 TCP 客户端的 http 访问，那么连反向连接也是做不到的，因为本机只是 tcp connect 、而是 listen 。

也就是无法实现类似使用 nmap 端口扫描的方法去扫描网站访客的电脑上开启了哪些服务

也无法使用访客的地址 A ，进行持续的 ping 测试来探测访客的联网、延迟情况。


具体这个防火墙是在哪一层，似乎是多层都有。并不会有问题。

不对啊
1. 路径是实体相关的，例如 path 中有<userid>部分，这样可以检测被利用后追究到账户
2. 签名是后端生成的，可以对请求鉴权和限流

所以我想不通被利用的点在哪，如果黑产知道你随时可以将它们连根拔除，那么它就不会来利用你的 OSS

## “使用 AI” 不是选择题。

全托管我也认为确实不合适，现在还没到时候。

会用、用得好就多用，不会用，就少用，但是放弃一定是不对的，因为 AI 是未来。

未来不需要刀耕火种的人工敲代码。

就像现在的裁缝可以手工缝纫，但肯定不会不懂缝纫机。

1. 聊天记录每次变动，属于动态内容，CDN 的缓存失效，但是网络加速效果还是有的。
2. CDN 不会有写入并发量的瓶颈，人家本身就是对象存储级别的写入性能。

建议：将历史聊天记录以块形式储存为静态不变的内容，例如聊天记录存为 index.json 往里面放第 201 条记录时候，即将 1-100 条内容另存为 page1.json, 然后 index.json 的第一行指向 page1.json ，后面是 101-201 行聊天记录。
这样就实现了仍然能利用到 CDN 的缓存特性，并不会频繁刷新缓存。

再下一步应该是读写分离，读总是从 CDN 读，但是写可以先缓存本地或者其他储存，有变化则定时同步到 OSS ，减少 OSS 写入。

但是总的来说，建议别折腾，CDN+OSS 没有你想的那么脆弱，除非你进行了并发测试证明性能真的达不到你的要求（可能性很低）