Qwen3-0.6B部署踩坑记录：网络代理导致调用失败的解决办法-开发者社区

Qwen3-0.6B部署踩坑记录：网络代理导致调用失败的解决办法

1. 背景与问题描述

Qwen3（千问3）是阿里巴巴集团于2025年4月29日开源的新一代通义千问大语言模型系列，涵盖6款密集模型和2款混合专家（MoE）架构模型，参数量从0.6B至235B。其中，Qwen3-0.6B作为轻量级模型，因其低延迟、高响应速度和适合边缘部署的特点，广泛应用于本地推理、嵌入式AI服务和快速原型开发场景。

在实际部署过程中，开发者常通过CSDN提供的GPU镜像环境进行快速启动。典型流程为：启动镜像后，在Jupyter Notebook中使用LangChain调用本地部署的Qwen3-0.6B模型。然而，不少用户反馈即使配置正确，仍会遇到模型调用失败的问题，表现为连接超时、HTTP 502错误或ConnectionError异常。

本文将重点分析一种常见但易被忽视的问题——网络代理配置冲突，并提供完整的排查路径与解决方案。

2. 典型调用代码与现象复现

2.1 LangChain调用示例

以下是在Jupyter环境中调用Qwen3-0.6B的标准LangChain代码：

from langchain_openai import ChatOpenAI import os chat_model = ChatOpenAI( model="Qwen-0.6B", temperature=0.5, base_url="https://gpu-pod694e6fd3bffbd265df09695a-8000.web.gpu.csdn.net/v1", # 当前jupyter的地址替换，注意端口号为8000 api_key="EMPTY", extra_body={ "enable_thinking": True, "return_reasoning": True, }, streaming=True, ) chat_model.invoke("你是谁？")

执行上述代码后，预期应返回模型的自我介绍内容。但在部分环境中，会抛出如下异常：

requests.exceptions.ConnectionError: HTTPSConnectionPool(host='gpu-pod694e6fd3bffbd265df09695a-8000.web.gpu.csdn.net', port=443): Max retries exceeded with url: /v1/chat/completions

2.2 初步排查方向

该错误提示表明客户端无法建立到目标base_url的连接。可能原因包括：

模型服务未正常启动
base_url地址错误或端口不匹配
网络策略限制（如防火墙、VPC隔离）
系统级网络代理干扰

前三种情况已有较多公开文档支持，而第四种“代理干扰”则容易被忽略，尤其是在企业内网或共享开发环境中。

3. 代理问题的识别与验证

3.1 检查环境变量中的代理设置

许多Linux发行版和容器环境会预设http_proxy、https_proxy和no_proxy环境变量。这些变量会被Python的requests库自动继承，从而影响所有HTTP请求行为。

在Jupyter Notebook中运行以下代码，检查当前环境的代理配置：

import os print("HTTP_PROXY:", os.environ.get("HTTP_PROXY")) print("HTTPS_PROXY:", os.environ.get("HTTPS_PROXY")) print("NO_PROXY:", os.environ.get("NO_PROXY"))

输出示例：

HTTP_PROXY: http://proxy.corp.com:8080 HTTPS_PROXY: http://proxy.corp.com:8080 NO_PROXY: localhost,127.0.0.1,.local

可以看到，尽管目标地址是公网域名，但由于未将CSDN GPU Pod的域名加入NO_PROXY白名单，请求仍会被重定向至企业代理服务器。而该代理通常无法访问内部Kubernetes服务暴露的Pod域名，导致连接失败。

3.2 使用curl直接测试连通性

在终端或Jupyter的命令行单元中执行：

curl -v https://gpu-pod694e6fd3bffbd265df09695a-8000.web.gpu.csdn.net/v1/models

若返回502 Bad Gateway或Could not resolve host，但更换为公共API（如api.openai.com）可正常访问，则进一步说明代理对特定域名的处理存在问题。

4. 解决方案与最佳实践

4.1 方案一：临时清除代理环境变量

最直接的方式是在调用模型前，显式取消代理设置：

import os # 临时清除代理环境变量 os.environ.pop("HTTP_PROXY", None) os.environ.pop("HTTPS_PROXY", None) os.environ.pop("http_proxy", None) os.environ.pop("https_proxy", None) # 再次初始化模型 chat_model = ChatOpenAI( model="Qwen-0.6B", temperature=0.5, base_url="https://gpu-pod694e6fd3bffbd265df09695a-8000.web.gpu.csdn.net/v1", api_key="EMPTY", extra_body={ "enable_thinking": True, "return_reasoning": True, }, streaming=True, ) response = chat_model.invoke("你是谁？") print(response.content)

此方法适用于单次调试或脚本运行场景。

4.2 方案二：配置NO_PROXY白名单

更优雅的做法是将CSDN GPU Pod的域名模式加入NO_PROXY，避免全局关闭代理：

export NO_PROXY="${NO_PROXY},*.web.gpu.csdn.net,gpu-pod*.web.gpu.csdn.net"

可在Jupyter的启动脚本或Dockerfile中预先设置，确保所有子进程继承正确的网络策略。

4.3 方案三：在LangChain中绕过代理

若需保留代理用于其他API调用（如外部知识库），可通过自定义httpx客户端方式，为特定请求禁用代理：

from langchain_openai import ChatOpenAI import httpx # 创建无代理的传输层 transport = httpx.HTTPTransport(proxy=None) client = httpx.Client(transport=transport, timeout=30.0) chat_model = ChatOpenAI( model="Qwen-0.6B", temperature=0.5, base_url="https://gpu-pod694e6fd3bffbd265df09695a-8000.web.gpu.csdn.net/v1", api_key="EMPTY", extra_body={ "enable_thinking": True, "return_reasoning": True, }, streaming=True, http_client=client, ) chat_model.invoke("你是谁？")

该方法实现了细粒度网络控制，既不影响其他模块的代理需求，又能确保本地模型调用成功。