Langchain-Chatchat与Nginx反向代理配置：提升系统安全性

Langchain-Chatchat 与 Nginx 反向代理：构建安全可控的本地 AI 知识库

在企业智能化转型的浪潮中，如何在享受大模型强大能力的同时，守住数据安全的底线，成为越来越多技术团队面临的现实挑战。尤其是当涉及 HR 政策、客户合同、医疗记录等敏感信息时，把文档上传到公有云 API 几乎是不可接受的选择。

这正是Langchain-Chatchat这类本地化知识库系统崛起的核心动因——它让企业在不离开内网的前提下，也能拥有一个“懂自己”的智能问答助手。但仅仅部署一个本地服务还不够，对外暴露的服务端口本身就是安全隐患。这时候，就需要Nginx作为反向代理来充当系统的“门卫”，统一入口、加密通信、过滤请求，构筑起第一道防线。

这套组合拳，本质上是在实现一种平衡：既要足够智能，又要绝对安全。而它的技术实现路径，远比听起来更精细。

Langchain-Chatchat 并不是一个从零开始的框架，而是基于LangChain构建的一套开箱即用的本地知识问答解决方案。它的核心思想是RAG（Retrieval-Augmented Generation）——先通过语义检索找到相关文档片段，再交给语言模型生成答案，从而避免 LLM “凭空编造” 的幻觉问题。

整个流程其实可以拆解为几个关键环节：

首先是文档加载与切片。用户上传 PDF、Word 或 TXT 文件后，系统会调用如PyPDF2、docx2txt等工具解析内容，并使用递归字符分割器（RecursiveCharacterTextSplitter）将长文本切分为大小适中、语义连贯的块（chunks）。这个 chunk_size 和 overlap 的设置很关键——太小可能丢失上下文，太大又会影响检索精度。实践中，500~1000 字符长度配合 50~100 的重叠通常是不错的起点。

接着是向量化和索引构建。每个文本块会被输入到嵌入模型（Embedding Model），比如 BGE 或 Sentence-BERT，转换成高维向量。这些向量随后存入 FAISS 或 Chroma 这样的向量数据库。FAISS 尤其适合本地场景，因为它由 Facebook 开发，专为高效相似度搜索优化，能在毫秒级响应中找出与用户问题最相关的几段文本。

当用户提问时，系统同样将问题编码为向量，在向量库中进行最近邻搜索，获取 top-k 条匹配结果作为上下文。然后，这些上下文和原始问题一起拼接成 Prompt，送入本地部署的大语言模型——可能是 Qwen、ChatGLM3，甚至是轻量级的 Phi-3。最终模型输出的答案返回给前端，完成一次闭环交互。

整个过程完全在本地运行，无需联网调用任何外部 API。这意味着哪怕断网，系统依然可用，特别适用于金融、军工、医疗等对隔离性要求极高的行业。

下面这段代码浓缩了这一流程的核心逻辑：

from langchain_community.document_loaders import PyPDFLoader, Docx2txtLoader from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain.embeddings import HuggingFaceEmbeddings from langchain.vectorstores import FAISS from langchain.chains import RetrievalQA from langchain_community.llms import HuggingFacePipeline # 1. 加载文档 loader = PyPDFLoader("knowledge.pdf") documents = loader.load() # 2. 文本分割 text_splitter = RecursiveCharacterTextSplitter(chunk_size=500, chunk_overlap=50) texts = text_splitter.split_documents(documents) # 3. 初始化嵌入模型（本地） embeddings = HuggingFaceEmbeddings(model_name="BAAI/bge-small-en") # 4. 构建向量数据库 db = FAISS.from_documents(texts, embeddings) # 5. 加载本地语言模型（示例使用 HuggingFace pipeline） llm = HuggingFacePipeline.from_model_id( model_id="google/flan-t5-base", task="text2text-generation", model_kwargs={"temperature": 0.7, "max_length": 512}, ) # 6. 创建问答链 qa_chain = RetrievalQA.from_chain_type( llm=llm, chain_type="stuff", retriever=db.as_retriever(search_kwargs={"k": 3}), return_source_documents=True ) # 7. 查询示例 query = "公司年假政策是如何规定的？" result = qa_chain.invoke({"query": query}) print("答案:", result["result"])

值得注意的是，虽然这段脚本能跑通，但在生产环境中还需考虑更多工程细节：模型加载是否稳定？向量库是否支持持久化？异常处理机制是否完备？这些都是决定系统能否长期可靠运行的关键。

而即便后端做得再完善，如果直接对外暴露服务端口（比如:8080），风险依然极高。攻击者可以通过端口扫描轻易发现服务存在，进而尝试各种注入或探测攻击。更不用说 HTTP 明文传输带来的中间人窃听问题。

