1. 项目概述从ChatGPT到本地化WebUI的桥梁最近在折腾本地部署大语言模型的时候发现了一个挺有意思的项目scubanarc/chatgpt-to-open-webui。这名字乍一看有点绕但说白了它的核心功能就一个——把OpenAI官方的ChatGPT Web界面无缝“搬”到你自己的Open WebUI服务里来用。你可能要问这有什么意义我自己用OpenAI的官网不香吗或者直接用Open WebUI去连各种开源模型不就行了这恰恰是这个项目最有价值的地方。它解决的痛点非常具体对于那些已经深度依赖ChatGPT特别是GPT-4的API进行工作流集成、自动化脚本开发的用户来说他们需要一个更可控、更私密、功能更丰富的交互界面但又不想放弃ChatGPT官方模型强大的推理能力和一致性。OpenAI的官方Web界面功能相对基础历史记录管理、对话组织、提示词工程支持都比较弱。而Open WebUI原名Ollama WebUI是一个功能极其强大的开源项目它提供了类似ChatGPT的界面但支持连接后端多种模型如Ollama本地模型、OpenAI API、Claude API等拥有对话分组、角色预设、模型切换、Markdown渲染、插件系统等一系列高级功能。chatgpt-to-open-webui就像一个精巧的适配器它截获你浏览器对chat.openai.com的请求将其中的关键数据主要是对话消息和模型配置实时转发到你本地的Open WebUI实例从而让你在Open WebUI的豪华“客厅”里继续享用ChatGPT官方模型的“大餐”。这个项目适合谁我认为有三类人最需要它重度ChatGPT API使用者你写了很多脚本、集成了工作流但需要一个更好的界面来管理复杂的对话历史、测试不同的系统提示词。注重隐私和安全的研究者/开发者你不希望所有对话记录都留在OpenAI的服务器上希望对话数据能经过自己的服务器或完全留在本地虽然模型推理仍在OpenAI云端。追求极致效率的提示工程师Open WebUI的对话分组、角色预设、一键重试等功能能极大提升你迭代和优化提示词的效率。接下来我会带你彻底拆解这个项目从原理、部署、配置到高级用法和避坑指南让你不仅能搭起来更能理解它背后的每一个设计抉择。2. 核心原理与架构拆解它到底是怎么工作的要玩转这个工具不能只停留在“能用”的层面必须搞清楚它的运行机制。这能帮助你在出问题时快速定位也能让你明白它的能力边界和安全考量。2.1 核心思路MITM中间人代理这个项目的本质是一个HTTP/HTTPS代理服务器但它不是简单的流量转发。它扮演了一个“中间人”的角色专门针对chat.openai.com这个域名进行流量拦截和改写。工作流程可以分解为以下几个核心步骤用户发起请求你在浏览器中访问https://chat.openai.com。流量拦截你的浏览器网络设置被配置为使用chatgpt-to-open-webui提供的代理服务。所有发往chat.openai.com的请求首先被这个代理截获。请求分析与改写代理服务器会深度分析HTTP请求。身份认证请求它会识别出登录、会话刷新等请求并将其原封不动地转发给真正的OpenAI服务器。这是为了获取和维护有效的登录状态Session Cookie或Token。你的OpenAI账户凭证永远不会经过这个代理服务器它只传递加密的会话令牌。对话API请求这是关键。当你在ChatGPT网页里发送一条消息时页面会向OpenAI的特定API端点例如/backend-api/conversation发起请求。代理会识别这类请求然后执行一个“偷梁换柱”的操作。数据提取与转发代理从ChatGPT的请求中提取出核心数据message用户消息、conversation_id对话ID、parent_message_id父消息ID用于保持对话线程以及模型参数如model“gpt-4”。目标转换代理将这些提取的数据按照Open WebUI的API格式重新封装构造一个新的HTTP请求发送给你本地或远程部署的Open WebUI服务后端。响应接收与回传Open WebUI后端接到请求后会使用你配置的OpenAI API密钥需要你在Open WebUI中预先配置好去调用真正的OpenAI API。获取到流式或非流式的响应后Open WebUI将其返回给代理。响应格式伪装代理收到Open WebUI的响应后会将其内容重新包装成ChatGPT官方API的响应格式然后返回给你的浏览器。浏览器渲染你的浏览器接收到这个“伪装”的响应因为它格式正确所以能正常解析并在ChatGPT的网页界面上显示出回复内容。对你而言整个体验和直接在官网聊天一模一样。为什么选择这种架构对用户透明用户无需改变任何操作习惯继续使用最熟悉的ChatGPT官网界面。功能无损理论上只要代理能正确转发所有必要的APIChatGPT网页的所有功能代码解释器、文件上传、多模态等都有可能被支持实际取决于项目实现程度。数据可控所有对话记录、元数据都会存储在你的Open WebUI数据库中便于本地管理、导出和备份。2.2 技术栈与依赖解析这个项目本身是用Node.js编写的这选择很合理。Node.js擅长处理高并发的I/O操作如网络代理、请求转发其事件驱动模型非常适合这种中间件场景。它的核心依赖库主要包括http-proxy-middleware/node-http-proxy: 用于创建HTTP代理服务器的核心库。express: 流行的Node.js Web框架用于搭建代理服务器的Web服务和处理路由。axios/node-fetch: 用于向OpenAI和Open WebUI发起HTTP请求。各种解析和操作HTTP请求/响应的工具库如body-parser,cookie-parser。一个重要前提是你必须已经有一个正常运行的Open WebUI服务实例。这个项目不包含Open WebUI本身它只是一个“连接器”。Open WebUI通常通过Docker部署它自身会提供Web界面默认端口8080和后端API。2.3 安全与隐私边界探讨这是必须严肃对待的部分。使用此类工具你必须清楚数据的流向你的OpenAI账户密码只在首次登录chat.openai.com时通过HTTPS直接发送给OpenAI。代理服务器看不到你的明文密码。你的会话令牌Session Token代理服务器会持有这个令牌并用它来维持你在ChatGPT网页的登录状态。这是一个敏感信息等同于临时密码。你的对话内容这是核心。你的每一条消息和ChatGPT的回复都会流经代理服务器并最终存储在你的Open WebUI数据库中。你的OpenAI API密钥这个密钥是配置在Open WebUI后端的用于实际调用GPT模型。chatgpt-to-open-webui代理本身不接触这个密钥。因此安全责任发生了转移从OpenAI转移到了你自己你的对话数据不再仅存在于OpenAI的云端也存在于你部署Open WebUI的服务器上。你需要确保这台服务器的安全如设置防火墙、定期更新、使用强密码。信任链你必须信任scubanarc/chatgpt-to-open-webui这个开源项目的代码不会恶意收集你的数据。最佳实践是自行审查代码并从官方仓库克隆。重要提示根据OpenAI的使用条款此类拦截和转发流量的行为可能处于灰色地带。它主要用于个人学习、研究和提升效率。请勿将其用于任何违反服务条款的用途也不要在不受信任的第三方服务器上使用。3. 详细部署与配置指南理论讲完了我们动手把它搭起来。我会以一台干净的Linux服务器Ubuntu 22.04为例演示从零开始的完整过程。假设你已经有了服务器的基础访问权限SSH。3.1 前置条件准备首先确保你的环境满足以下要求Node.js环境版本建议 16。我们将使用nvm来安装这是管理Node版本的最佳实践。Open WebUI服务这是必须的。如果你还没有需要先部署它。一个有效的OpenAI账户用于登录chat.openai.com。OpenAI API密钥用于配置在Open WebUI后端让Open WebUI能代表你调用API。3.1.1 部署Open WebUI如果尚未部署Open WebUI的官方推荐部署方式是Docker这能避免复杂的Python环境依赖。# 1. 安装Docker如果未安装 sudo apt update sudo apt install -y docker.io docker-compose-v2 sudo systemctl enable --now docker sudo usermod -aG docker $USER # 退出并重新登录SSH使组权限生效 # 2. 拉取并运行Open WebUI容器 docker run -d \ --name open-webui \ -p 8080:8080 \ -e OLLAMA_BASE_URLhttp://host.docker.internal:11434 \ -v open-webui:/app/backend/data \ --restart always \ ghcr.io/open-webui/open-webui:main参数解释-p 8080:8080: 将容器的8080端口映射到宿主机的8080端口。你现在可以通过http://你的服务器IP:8080访问Open WebUI。-e OLLAMA_BASE_URL...: 这个环境变量是用于连接本地Ollama服务的。即使我们只用OpenAI API这个变量最好也保留否则Open WebUI前端可能会报错。host.docker.internal是Docker的一个特殊域名指向宿主机。-v open-webui:/app/backend/data: 将数据卷挂载到容器这样你的对话历史、设置等信息在容器重启后不会丢失。--restart always: 确保容器在意外退出或系统重启后自动启动。运行后访问http://你的服务器IP:8080首次进入会要求你创建一个管理员账户。创建完成后进入设置。3.1.2 在Open WebUI中配置OpenAI API登录Open WebUI点击左下角的设置齿轮图标。在设置侧边栏找到“模型提供商”或“Model Providers”。点击“OpenAI”你会看到一个输入框要求填写“API Key”。前往 OpenAI平台 创建一个新的API密钥注意保管只显示一次。将生成的API密钥粘贴到Open WebUI的配置中并保存。现在你的Open WebUI已经具备了调用ChatGPT模型的能力。你可以在主界面的模型选择下拉菜单里看到可用的OpenAI模型如gpt-3.5-turbo, gpt-4等。请务必先在这里测试一下直接通过Open WebUI界面能否正常与ChatGPT对话。这是后续步骤的基础。3.2 安装与配置 chatgpt-to-open-webui现在我们来部署核心的代理服务。# 1. 克隆项目仓库 git clone https://github.com/scubanarc/chatgpt-to-open-webui.git cd chatgpt-to-open-webui # 2. 使用nvm安装并切换Node.js版本推荐 curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.0/install.sh | bash # 关闭并重新打开终端或执行 export NVM_DIR$HOME/.nvm [ -s $NVM_DIR/nvm.sh ] \. $NVM_DIR/nvm.sh [ -s $NVM_DIR/bash_completion ] \. $NVM_DIR/bash_completion nvm install 18 # 安装Node.js 18 LTS版本 nvm use 18 # 3. 安装项目依赖 npm install安装完成后你需要配置项目。通常项目根目录下会有一个配置文件示例如config.example.json或.env.example。复制它并修改。# 假设项目使用 .env 文件 cp .env.example .env编辑.env文件关键配置项如下# 代理服务器监听的端口例如 3000 PORT3000 # 你的Open WebUI后端地址注意是后端API的地址不是前端页面地址。 # 默认的Docker部署后端通常和前端在同一地址但端口是8080。 # 格式http://你的服务器IP:8080/api OPEN_WEBUI_BASE_URLhttp://localhost:8080/api # 日志级别调试时可设为 debug LOG_LEVELinfo # 可选设置一个访问代理的密码不建议因为主要靠网络隔离 # BASIC_AUTH_USERNAMEadmin # BASIC_AUTH_PASSWORDyourpassword重点解析OPEN_WEBUI_BASE_URL如果你的chatgpt-to-open-webui和Open WebUI部署在同一台机器上可以使用http://localhost:8080/api。如果部署在不同机器则需要填写Open WebUI服务器的真实IP和端口并且确保该端口的防火墙是开放的允许代理服务器访问。/api路径是Open WebUI后端API的固定前缀必须加上。3.3 启动代理服务与浏览器配置配置好后启动代理服务# 开发模式启动代码修改会自动重启 npm run dev # 或者生产模式启动 npm start # 更推荐使用PM2进行进程守护确保服务在后台稳定运行 npm install -g pm2 pm2 start npm --name chatgpt-proxy -- start pm2 save pm2 startup # 设置开机自启服务启动后会在你配置的端口如3000上监听。现在你需要配置浏览器让它通过这个代理来访问chat.openai.com。这里有两种主流方法方法一使用浏览器插件最简单推荐安装像SwitchyOmega(Chrome/Firefox) 这样的代理管理插件。新建一个情景模式比如叫 “ChatGPT Proxy”。代理协议选择HTTP代理服务器填写你部署chatgpt-to-open-webui的机器IP端口填写配置的端口如3000。在“条件”或“规则列表”中添加一条规则chat.openai.com使用这个代理其他网站直接连接。启用这个情景模式。方法二使用系统/终端全局代理影响所有流量不推荐# 在Linux/Mac终端中临时设置 export http_proxyhttp://你的代理IP:3000 export https_proxyhttp://你的代理IP:3000 # 然后在这个终端里启动浏览器例如Chrome google-chrome --proxy-serverhttp://你的代理IP:3000这种方法会将所有浏览器流量都导向代理可能会影响其他网站访问且代理服务必须能正确处理非ChatGPT的流量本项目通常不能。配置完成后进行测试确保代理服务 (npm start) 和 Open WebUI (docker ps查看状态) 都在运行。在浏览器中访问https://chat.openai.com。此时流量应经过你的代理。正常登录你的OpenAI账户。发起一次对话。如果一切正常你应该能在ChatGPT网页界面正常收发消息。如何验证它真的在工作查看Open WebUI界面打开你的Open WebUI (http://服务器IP:8080)你应该能看到一个标题为 “ChatGPT” 或类似的新对话内容就是你刚刚在ChatGPT官网进行的对话。查看代理服务器日志在运行npm start的终端里你会看到详细的请求和转发日志。网络检查在ChatGPT网页按F12打开开发者工具查看网络请求。你会发现向chat.openai.com发出的请求其远程地址变成了你代理服务器的IP和端口。4. 高级用法与深度定制基础功能跑通后我们可以探索一些高级玩法让这个工具更贴合你的个人工作流。4.1 模型映射与强制使用特定模型默认情况下代理会读取你在ChatGPT网页上选择的模型如GPT-4o并转发给Open WebUI。但有时你可能想强制使用某个模型或者将ChatGPT界面上的模型选择映射到Open WebUI里不同的模型名称。这通常需要修改代理服务器的代码逻辑。查看项目的src或lib目录找到处理API请求转发的核心文件例如openai-proxy.js或conversation-handler.js。关键逻辑在于它如何解析来自ChatGPT的请求体。示例强制使用 GPT-4假设你找到了解析请求的代码段它可能长这样const openaiRequestBody JSON.parse(req.body); const model openaiRequestBody.model || ‘gpt-3.5-turbo’; // ... 然后准备转发给Open WebUI的请求体你可以在这里添加一个映射或覆盖let model openaiRequestBody.model || ‘gpt-3.5-turbo’; // 强制将所有请求的模型改为 gpt-4 model ‘gpt-4’; // 或者做一个映射如果网页选的是 ‘gpt-4’ 实际用 ‘gpt-4-0125-preview’ if (model ‘gpt-4’) { model ‘gpt-4-0125-preview’; }注意修改源代码需要你对Node.js和项目结构有一定了解并且未来项目升级时可能需要重新合并你的修改。4.2 对话元数据与Open WebUI功能集成这是使用Open WebUI的最大优势。所有通过代理过来的对话在Open WebUI里都是完全可管理的。对话分组与标签你可以在Open WebUI中为这些对话创建文件夹、打上标签如“工作”、“学习”、“编程”方便后期检索。这是ChatGPT官方界面不具备的。提示词预设在Open WebUI中你可以创建“角色”或“预设”。例如创建一个“代码评审专家”的预设包含详细的系统指令。虽然代理不会自动应用这些预设但你可以手动在Open WebUI中基于某次对话的上下文应用新的预设来继续对话这比在ChatGPT网页上反复粘贴系统提示词方便得多。消息编辑与重新生成如果对某条回复不满意可以在Open WebUI中直接编辑你上一条消息或者让模型从某个节点开始重新生成后续对话实现对话树的回溯。数据导出可以一键导出整个对话或所有对话为Markdown、JSON、PDF等格式用于归档或知识库建设。4.3 处理多模态与文件上传ChatGPT网页支持上传图像、PDF、Word等文件进行处理。要让这个功能通过代理工作需要确保代理能正确处理multipart/form-data类型的请求并将文件数据正确地转发给Open WebUI。Open WebUI本身也支持文件上传需要配置。代理项目需要将ChatGPT上传的文件通过Open WebUI的相应API可能是/api/files/upload进行上传并将返回的文件ID或路径整合到转发给Open WebUI的对话请求中。这是一个高级功能需要查看chatgpt-to-open-webui项目的具体实现是否支持。如果官方尚未实现你可能需要自己研究ChatGPT的文件上传API和Open WebUI的文件上传API然后在代理代码中实现桥接。这涉及到二进制流的处理和API格式转换复杂度较高。4.4 与本地模型混合使用一个更强大的场景是在ChatGPT界面里无缝切换OpenAI模型和你本地部署的Ollama模型。理论上这可以通过更复杂的代理逻辑实现根据你在ChatGPT网页上选择的模型名称动态决定将请求转发给Open WebUI的哪个后端。如果模型是gpt-4或gpt-3.5-turbo则转发到Open WebUI的OpenAI连接器。如果模型是llama3:8b或qwen2:7b你需要先在ChatGPT的模型列表里“模拟”出这些选项可能需要修改前端或使用浏览器插件则转发到Open WebUI的Ollama连接器。这需要对代理代码进行深度定制实现一个路由分发器。但对于追求极致统一体验的用户来说这是一个非常有吸引力的方向。5. 常见问题、故障排查与优化心得在实际部署和使用过程中你肯定会遇到各种问题。下面是我踩过坑后总结的排查清单和优化建议。5.1 部署与连接问题问题1浏览器访问chat.openai.com无法打开或一直加载。检查代理服务状态pm2 list或ps aux | grep node查看进程是否在运行。查看代理日志pm2 logs chatgpt-proxy是否有错误。检查端口和防火墙确保代理服务的端口如3000在服务器上已开放并且允许你的客户端IP访问。sudo ufw allow 3000。检查浏览器代理设置确认SwitchyOmega等插件规则是否正确是否已激活。尝试用curl命令测试代理是否通畅curl -x http://你的代理IP:3000 https://chat.openai.com看是否能返回HTML内容可能会遇到Cloudflare验证但至少应能连接。检查Open WebUI连通性在代理服务器上用curl http://localhost:8080/api/models(或你的OPEN_WEBUI_BASE_URL) 测试是否能访问到Open WebUI后端。如果返回401或404说明Open WebUI服务或网络配置有问题。问题2能打开ChatGPT网页并登录但发送消息后没反应或报错。查看代理服务器日志这是最重要的信息源。看它是否成功截获了/backend-api/conversation请求转发是否成功Open WebUI返回了什么错误。检查Open WebUI的OpenAI API配置再次确认Open WebUI设置中的API密钥正确且未过期额度是否充足。检查Open WebUI模型列表在Open WebUI界面确认模型下拉列表里能正常加载出gpt-3.5-turbo,gpt-4等模型。如果加载不出就是Open WebUI连接OpenAI API的问题。网络超时代理转发或Open WebUI调用OpenAI API可能超时。尝试在代理代码或配置中增加超时时间限制。5.2 数据与同步问题问题3ChatGPT网页上的对话在Open WebUI里找不到或不同步。对话标题映射ChatGPT的对话标题可能和Open WebUI的标题生成规则不同。Open WebUI可能用消息的前几个词做标题。这是正常现象内容同步即可。同步延迟代理是实时转发的理论上应该立刻出现。如果没有检查代理日志看转发请求是否成功HTTP状态码应为200。可能是Open WebUI的数据库写入有延迟。重复对话不要同时在ChatGPT网页和Open WebUI界面对同一个对话进行操作可能导致消息重复或冲突。建议只在一个界面进行写操作。问题4历史对话没有同步过来。这个代理是单向同步且是从ChatGPT网页到Open WebUI。它只能同步代理启动后新产生的对话。你在安装代理之前的历史对话无法自动同步到Open WebUI。如果需要旧对话只能手动从ChatGPT官网导出然后导入到Open WebUI中如果Open WebUI支持导入的话。5.3 性能与稳定性优化1. 使用进程守护工具永远不要只用npm start在终端前台运行。使用PM2或systemd来管理进程保证服务崩溃后自动重启以及开机自启。2. 日志管理与轮转生产环境运行务必配置日志轮转避免日志文件撑满磁盘。PM2自带了日志管理功能也可以使用logrotate。pm2 install pm2-logrotate pm2 set pm2-logrotate:max_size 10M # 每个日志文件最大10M pm2 set pm2-logrotate:retain 30 # 保留30个日志文件3. 考虑网络延迟如果你的代理服务器、Open WebUI服务器和你的客户端分布在不同的地区或网络延迟会叠加。最终的消息响应时间 ≈ (客户端到代理延迟) (代理处理时间) (代理到Open WebUI延迟) (Open WebUI到OpenAI API延迟) (模型生成时间)。尽量让代理和Open WebUI部署在同一内网可以显著减少中间环节的延迟。4. 安全性加固不要将代理服务暴露在公网除非你知道自己在做什么。最好在本地机器或受信任的内网部署。如果必须在公网至少设置IP白名单或简单的HTTP Basic认证项目配置支持。定期更新关注项目GitHub仓库的更新及时修复可能的安全漏洞。隔离环境可以考虑将Node.js代理服务也容器化Docker与主机环境隔离。5.4 一个我踩过的大坑Cookie与会话失效最初部署时我遇到一个诡异的问题使用一段时间后ChatGPT网页会突然掉线提示需要重新登录。原因分析ChatGPT的登录会话有一定有效期并且可能会检测异常活动如IP频繁变动。我们的代理服务器在转发登录请求和维护Cookie时可能没有正确处理会话刷新的逻辑或者Cookie在代理层存储不当。解决方案确保代理代码正确处理Cookie检查项目代码中是否将从OpenAI服务器返回的Set-Cookie头部正确地传递给了浏览器以及是否将浏览器发来的Cookie头部正确地转发给了OpenAI。任何一环丢失都会导致会话中断。减少IP变动尽量让代理服务器的出口IP固定。如果使用家庭宽带IP可能会变考虑使用云服务器。模拟更真实的浏览器行为有些高级的反爬机制会检查User-Agent、HTTP头顺序等。确保代理服务器转发请求时保留了原始请求的大部分头部信息。最后这个项目是一个极佳的学习案例它展示了如何通过中间件技术在不修改客户端和服务端的情况下实现两个系统间的数据桥接和功能增强。它的价值不在于技术有多高深而在于精准地解决了一个特定人群的痛点。如果你也是那个既离不开ChatGPT强大能力又渴望更佳交互和数据管理体验的人那么花点时间部署和调试它绝对是值得的。