@wingkwanli888 不用改前端的接口地址，看看前端需要什么接口地址，服务端就实现一下，这样对前端是透明的

@psyer 这个考虑过了，docker 好加，后面可以加上。我最开始考虑用 vercel ，但发现不太可行，由于目前聊天上下文都是保存在内存的，但是部署在 vercel 的服务要求是无状态的，因此没法保存聊天上下文，除非引入第三方 DB ，部署就复杂了

@smallyu 服务端代理的代码也有呀，src 里面就是，前端部分不需要源代码，直接保存 ChatGPT 的前端页面就行

@zbinlin 核心思想是反代，但是代理的是 GPT3.5 的接口，并不是直接反代 ChatGPT 。保持接口一致是为了复用前端 UI

另外我严重怀疑 OP 就是 freegpt.one 的作者。OP 这个号注册之后就没有发过言，也没发过贴，只有这一个帖子。另外附言中说「昨晚 ChatGPT 国内访问被 SNI 阻断了」，说的这么清楚，很可能就是作者本人。

这只我一厢情愿的瞎猜，不保证真实性。如果是真的，我还是很佩服 OP 的。

@b1ghawk #209 另外，他的前端 UI 和最新的 ChatGPT 的 UI 有些区别，他保存的应该是比较旧的 ChatGPT 的 UI ，时间应该是去年 12.8 号或之前的，因为他的大部分的 js 文件或者字体文件的 last-modified header 的值是 Thu, 08 Dec 2022 15:30:20 GMT ，表明这些文件在此之后都没有再修改过了。还有少部分文件的 last-modified 的值比较新，应该是他修改了里面的一些内容。

https://i.imgur.com/rJIpvSh.png

@b1ghawk #209 他的服务调用的是 OpenAI 的接口，后端调用接口的时候传个 token 就可以了，所以是不需普通用户登录的。

昨天我抓他的接口请求，在 response header 里面是有个 X-Powered-By: Express 的，所以判定接口用的是 Express 框架，不过今天再看已经没有了，可能是去掉了个这 header 。

不太可能用的是 worker ，因为 worker 好像被墙了。很可能只用 cloudflare 做了一层加速，后端是部署在另一个 VPS 的 Node.js 服务

分析了一下 freegpt.one ，前端应该是直接保存的 ChatGPT 的前端页面，并删除了部分区块（比如对话列表）。并写了个后端服务来反向代理接口请求。后端服务用的 Express ，并且大概率使用了 Cloudflare 的 Workers 做反代。

让 ChatGPT 给你优化一波。另外，毕业生是比较难找工作的，这不是楼主一个人面临的问题，要有耐心，C# 在国内用的应该不多。

Google 大法好： https://images.google.com

@huiyanpohundh123 #15 OP 用的哪家的 VPS 套的 warp ？我用的 GCP 的套 warp 也不好使。

@yanzhiling2001 #1 网络被开发工具给限制成 3G 的速率了

我想知道 阿凡达 2 还能看吗？

@Gav1nw #4 .class 文件不是直接运行在 CPU 上的，它是运行在 JVM 上的，而 JVM 在不同的系统和 CPU 架构上有不同的实现，这对 .class 文件来说是透明的，Java 也正是靠不同平台的 JVM 实现了跨平台。

@yuezk #12 除了把 session 保存在 redis 和数据库中，还可以用 JWT 的形式保存在客户端。无论如何，状态是无法避免的，但是我们可以通过把状态转移到其他地方的方式来避免自己保存状态，从而实现无状态。

先说一下什么是有状态，以用记登录场景为例，通常情况下，当用户登录成功之后，我们会把用户的信息保存在 HTTP session 中。这里的用户信息就是状态，HTTP session 实际上就是一个全局变量。当服务遇到问题重启的时候，变量会被销毁，这些状态就会丢失，用户的登录态就会丢，这显然是有问题的。另外，如果是多个服务实例，当用户登录到一个服务器后就没有办法负载均衡到另外的服务器，因为在其他的服务器上的 HTTP session 里面是没有用户信息的。

所以，我们需要无状态的服务，用户做完登录后，把 session 信息保存在外部，比如 redis 和数据库，这样，当服务器重启的时候，我们就可以把用户路由到其他的服务器，用户的登录态也不会丢。

在 K8s 的世界中，服务的重启或者删除重建是很常见的操作，所以要求服务无状态，便于扩展和恢复。

无状态不光在服务领域，我们平时写类的时候，也会有无状态的类这一说。

@cvbnt #2 stateless

更新链接：How Wine works 101： https://werat.dev/blog/how-wine-works-101/

这个帖子让我想到了前段时间看到的一篇关于 Wine 的文章（[How Wine works 101]( https://werat.dev/blog/how-wine-works-101/)，[中文译文]( https://www.freebuf.com/articles/system/346955.html)）。

实际上无论是什么操作系统，最终运行二进制文件都是 CPU 的工作，操作系统只是负责把二进制文件加载到 CPU 上去执行。而相同架构的 CPU 的指令又是一样的，所以理论上是可以把在 Windows 的编译的二进制文件移植到 Linux 上去的，

再看二进制文件，它其实是有结构的，可以简单理解成由 header 和 body 组成。header 部分是给操作系统来读取进行加载的，这部分不同的操作系统之间是有差别的。body 部分是 CPU 的指令，是真正要运行的部分，这部分的内容是和操作系统无关的。

所以可以这样理解，Wine 的主要工作是读取了二进制文件中的 body 部分，并加载到 CPU 运行。另外，它还 hook 了一些 Windows 上的系统函数，转成在的 Linux 里面的实现。

所以，理论上来说，用 Wine 运行 Windows 的程序，其性能并不会比在 Windows 中差，甚至有的时候还会更快。