这就引出了 Nginx 的角色。它不只是简单的“转发器”，更是整个系统的安全网关。

典型的部署结构是这样的：Nginx 运行在边界服务器上，监听标准 HTTPS 端口（443），而 Langchain-Chatchat 服务则绑定在127.0.0.1:8080，仅接受本地回环访问。所有外部请求必须先经过 Nginx 处理，才能抵达后端。

这种架构的好处显而易见：

• 隐藏真实服务地址：外部无法得知后端运行在哪个端口，也无法判断其技术栈，大大降低被针对性攻击的可能性。
• 强制启用 HTTPS：Nginx 可以集中管理 SSL 证书，实现 TLS 加密通信，防止数据在传输过程中被截获或篡改。
• 灵活的路由控制：可以根据路径分发流量，例如/api/*转给 Langchain-Chatchat，静态资源走另一个目录，未来扩展其他服务也更方便。
• 统一的日志审计：所有访问记录都集中在 Nginx 日志中，便于监控异常行为、排查问题，满足合规审计需求。

以下是一个典型的 Nginx 配置示例：

server { listen 80; server_name ai.company.com; # 强制跳转 HTTPS return 301 https://$server_name$request_uri; } server { listen 443 ssl http2; server_name ai.company.com; # SSL 证书配置 ssl_certificate /etc/ssl/certs/chatchat.crt; ssl_certificate_key /etc/ssl/private/chatchat.key; # 安全强化参数 ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512; ssl_prefer_server_ciphers off; # 反向代理设置 location / { proxy_pass http://127.0.0.1:8080; proxy_http_version 1.1; proxy_set_header Upgrade $http_upgrade; proxy_set_header Connection 'upgrade'; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_cache_bypass $http_upgrade; # 禁用缓存，确保每次请求都实时响应 proxy_set_header Cache-Control "no-cache"; } # 可选：添加 Basic Auth 认证 # location / { # auth_basic "Restricted Access"; # auth_basic_user_file /etc/nginx/.htpasswd; # include /etc/nginx/proxy_params; # proxy_pass http://127.0.0.1:8080; # } # 日志记录 access_log /var/log/nginx/chatchat_access.log; error_log /var/log/nginx/chatchat_error.log; }

其中X-Forwarded-*系列头字段尤为重要。它们能让后端服务正确识别用户的原始 IP 地址、使用的协议（HTTPS）、以及真实的 Host 值。否则，日志里看到的全是127.0.0.1，会给调试带来极大困扰。

配置完成后，只需执行：

sudo ln -s /etc/nginx/sites-available/langchain-chatchat /etc/nginx/sites-enabled/ sudo nginx -t && sudo systemctl reload nginx

即可生效。

当然，这只是基础配置。在实际生产中，你可能还需要进一步加固：

• 启用Basic Auth或集成 JWT/OAuth 插件，实现账号级别的访问控制；
• 使用ModSecurity + OWASP 规则集构建 WAF，防御 SQL 注入、XSS 等常见 Web 攻击；
• 配置rate limiting，防止单个 IP 恶意刷接口；
• 结合Let’s Encrypt实现证书自动续期，避免因证书过期导致服务中断；
• 接入 Prometheus 和 Grafana，对请求量、延迟、错误率进行可视化监控。

此外，系统层面的安全也不容忽视：Langchain-Chatchat 应以非 root 用户运行，限制其文件系统权限；定期备份向量数据库和原始文档；对使用的 LLM 和 Embedding 模型做好版本管理，以便快速回滚。

最终形成的架构如下：

[用户浏览器] ↓ HTTPS 请求 [Nginx 反向代理] ←→ [SSL | 访问控制 | 日志审计] ↓ 本地 HTTP 转发 [Langchain-Chatchat 后端] ←→ [向量数据库 FAISS/Chroma] ↓ [本地 LLM 模型（如 Qwen、ChatGLM3）]

这是一种典型的“外松内紧”设计：对外只开放一个受控的 HTTPS 入口，内部则是完全封闭的数据处理闭环。用户无感知地完成了安全访问，而企业则牢牢掌控着数据主权。

这种方案的价值，在于它提供了一种可落地的折中路径。相比直接调用通义千问、文心一言等公有云 API，它虽然前期投入更高，但换来的是真正的数据自主权、更低的长期成本、更高的响应速度和更强的定制能力。尤其对于需要满足 GDPR、等保二级以上要求的企业来说，几乎是唯一可行的选择。

如今，类似的架构已广泛应用于企业知识管理、内部客服机器人、合规审查辅助等多个高安全要求场景。它不仅是技术组件的简单堆叠，更是一种思维方式的转变：AI 的价值不在“多聪明”，而在“能不能放心用”。

而这，或许才是智能化时代最值得追求的方向。