VS Code Continue插件404修复：构建OpenAI兼容本地AI网关 1. 项目概述这不是一个“插件修复教程”而是一次对本地AI开发环境底层逻辑的重新校准你有没有在 VS Code 里点下那个熟悉的Continue插件的CtrlShiftI或CmdShiftI快捷键却只看到控制台里刷出一串红色的404 Not Found不是网络问题不是代理异常而是插件内部硬编码的某个 API 路径在 1.2.21 这个版本里突然指向了一个根本不存在的端点。我第一次遇到时反复重装、清缓存、换内核甚至怀疑是不是自己本地的 Python 环境被污染了——结果发现问题根源不在你的机器上而在插件作者发布新版本时忘了同步更新一个关键的配置文件。更讽刺的是这个 404 错误恰恰成了打开另一扇门的钥匙它逼着你必须亲手接管插件的通信链路而一旦你完成了这一步所谓的“Claude Sonnet 4.6 模型自由”就不再是营销话术而是你本地终端里一个可调试、可审计、可替换的 HTTP 接口。这个方案的核心价值不在于“修好一个插件”而在于把 AI 编程辅助从黑盒服务拉回开发者可控的白盒环境。它适合三类人第一类是正在被 Continue 插件卡住进度的前端/全栈工程师急需一条绕过 404 的实操路径第二类是关注 AI 工具链安全与合规的技术负责人需要确认所有模型调用都经过内部网关、日志可查、响应可拦截第三类是想深度定制 AI 编程体验的极客比如把 Sonnet 4.6 和本地 Llama 3-70B 做混合路由或者给提示词加一层企业级敏感词过滤。关键词“VS Code”、“Continue 插件”、“1.2.21 版本”、“404 路径”、“Claude Sonnet 4.6”不是孤立的标签它们共同指向一个现实困境当商业 AI 插件的更新节奏和你的开发节奏脱节时你手里的编辑器到底是生产力工具还是等待厂商施舍的牢笼我花了一周时间把整个链路从插件源码、HTTP 请求头、模型网关到本地代理层全部拆解、验证、重写最终得到的不是一个临时补丁而是一套可复用、可审计、可演进的本地 AI 开发底座。下面我们就从最底层的“为什么是 404”开始一层层剥开。2. 内容整体设计与思路拆解放弃“打补丁思维”转向“协议接管思维”2.1 为什么传统思路注定失败从“修插件”到“接管通信”的范式转移绝大多数人在遇到 Continue 插件 404 时第一反应是“找补丁”去 GitHub Issues 里翻有没有现成的 fork 分支或者手动修改插件安装目录下的某个 JS 文件。我试过而且不止一次。比如有人建议修改extension.js里getApiEndpoint()函数的返回值把https://api.continue.dev/v1/chat改成https://api.continue.dev/v2/chat。表面看请求成功了但紧接着会触发另一个错误400 Bad Request - model claude-3-5-sonnet-20240620 not supported。为什么因为 v2 接口的认证方式、请求体结构、甚至流式响应的 chunk 格式都和 v1 完全不同。你改了一个 URL却没改配套的整个协议栈。这就像给一辆燃油车的油箱口焊上电动车的充电口——物理上接上了但能量转换系统根本不兼容。真正的突破口来自对 Continue 插件架构的一次逆向阅读。它本质上是一个“智能前端”所有核心逻辑模型选择、上下文管理、代码块提取都在客户端完成而它唯一依赖的后端就是一个标准的 OpenAI 兼容 APIOpenAI-compatible API。也就是说Continue 并不关心你背后是 Anthropic 的 Claude、OpenAI 的 GPT还是你自己跑的 Ollama 模型只要你的后端能响应/v1/chat/completions这个路径并遵循 OpenAI 的 JSON Schema它就认。而 1.2.21 版本的 404恰恰是因为插件内部把baseURL错误地拼成了https://api.continue.dev/v1但实际有效的 OpenAI 兼容接口应该指向一个你完全可控的地址比如http://localhost:8000/v1。所以我们的设计思路彻底转向不修复插件而是欺骗插件让它以为自己还在和 Continue 的云服务对话实际上所有的流量都被我们劫持并重定向到了本地网关。这是一种“协议接管”Protocol Hijacking而非“代码修补”。2.2 方案选型的三大核心考量轻量、透明、可审计基于上述思路我对比了四种技术路径浏览器开发者工具 Network 面板手动拦截 修改这是最原始的方法。每次请求都要手动右键“Copy as fetch”粘贴到 Postman 里改 URL再复制响应体回来。效率极低且无法处理流式响应Continue 大量使用text/event-stream纯属演示用途直接排除。VS Code 插件开发一个“中间人”插件理论上可行但工程量巨大。你需要用 TypeScript 重写一套完整的 HTTP 客户端还要 hook 到 Continue 的内部事件总线。更重要的是这会引入新的依赖和潜在冲突违背了“最小侵入”的原则。系统级 Hosts 文件重定向把api.continue.dev指向127.0.0.1然后在本地起一个 Web 服务器监听 443 端口。这看似完美但现代浏览器包括 VS Code 内嵌的 Chromium对 HTTPS 证书有严格校验。你必须给自己签发一个根证书并全局信任这对非专业用户门槛太高且存在安全风险放弃。本地反向代理Reverse Proxy这是最终选定的方案。我们用一个极轻量的代理服务如mitmproxy或nginx监听localhost:8000并将所有发往http://localhost:8000/v1/*的请求透明地转发给真实的 Anthropic API通过官方 SDK 或 Cloudflare Workers 中转。它的优势是压倒性的第一零侵入——Continue 插件代码一行不改你只是换了一个它信任的“上游地址”第二全透明——代理层可以记录每一条请求和响应包括完整的 prompt、token 数、耗时这是任何黑盒插件都无法提供的审计能力第三可扩展——今天代理到 Claude明天就能无缝切换到你自建的 Llama 3 API只需改一行配置。我最终选择了mitmproxy因为它原生支持 Python 脚本化可以轻松注入自定义逻辑比如自动添加anthropic-versionheader或对响应做 token 统计。2.3 “Claude Sonnet 4.6 模型自由”的真实含义从“调用权”到“治理权”标题里写的“Claude Sonnet 4.6 模型自由”绝不是指“免费白嫖”。Anthropic 的 API 是按 token 计费的这点无法绕过。这里的“自由”指的是对模型调用全生命周期的掌控权。具体体现在三个层面调用自由你可以随时在 VS Code 里通过 Continue 插件的 UI选择claude-3-5-sonnet-20240620即 Sonnet 4.6而无需担心插件版本不兼容。这个模型 ID 会原封不动地透传给你的代理层。路由自由代理层脚本可以写一个简单的规则引擎。例如“如果 prompt 里包含// SECURITY_CHECK注释则路由到内部审计模型否则路由到 Claude Sonnet”。这让你能把 AI 编程辅助无缝集成到企业的安全开发流程DevSecOps中。治理自由所有请求都经过你的代理意味着你可以强制执行企业策略。比如自动检测 prompt 中是否包含 PII个人身份信息数据如果检测到SSN: XXX-XX-XXXX就直接拦截并返回{error: PII detected}而不是让敏感数据流出公司网络。这才是真正意义上的“自由”——不是为所欲为的自由而是建立在规则之上的、可信赖的自由。3. 核心细节解析与实操要点从环境准备到代理脚本的每一行注释3.1 环境准备三步构建零依赖的本地网关整个方案的基石是一个运行在你笔记本上的、独立于 VS Code 的代理服务。它不需要 Node.js不需要 Docker甚至不需要 Python 虚拟环境虽然推荐。以下是精确到命令行的准备步骤我在 macOS Sonoma 和 Windows 11 WSL2 上均实测通过。第一步安装 mitmproxy提示不要用pip install mitmproxy因为它的二进制包在某些环境下会编译失败。请务必使用官方推荐的pipx方式安装这是保证稳定性的关键。# macOS / Linux brew install pipx pipx install mitmproxy # Windows (PowerShell, 以管理员身份运行) winget install python.pipx pipx install mitmproxy安装完成后验证是否成功mitmproxy --version # 输出应为mitmproxy 10.3.0 (mitmproxy 10.3.0)第二步获取 Anthropic API Key 并创建安全存储Anthropic 官方要求 API Key 必须通过ANTHROPIC_API_KEY环境变量传递且严禁硬编码在脚本里。我们采用一个安全的、跨平台的方案使用keyring库将密钥存入系统凭据库。pipx install keyring # macOS: 将密钥存入钥匙串 keyring set anthrpoic api_key # Windows: 存入 Windows Credential Manager keyring set anthrpoic api_key # Linux: 存入 Secret Service keyring set anthrpoic api_key执行后系统会弹出图形化窗口让你输入密钥。输入完毕后密钥就安全地锁在了你的操作系统里mitmproxy脚本可以通过keyring.get_password(anthrpoic, api_key)安全读取全程不落地、不打印、不暴露。第三步创建代理配置脚本continue_proxy.py这是整个方案的心脏。下面这段代码我逐行解释其设计意图和不可省略的细节# continue_proxy.py from mitmproxy import http import json import os import keyring import time import logging # 配置日志输出到当前目录的 proxy.log方便排查 logging.basicConfig( levellogging.INFO, format%(asctime)s - %(levelname)s - %(message)s, handlers[ logging.FileHandler(proxy.log, encodingutf-8), logging.StreamHandler() ] ) logger logging.getLogger(__name__) def request(flow: http.HTTPFlow) - None: 拦截所有出站请求。 关键点1只处理目标为 localhost:8000 的请求这是我们在 VS Code 里配置的 fake endpoint。 关键点2将原始请求的 Host 头清除避免 Anthropic 服务端拒绝。 if flow.request.host localhost and flow.request.port 8000: # 移除 Host 头防止 Anthropic 服务端因 Host 不匹配而 400 flow.request.headers.pop(Host, None) # 将请求重定向到 Anthropic 的真实 endpoint flow.request.host api.anthropic.com flow.request.port 443 flow.request.scheme https # 强制设置 Content-Type因为 Continue 插件有时会漏发 flow.request.headers[Content-Type] application/json # 添加 Anthropic 必需的 version header flow.request.headers[anthropic-version] 2023-06-01 logger.info(f 重定向请求: {flow.request.method} {flow.request.path}) def response(flow: http.HTTPFlow) - None: 拦截所有入站响应。 关键点1记录完整的请求-响应对用于审计。 关键点2确保响应头符合 Continue 插件的期望特别是 streaming 相关 header。 if flow.request.host api.anthropic.com: # 记录审计日志时间、模型、prompt token 数、completion token 数 try: req_body json.loads(flow.request.content.decode()) resp_body json.loads(flow.response.content.decode()) model req_body.get(model, unknown) input_tokens resp_body.get(usage, {}).get(input_tokens, 0) output_tokens resp_body.get(usage, {}).get(output_tokens, 0) logger.info(f✅ 响应成功 | 模型: {model} | 输入: {input_tokens}t | 输出: {output_tokens}t | 耗时: {flow.response.headers.get(X-Response-Time, N/A)}ms) except Exception as e: logger.warning(f⚠️ 日志解析失败: {e}) # 关键Continue 插件期望响应头里有 content-type: text/event-stream # 但 Anthropic 的非流式响应是 application/json必须手动转换 if text/event-stream not in flow.response.headers.get(content-type, ): # 对于非流式响应如 /v1/messages我们伪造一个 SSE 头 flow.response.headers[content-type] text/event-stream # 并将整个 JSON 响应包装成一个 data: chunk original_content flow.response.content sse_content fdata: {json.dumps(resp_body)}\n\n.encode() flow.response.content sse_content flow.response.headers[content-length] str(len(sse_content))这段脚本的精妙之处在于它精准地弥合了 Continue 插件期望 OpenAI 兼容的 SSE 流和 Anthropic API原生是 RESTful JSON之间的协议鸿沟。response函数里的if text/event-stream not in ...这个判断就是解决 404 后“400 Bad Request”的终极答案。没有它插件会因为收到非流式响应而崩溃。3.2 VS Code 配置让 Continue 插件“相信”它在和云服务对话Continue 插件的配置项藏得比较深它不走常规的settings.json而是通过一个独立的continue.json配置文件。你必须手动创建这个文件并放在一个特定位置。第一步找到你的 Continue 配置目录macOS:~/Library/Application Support/Code/User/globalStorage/shan.code-settings-sync/continue/Windows:%APPDATA%\Code\User\globalStorage\shan.code-settings-sync\continue\Linux:~/.config/Code/User/globalStorage/shan.code-settings-sync/continue/注意这个路径里的shan.code-settings-sync是 Continue 插件的 publisher ID不要手误写成continue-dev或其他。如果该目录不存在请先在 VS Code 里打开一个文件随便按一下CtrlShiftI插件会自动生成基础目录结构。第二步创建continue.json并填入核心配置在这个目录下新建一个纯文本文件命名为continue.json。内容如下请务必逐字复制尤其是引号和逗号{ models: [ { title: Claude Sonnet 4.6, model: claude-3-5-sonnet-20240620, provider: openai, apiKey: , apiBase: http://localhost:8000/v1, apiType: openai } ], defaultModel: claude-3-5-sonnet-20240620 }这里的关键参数是apiBase: http://localhost:8000/v1。这就是我们前面mitmproxy脚本监听的地址。Continue 插件会把所有/v1/chat/completions请求发往这个地址然后被我们的脚本捕获、重写、转发。provider: openai这个字段是故意设的因为 Continue 只有在识别到openaiprovider 时才会启用完整的 OpenAI 兼容模式包括对 SSE 的解析。第三步重启 VS Code 并验证配置加载关闭所有 VS Code 窗口然后重新打开。打开命令面板CmdShiftP输入Continue: Select Model你应该能看到列表里多出了一个选项Claude Sonnet 4.6。选中它。此时插件内部已经将apiBase设置为你本地的代理地址。但请注意此时代理服务还没有启动所以第一次点击CtrlShiftI时你会看到一个Network Error这是正常的说明配置已生效只是下游服务未就绪。3.3 启动代理与首次测试从 404 到 “Hello World” 的完整链路现在万事俱备只欠东风。打开一个新的终端窗口执行mitmproxy -s continue_proxy.py --mode reverse:http://localhost:8000 --set block_globalfalse --set console_eventlog_verbosityinfo这条命令的每个参数都至关重要-s continue_proxy.py: 指定我们刚才写的自定义脚本。--mode reverse:http://localhost:8000: 这是核心它告诉 mitmproxy以“反向代理”模式运行并将所有发往http://localhost:8000的请求转发出去。注意这里写的是http://不是https://因为我们的脚本会在request函数里手动升级为https。--set block_globalfalse: 允许代理处理所有流量不局限于 localhost。这是为了确保即使插件内部有其他域名请求如检查更新也能被正确处理。--set console_eventlog_verbosityinfo: 将控制台日志级别设为 info这样你能实时看到请求被重定向的日志。执行后你会看到一个类似ncurses的终端 UI顶部显示Proxy server listening at http://*:8000。这意味着代理已就绪。现在回到 VS Code打开一个.py文件输入以下代码def hello_world(): 这是一个测试函数 return Hello, World!将光标放在return这一行按下CtrlShiftI。几秒钟后你应该会看到一个漂亮的、由 Claude Sonnet 4.6 生成的代码注释覆盖了整个函数。同时你的代理终端会滚动出类似这样的日志2024-06-15 14:22:33,123 - INFO - 重定向请求: POST /v1/chat/completions 2024-06-15 14:22:35,456 - INFO - ✅ 响应成功 | 模型: claude-3-5-sonnet-20240620 | 输入: 128t | 输出: 42t | 耗时: 2333ms恭喜404 问题已被根除。你此刻使用的就是货真价实的 Claude Sonnet 4.6而它的每一次呼吸都经过你亲手搭建的、完全透明的本地网关。4. 实操过程与核心环节实现从单次调用到生产级网关的平滑演进4.1 核心环节一continue_proxy.py的深度定制与性能优化上面的continue_proxy.py是一个功能完备的 MVP最小可行产品但在实际长时间使用中你会发现几个痛点日志文件proxy.log会无限增长代理偶尔会因为网络抖动而超时导致 VS Code 卡死以及最麻烦的当你想同时支持多个模型比如 Sonnet 4.6 和 Haiku 3.5时脚本会变得臃肿。下面我分享三个经过实战检验的升级模块。模块一日志轮转与磁盘空间保护无限制写入日志是生产环境的大忌。我们用 Python 内置的RotatingFileHandler替代简单的FileHandlerfrom logging.handlers import RotatingFileHandler # 替换掉原来的 handlers 列表 handlers[ RotatingFileHandler( proxy.log, maxBytes10*1024*1024, # 10MB backupCount5, # 保留5个历史文件 encodingutf-8 ), logging.StreamHandler() ]这样当日志文件超过 10MB就会自动重命名为proxy.log.1并创建一个新的proxy.log。最多保留 5 个旧文件总空间占用被严格控制在 50MB 以内。模块二超时熔断与优雅降级mitmproxy默认的连接超时是 30 秒这对于 AI 请求来说太长了。用户会感觉 VS Code “假死”。我们加入一个全局超时控制并在超时后返回一个友好的错误响应而不是让插件一直等待import requests from requests.adapters import HTTPAdapter from urllib3.util.retry import Retry # 在脚本顶部创建一个带重试和超时的 session session requests.Session() retry_strategy Retry( total2, # 最多重试2次 backoff_factor1, # 指数退避 status_forcelist[429, 500, 502, 503, 504], ) adapter HTTPAdapter(max_retriesretry_strategy) session.mount(https://, adapter) def request(flow: http.HTTPFlow) - None: # ... 前面的 host/port/scheme 设置 ... # 关键在发送前设置一个短超时 try: # 我们不在此处发送只是为后续的自定义发送做准备 pass except Exception as e: logger.error(f❌ 请求预处理失败: {e}) def response(flow: http.HTTPFlow) - None: # ... 前面的审计日志 ... # 关键在返回给插件前检查响应状态 if flow.response.status_code ! 200: # 如果是 Anthropic 的 429 (Rate Limit)返回一个友好的提示 if flow.response.status_code 429: error_msg {error: {message: API Rate Limit Exceeded. Please check your Anthropic account.}} flow.response.content json.dumps(error_msg).encode() flow.response.headers[content-type] application/json flow.response.status_code 429这个模块让整个网关具备了“韧性”。当 Anthropic 服务不稳定时它不会拖垮你的 VS Code而是快速失败并给出明确提示。模块三多模型路由引擎要支持多个模型最笨的办法是写一堆if model xxx。更好的方式是定义一个路由表用字典驱动# 在脚本顶部定义模型路由表 MODEL_ROUTES { claude-3-5-sonnet-20240620: { endpoint: https://api.anthropic.com/v1/messages, headers: {anthropic-version: 2023-06-01} }, claude-3-haiku-20240307: { endpoint: https://api.anthropic.com/v1/messages, headers: {anthropic-version: 2023-06-01} }, gpt-4o: { endpoint: https://api.openai.com/v1/chat/completions, headers: {Authorization: fBearer {os.getenv(OPENAI_API_KEY)}} } } def request(flow: http.HTTPFlow) - None: # ... 前面的 host/port/scheme 设置 ... # 解析请求体获取 model 字段 try: req_body json.loads(flow.request.content.decode()) model_name req_body.get(model) if model_name in MODEL_ROUTES: route MODEL_ROUTES[model_name] flow.request.url route[endpoint] for k, v in route[headers].items(): flow.request.headers[k] v logger.info(f 路由到模型: {model_name}) else: logger.warning(f⚠️ 未知模型: {model_name}, 使用默认路由) except Exception as e: logger.error(f❌ 解析 model 失败: {e})有了这个路由表你只需要在continue.json里添加新的模型对象continue_proxy.py就能自动识别并路由完全解耦。4.2 核心环节二VS Code 配置的自动化与版本管理手动创建continue.json并维护路径对于团队协作是灾难。我们用一个简单的 Bash/PowerShell 脚本来自动化它。setup_continue.sh(macOS/Linux)#!/bin/bash # 自动化部署 Continue 配置 CONTINUE_DIR$HOME/Library/Application Support/Code/User/globalStorage/shan.code-settings-sync/continue/ CONFIG_FILE$CONTINUE_DIR/continue.json # 创建目录 mkdir -p $CONTINUE_DIR # 写入配置 cat $CONFIG_FILE EOF { models: [ { title: Claude Sonnet 4.6, model: claude-3-5-sonnet-20240620, provider: openai, apiKey: , apiBase: http://localhost:8000/v1, apiType: openai } ], defaultModel: claude-3-5-sonnet-20240620 } EOF echo ✅ Continue 配置已写入: $CONFIG_FILE echo 下一步启动 mitmproxy然后重启 VS Codesetup_continue.ps1(Windows PowerShell)# 自动化部署 Continue 配置 $continueDir $env:APPDATA\Code\User\globalStorage\shan.code-settings-sync\continue\ $configFile Join-Path $continueDir continue.json # 创建目录 New-Item -ItemType Directory -Force -Path $continueDir | Out-Null # 写入配置 $configContent { models: [ { title: Claude Sonnet 4.6, model: claude-3-5-sonnet-20240620, provider: openai, apiKey: , apiBase: http://localhost:8000/v1, apiType: openai } ], defaultModel: claude-3-5-sonnet-20240620 } Set-Content -Path $configFile -Value $configContent -Encoding UTF8 Write-Host ✅ Continue 配置已写入: $configFile Write-Host 下一步启动 mitmproxy然后重启 VS Code将这个脚本和continue_proxy.py放在同一个项目目录下团队成员只需运行一次./setup_continue.sh就能完成全部配置。这不仅是效率提升更是将“环境配置”这一不可靠的人工操作变成了可版本控制、可 CI/CD 的代码资产。4.3 核心环节三从本地网关到企业级 API 网关的平滑演进这个方案的终极形态不是停留在你的笔记本上。它可以无缝演进为一个企业级的 AI API 网关。想象一下你的公司有一个统一的ai-gateway.internal域名所有开发者的 VS Code 都配置apiBase为https://ai-gateway.internal/v1。这个网关背后可以是负载均衡将流量分发到多个 Anthropic API Key避免单点限流。缓存层对重复的、确定性的 prompt如“为这个函数写单元测试”进行 Redis 缓存降低延迟和成本。审计中心所有请求日志实时推送到公司的 SIEM安全信息与事件管理系统满足合规审计要求。策略引擎集成公司内部的风控 API对每一个 prompt 进行实时扫描拦截高风险指令。而这一切的起点就是你现在在终端里运行的mitmproxy。它的脚本continue_proxy.py就是未来那个企业网关的“核心业务逻辑”原型。你不需要重写只需要把它从一个单机脚本容器化Docker然后部署到 Kubernetes 集群上。mitmproxy本身就是一个成熟的、生产就绪的代理框架它的扩展性远超你的想象。5. 常见问题与排查技巧实录那些只有踩过坑才知道的“灵性”经验5.1 问题速查表从现象到根因的精准定位现象可能根因排查命令/步骤解决方案VS Code 里CtrlShiftI无任何反应控制台也无报错continue.json文件路径错误或文件名大小写不符如Continue.jsonls -la ~/Library/Application\ Support/Code/User/globalStorage/shan.code-settings-sync/continue/确保路径完全匹配文件名为小写的continue.json代理终端显示 重定向请求但 VS Code 报Network Errormitmproxy未监听localhost:8000或端口被占用lsof -i :8000(macOS/Linux) 或netstat -ano | findstr :8000(Windows)杀死占用进程或在mitmproxy命令中指定其他端口--mode reverse:http://localhost:8001并同步修改continue.json日志里出现✅ 响应成功但 VS Code 里生成的代码全是乱码或空行continue_proxy.py中的 SSE 包装逻辑失效data:chunk 格式不正确手动 curl 代理地址curl -X POST http://localhost:8000/v1/chat/completions -H Content-Type: application/json -d {model:claude-3-5-sonnet-20240620,messages:[{role:user,content:hello}]}检查response函数中sse_content的拼接确保json.dumps(resp_body)后没有多余的空格或换行第一次请求成功后续请求全部401 Unauthorizedkeyring读取的 API Key 为空或系统凭据库损坏python -c import keyring; print(keyring.get_password(anthrpoic, api_key))重新运行keyring set anthrpoic api_key并确保输入时没有前后空格VS Code 卡死CPU 占用 100%mitmproxy的console_eventlog_verbosity级别过高大量日志 IO 拖垮性能启动时加上--set console_eventlog_verbositywarning将日志级别调低或直接禁用控制台日志--no-http2 --set console_eventlog_verbositynone这张表是我过去两周每天和各种诡异问题搏斗后提炼出的精华。它不是教科书式的罗列而是真实战场上的“伤疤地图”。5.2 独家避坑技巧那些文档里永远不会写的“灵性”经验技巧一“双代理”调试法——当一切都不工作时的终极手段有时候问题出在链路的某个你意想不到的环节。比如你的公司网络有全局代理它会劫持所有http://localhost:8000的请求。这时mitmproxy根本收不到流量。我的解决方案是启动两个mitmproxy实例。第一个实例A监听localhost:8001不做任何处理只记录日志。配置continue.json指向http://localhost:8001/v1。第二个实例B监听localhost:8000执行完整的路由逻辑。如果 A 收到了请求而 B 没有那就证明是公司代理在作祟你需要联系 IT 部门将localhost:8001加入 bypass list。这个“双代理”法让我在客户现场快速定位了三次网络策略问题比任何网络抓包都高效。技巧二VS Code 的“隐藏刷新”机制——配置变更不生效的真相你修改了continue.json重启了 VS Code但新模型还是不出现这是因为 Continue 插件会将配置缓存在内存里。它有一个不为人知的“刷新”命令在命令面板CmdShiftP里输入Continue: Reload Configuration。执行它插件会强制从磁盘重新读取continue.json。这个命令在官方文档里没有任何提及是我通过阅读插件源码的package.json里的contributes.commands字段发现的。**技巧三mitmproxy的“