企业官网建设流程全解析

先说个让我印象很深的事。某团队给内部知识库做了一个基于LangChain的问答服务，容器一跑起来就直接对外开放。结果没撑过一周，大模型API费用报警，账单比预算超了十倍。查下来发现，不是业务量涨了，而是他们部署LangChain时用Docker把容器端口原样暴露到了公网，又被自动化扫描工具逮了个正着。这类事最近真不少见，所以这篇就专门聊聊LangChain API暴露后的攻击路径，以及短期内必须检查的5个Docker配置漏洞。不管你是AI应用开发者、运维还是自己折腾部署的个人开发者，下面的内容都可以直接照着自查。

LangChain只是工具链，本身不背锅，真正出问题的是部署环境。很多同学以为“API是内网的，不会有人扫到”，可实际上容器一旦映射到宿主机端口，防火墙又没有限制来源，攻击者用常规端口扫描就能把服务找出来。我见过太多把LangChain服务当成普通Web服务部署，结果暴露了内部Prompt、模型密钥、业务数据还浑然不知的案例。这篇文章会把从定位问题到修复加固的完整流程讲清楚，关键命令都会贴出来。

1. 为什么LangChain的API会成为攻击目标

1.1 从一次事故说起：API暴露的代价

先还原一下那个翻车现场。这套系统本身不复杂：LangChain做编排，接了大模型API，后端包了一个HTTP服务（比如FastAPI），然后Docker部署在一台有公网地址的服务器上。开发同学图省事，直接用了类似这样的命令：

docker run -d -p 8000:8000 mylangchain-app

这条命令的问题在于，-p 8000:8000默认会绑定宿主机所有网卡，包括公网网卡。也就是说，只要服务器有公网IP，你的服务就等于挂到了公网上，任何人访问http://服务器IP:8000都能直接调用。攻击者的扫描器根本不需要多聪明，常见端口扫一遍就能发现。

后果分几层来看。如果这个LangChain服务没有做认证，任何人都能调用你的大模型接口，消耗的是你的额度；如果业务逻辑里带了文件读取、搜索、代码执行之类的能力，那攻击者可以直接发恶意Prompt，绕过内容限制，甚至套出你的系统Prompt和敏感上下文。最麻烦的是，很多LangChain应用还会把对话历史、向量数据库连接、缓存配置这些都打包在环境变量里，一旦容器配置暴露，等于连带泄露了底层依赖的凭据。

这个案例的最终处理很麻烦：改密钥、清缓存、下线再上线、还要排查有没有数据被导走。花了整整一天时间，而根源就是一条端口映射命令和缺少认证层。所以这5个Docker配置漏洞，每一个都值得认真排一遍。

1.2 攻击者是怎么找到你的API的

很多人觉得内网服务不会被发现，这个想法在云服务器上完全不成立。攻击者找LangChain API，主要是三类途径：

• 全网扫描：用端口扫描工具对某个IP段做批量探测，识别开放了8000、8080、8501、9090这类常见Web端口的服务。扫描是自动化的、持续的，不是针对你，但撞上是迟早的事。
• 指纹识别：扫到端口后，攻击者会进一步看HTTP响应头、/docs、/openapi.json这类路径。FastAPI的接口文档路径几乎是公开的秘密，看到openapi.json，基本就等于告诉攻击者“我这个服务可以调用哪些接口”。
• 搜索引擎和网络测绘：现在不少测绘平台会定期爬取全网开放服务，你的服务暴露一段时间后，响应特征会被收录。即便后来加了防火墙，历史索引仍然可能指向这个地址。

我自己做过一个测试：在一台没有任何安全防护、只跑了一个LangChain服务的云主机上，24小时内日志里出现了来自几十个不同IP的探测请求，内容包括请求/docs、/redoc、试图查看根路径信息等。这说明暴露公网的AI服务，存活时间真的很短。

1.3 AI应用API为什么特别招黑

既然普通Web服务也经常暴露，为什么LangChain这类AI应用API尤其容易被盯上？核心原因是这类服务的“利用价值”太高了。

大模型API有真实成本，攻击者调用你的LangChain服务，实际上是在烧你的钱。如果是接的按Token计费的大模型API，几千次恶意请求就能产生一笔不小的账单。更“香”的是，LangChain应用往往配置了多种工具，比如网页搜索、数据库查询、代码执行，攻击者可以拿它当免费的代理工具。有人甚至会把你的服务当成中转站，用来批量生成内容、发送请求，借助你的IP和额度做各种自动化操作。

另外，LLM应用还存在Prompt注入的问题。攻击者通过构造特殊输入，可能让LangChain的Agent执行本不该执行的工具调用。一个暴露的API如果没有充分防护，等于把整套工具链的使用权交给了攻击者。理解了这个背景，你再看下面这5个Docker配置漏洞，就明白为什么每一条都值得重视了。

2. 立即检查的5个Docker配置漏洞

2.1 漏洞一：端口映射一开到底，服务裸奔到公网

这是最常见、破坏力也最大的一条。好多人对Docker端口映射的理解就是“把容器端口暴露出去”，完全没意识到默认绑定的是0.0.0.0。它意味着宿主机上所有网络接口都能访问到这个端口，公网接口自然也包括在内。

我见过最典型的错误写法：

ports: - "8000:8000"

这种写法在docker-compose.yml里非常普遍，看起来没问题，实际上就是把服务直接挂到公网。对比一下，正确的做法是至少要写明绑定的IP：

ports: - "127.0.0.1:8000:8000"

只绑定回环地址后，外部无法直接访问，只有宿主机本机或者通过反向代理转发才能连接。很多人会担心：那我前端页面怎么调用？答案是用Nginx或Caddy这类反向代理统一入口，由反向代理来做HTTPS、认证、限流。Docker容器本身负责跑应用，入口层单独用一个代理容器来管，这样职责清晰，安全边界也明确。

判断你的端口是否裸奔，其实很简单：

ss -tlnp | grep 8000

看本地地址那一列，如果是0.0.0.0:8000，那就是所有接口都监听了；如果是127.0.0.1:8000，才是安全的绑定方式。

2.2 漏洞二：密钥硬编码在镜像和编排文件里

LangChain应用一般都要配大模型API Key、向量库连接串、数据库密码等敏感信息。很多项目的做法是把这些直接写进Dockerfile的ENV指令，或者写进docker-compose.yml的environment节点，再或者塞进项目源码的.env文件但没加到.gitignore里。

这些做法各有各的坑。写在Dockerfile里最致命，因为docker build之后，ENV层面的值会被固化到镜像的配置元数据里。任何人拿到你的镜像，执行一句：

docker history mylangchain-app

就能从上到下看到每一层执行的指令，包括ENV OPENAI_API_KEY=sk-xxxx这样的明文。如果不能直接执行Docker命令，镜像被推到公开仓库后，别人拉下来一样能通过docker inspect看到环境变量。

写在docker-compose.yml里的问题也差不多。编排文件往往会提交到代码仓库，一旦仓库泄露（哪怕是私有仓库被误配成了公开），所有密钥全部见光。更隐蔽的问题是，Docker在运行容器时，环境变量会以明文形式出现在宿主机的进程信息里：

docker inspect 容器ID

同样能把环境变量看个底朝天。所以密钥管理的第一原则是：不要写在任何会被长期留存的文件里。

2.3 漏洞三：服务裸奔，没有认证和限流

这个漏洞和第一个常见漏洞经常一起出现，但即使你只把服务绑到了内网或者加了防火墙白名单，认证和限流依然是必须的一层。

LangChain服务如果用的是FastAPI，默认会开放/docs和/openapi.json。这两个路径本身不是漏洞，但它们是“门牌号”，会直接告诉访问者你的服务暴露了哪些接口。比如你有一个/chat接口，攻击者看到之后，不需要猜测端点路径，直接就能构造请求发起调用。

没有认证的情况下，调用成本趋近于零。攻击者的脚本不需要登录、不需要令牌，一条POST请求就完事。要是没有限流，攻击者还可以并发刷接口，把你的大模型额度快速消耗掉。更隐蔽的是，LangChain服务如果接入了记忆、文件检索、工具调用等能力，攻击者可以通过精心构造的Prompt让系统执行预期之外的动作。没有认证和护栏的时候，这些风险都会被放大。

这也是为什么我强调：哪怕你的服务跑在内网、哪怕只给自己人用，也至少要加一层简单的API Key校验。真实案例里，内网渗透攻击的第一目标往往是横向移动，你的LangChain服务一旦能访问内网其他资源，又没有访问控制，那它本身就会变成跳板。

2.4 漏洞四：容器以root身份运行，权限壁垒形同虚设

从Docker的角度看，容器内的root并不等于宿主机上的root，但这只说明权限没有直接打通，不代表安全。真正的问题是：如果容器以root身份运行，攻击者一旦通过LangChain服务拿到容器内的shell（比如借助代码执行类工具、或者某个依赖的远程执行漏洞），就能在容器里做很多事情，包括安装工具、读取挂载的敏感目录、尝试逃逸。

检查起来很简单：

docker inspect --format='{{.Config.User}}' 容器ID

如果输出为空或root，那就是root运行。从安全角度，建议在Dockerfile里创建专用用户并切换到非root身份：

RUN useradd -m -u 1000 appuser USER appuser

还可以在docker-compose.yml里显式声明：

user: "1000:1000"

另外要注意，很多镜像默认有大量用不到的系统工具，比如curl、wget、bash等，攻击者进到容器后可以直接拿来下载恶意工具。这里我们不用纠结每个命令会不会造成多大的危害，思路很简单：能不装的不装、不能用root就不用root、能限制的能力就限制。后续加固章节会给出具体的配置。

2.5 漏洞五：镜像和依赖库长期不更新

最后一个漏洞隐蔽性最高，但一旦被利用，后果往往也很严重。LangChain和它的依赖（特别是底层的大模型SDK、HTTP框架、序列化库）迭代速度很快，经常会有安全修复。如果你在部署时用了某个固定版本的基础镜像，比如python:3.9而不是python:3.9-slim，或者锁定了某个旧版LangChain，时间一长，镜像里就会积累已知漏洞。

攻击者不需要知道你用的具体版本，他们可以用自动化工具扫描镜像中的组件指纹，比对公开漏洞库，然后针对性发起攻击。比如某个老版本的反序列化库存在远程代码执行漏洞，刚好你的LangChain服务用到了它，那攻击者只需要一条特制请求就能打穿服务。

要检查镜像本身是否有已知漏洞，可以用Docker自带的扫描命令：

docker scan mylangchain-app

或者你构建时就用带漏洞扫描的镜像仓库，也能在Push时自动检测。另外，基础镜像更新频率低，会导致整个攻击面跟着变旧。这不只是“换个新版本”的问题，更新依赖的同时还要注意兼容性测试，避免LangChain升级后接口行为变化影响业务。

3. 5分钟自查：给容器做一次“安全体检”

3.1 一条命令扫清关键暴露面

先别急着改配置，先把你手上已经跑着的容器全部列出来，做一个快速体检。下面这组命令是我每次接到这类排查都会用的一套组合拳，没有多余的步骤：

# 1. 列出所有运行中的容器 docker ps -a # 2. 查看每个容器的端口映射情况 docker ps --format "table {{.Names}}\t{{.Ports}}" # 3. 检查宿主机实际监听端口 ss -tlnp # 4. 查看容器内运行的用户身份 for c in $(docker ps -q); do echo "=== $c ===" docker inspect --format='{{.Config.User}}' $c done

第一条命令看全貌，第二条重点看端口映射，第三条核实宿主机上真的有端口在监听，第四条判断是不是root运行。这四步可以在一两分钟内跑完，不用装任何额外工具。

如果服务是通过docker-compose.yml起的，那你还需要再检查一下编排文件本身：

docker-compose config

这个命令会解析编排文件并输出实际生效的配置，你可以看到ports、environment、user这些字段最终的值。注意检查environment下有没有明文密钥，端口绑定有没有写成0.0.0.0。解析后的输出不会直接告诉你安全不安全，但它会把配置的全貌暴露出来，方便人工判断。

3.2 检查结果的判断标准

命令跑完，怎么判断结果到底有没有问题？我一般按下面这几条标准来对照：

拿这个表格去对照，基本上能够分出个大概。我当时处理上文那个翻车项目时，对照下来五条几乎全中：端口绑定0.0.0.0、环境变量里有大模型Key、服务没有任何认证、容器是root跑的、镜像还是构建了半年没动过的老版本。整个排查过程不到10分钟，问题清单就出来了。

3.3 发现问题后的紧急处置流程

自查发现问题之后，第一反应不应该是马上改配置，而是先做紧急处置，避免攻击者继续利用。我建议按这个顺序来：

先把最直接的暴露面砍掉。如果服务还在跑，先停掉容器或者用防火墙直接把外部访问断掉。最简单的方式是让服务只监听回环地址，或者干脆先把容器停了，等修复完成再重启。

接着检查日志，看看有没有已经被攻击的痕迹。Docker容器日志在宿主机上通过docker logs 容器ID查看，重点看有没有高频请求、异常路径、奇怪的Prompt。如果发现有可疑调用，还要检查大模型平台的调用记录，确认消耗了多少额度、用了哪些IP。

最后再决定要不要改密钥。这一步很多人会犹豫，觉得“就是端口暴露了一下，还没被攻击，没必要换Key”。但我的建议是，只要服务暴露过公网且没有认证，就要默认密钥已经泄露，直接轮换。 因为扫描器和攻击者的行为你是看不全的，日志里看不到的不代表没发生，换一次密钥的成本远低于被恶意刷单的损失。

4. 加固实操：把5个漏洞逐个堵上

4.1 端口收敛：让服务只对本机可见

端口暴露的问题，核心在于“对外暴露”和“对外提供服务”这两个概念被模糊了。修复思路也很简单：你不在Docker层面把端口暴露出去，而是通过反向代理统一对外发布。

先看Docker运行方式怎么做。把：

docker run -d -p 8000:8000 mylangchain-app

改成：

docker run -d -p 127.0.0.1:8000:8000 mylangchain-app

这样服务只在宿主机本机监听，外部网络无法直接访问。如果你的场景是多个服务通过docker-compose一起编排，而且服务之间需要互相通信，那在同一个Docker网络内直接通过服务名访问端口就行，不需要映射到宿主机。比如LangChain服务和向量数据库之间用http://vector-db:6333这种内部地址，宿主机上根本不需要暴露向量库端口。

然后补一个反向代理作为统一入口。Nginx配置里核心的几行是这样的：

server { listen 443 ssl; server_name api.example.com; ssl_certificate /etc/nginx/certs/fullchain.pem; ssl_certificate_key /etc/nginx/certs/privkey.pem; location / { proxy_pass http://127.0.0.1:8000; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; } }

反代的作用不只是转发，它还能统一在这里做HTTPS终止、接入WAF规则、配置限流。以后要换认证方式，也只需要改这一层，不用动LangChain服务本身。这也是为什么我坚持把“认证”和“入口”放在同一层来管理，维护成本会低很多。

4.2 密钥搬家：从镜像里抹掉所有敏感信息

密钥管理没有想象中复杂，核心原则只有一条：敏感信息不进镜像、不进代码仓库、不写进编排文件。具体做法可以分三步。

第一步，把密钥从Dockerfile和docker-compose.yml中全部移除。Dockerfile里不再写ENV OPENAI_API_KEY=xxx，docker-compose.yml里不再写environment: OPENAI_API_KEY: xxx。

第二步，改用.env文件来承载环境变量。在项目根目录放一个.env文件，内容形如：

OPENAI_API_KEY=sk-xxxxxxxx VECTOR_DB_URL=http://vector-db:6333

然后确保这个文件被加入.gitignore，并且在编排文件里通过env_file引入：

services: langchain-app: env_file: - .env

第三步也是很多人容易忽略的：清理历史镜像和构建缓存。镜像是分层存储的，就算你改了新的Dockerfile，旧的镜像层仍然可能带着明文密钥存在本地甚至远端仓库里。你需要把包含敏感信息的镜像层彻底清理掉：

docker system prune -a

同时去镜像仓库把暴露了密钥的历史Tag删除或覆盖。如果项目已经提交到了代码仓库，还要检查提交历史里有没有出现过.env文件，一旦出现过，光增删文件不够，需要重写历史或直接轮换密钥。

有个细节要提醒：.env文件的权限也要管。默认创建的文件权限可能是644，其他系统用户也能读。放到生产服务器后，建议执行：

chmod 600 .env

这样只有文件所有者能读写，减少本机横向读取的风险。

4.3 认证与限流：在服务前面加一道门

密钥搬完之后，接着要把认证和限流补齐。这里我推荐的做法是直接在反向代理层解决，不需要在LangChain服务代码里改动任何东西。毕竟改代码要重新构建、重新测试，而Nginx加个配置几秒钟就能生效。

最简单的方案是Basic Auth，适合内部工具或小范围使用：

location / { proxy_pass http://127.0.0.1:8000; auth_basic "Restricted Access"; auth_basic_user_file /etc/nginx/conf.d/.htpasswd; }

密码文件用openssl passwd -apr1生成条目。优点是配置简单，缺点是Basic Auth在明文HTTP下等于裸奔，所以一定要配合HTTPS使用。如果是正式的对外服务，更建议用API Key的方式，让客户端在请求头里带上Authorization: Bearer <token>，然后在Nginx里做校验。

限流也是反代层顺手就把事办了。Nginx的limit_req模块可以限制每个客户端IP的请求频率：

limit_req_zone $binary_remote_addr zone=apiauth:10m rate=10r/m; server { location / { limit_req zone=apiauth burst=20 nodelay; proxy_pass http://127.0.0.1:8000; } }

这里rate=10r/m是每分钟10次请求，burst=20允许突发20个请求排队，nodelay表示突发期间不排队直接处理。对大模型调用场景来说，这个频率已经够保守，能有效防止脚本刷量。如果业务确实需要更高的并发，可以根据你实际的调用频率调整。

认证和限流组合起来，即使你的服务被人发现了，对方没有Key就进不来，进来之后频率也被限制住了，损失可以控制在可控范围内。

4.4 权限降级：让容器不再以root运行

容器权限这块，我建议一次做三件事：换非root用户、去掉不必要的Linux能力、把文件系统设为只读。三件事可以在docker-compose.yml里一次配齐。

先看Dockerfile部分。在镜像构建阶段就创建好用户并切换过去：

FROM python:3.11-slim # 创建普通用户 RUN useradd --create-home --shell /bin/bash appuser WORKDIR /app # 复制依赖并安装 COPY requirements.txt . RUN pip install --no-cache-dir -r requirements.txt # 复制代码 COPY --chown=appuser:appuser . . # 切换用户 USER appuser CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

注意COPY --chown=appuser:appuser，这行是把文件所有权分给普通用户，避免应用运行时报权限错误。很多同学改完USER appuser之后启动失败，多半就是忽略了文件属主问题。

然后看docker-compose.yml补安全配置：

services: langchain-app: build: . user: "1000:1000" read_only: true security_opt: - no-new-privileges:true cap_drop: - ALL tmpfs: - /tmp

read_only: true把根文件系统设为只读，应用如果需要写临时文件，用tmpfs挂一个匿名内存盘到/tmp。cap_drop: ALL表示去掉容器所有内核能力，普通应用完全够用。no-new-privileges防止进程提权。这几项加起来，就算攻击者真的打进了容器，他没有root权限、没有额外能力、文件系统也写不进去，想进一步搞事情会困难很多。

最容易被忽略的一点是：挂载宿主机目录时，不要直接给读写权限。如果容器需要访问宿主机上的某个目录，在docker-compose.yml里用ro限制：

volumes: - /data:/data:ro

这样即使应用被攻破，攻击者也无法修改宿主机上挂载目录里的文件。

4.5 镜像治理：从源头压缩攻击面

镜像层面的加固，核心是“做小”和“保持新”。做小指的是用更精简的基础镜像，把不需要的软件包都扔掉，缩小攻击者可以借用的工具范围。

我建议把基础镜像从python:3.11换成python:3.11-slim，尺寸减少的同时，系统里的额外工具也少了很多。如果你的依赖库不涉及底层编译，甚至可以考虑python:3.11-alpine。不过Alpine镜像使用的C语言库和常见Linux发行版不同，部分Python包可能需要额外编译，这个需要根据项目实际情况测试，不是无脑切换。

多阶段构建是另一个很实用的手段。比如在构建阶段需要gcc来编译某些依赖，但运行时不需要这些编译工具，那就用两个阶段分离：

# 构建阶段 FROM python:3.11-slim AS builder COPY requirements.txt . RUN apt-get update && apt-get install -y build-essential && pip install --prefix=/install -r requirements.txt # 运行阶段 FROM python:3.11-slim COPY --from=builder /install /usr/local COPY --chown=appuser:appuser . /app USER appuser CMD ["uvicorn", "main:app", "--host", "0.0.0.0", "--port", "8000"]

这样运行镜像里只保留运行需要的文件，编译工具不会出现在最终产物里。攻击者进入容器后，连gcc都没有，想临时编译工具就困难了。

保持新这个事，需要养成习惯。我给自己定的节奏是每两个月做一次依赖更新检查，重点关注LangChain、FastAPI、pydantic这些核心依赖的版本变化。不是每一次更新都要马上跟，但至少要做到知道哪些版本有安全通告，然后评估自己是否需要升级。你可以用Docker的漏洞扫描工具在CI阶段自动检测，也可以在本地定期手动执行docker scan。

5. 常见问题与排查技巧实录

5.1 自查时最常踩的坑

先分享几个我在处理这类问题时见过的“坑”，有些是理解上的误区，有些是操作上的盲区。

第一个误区：以为容器内部端口是安全的，不需要控制宿主机的对外暴露。这个在前面反复强调过，但每次排查还是能看到有人把容器端口直接映射到0.0.0.0。核心原因是很多教程里默认写了-p 8000:8000，没人告诉你这会在公网网卡上监听。所以自查的时候，千万别只看容器内部有什么，一定要看宿主机端口监听在哪个地址。

第二个误区：只检查当前运行中的容器，不看已经停止的容器和镜像。攻击者不一定会对正在运行的服务下手，他可能会反过来利用暴露在镜像仓库里的历史镜像获取密钥。所以自查时，docker ps -a和docker images都要看一遍，确认没有带敏感信息的镜像泄露在外面。

第三个误区：改了配置就以为安全了，没重启容器。docker-compose.yml修改后需要docker-compose up -d重建容器，Dockerfile修改后需要重新build镜像，否则你改的配置根本没生效。有一次排查，对方说已经改了绑定地址，但ss -tlnp一看还是老样子，最后发现只是改了文件没重建。

5.2 出事之后的排查思路

如果你已经发现API被攻击了，先别慌，按下面的思路来排查，能省很多时间。

第一步，锁定访问来源。从容器日志里把访问IP提取出来，排序统计：

docker logs 容器ID 2>&1 | grep "GET\|POST" | awk '{print $1}' | sort | uniq -c | sort -rn

注意，日志格式取决于你的应用写不写访问日志、写到什么格式，但思路是一样的：找到高频访问IP和异常请求路径。如果日志里没记请求来源，那说明你的服务连访问日志都没开，这是一个需要补的盲区，修复之后赶紧把访问日志打开。

第二步，追溯大模型平台的调用记录。大多数大模型平台提供调用明细查询，可以看到每次请求消耗的Token、来源IP。如果发现大量来自陌生IP的高消耗请求，基本可以确认是被刷了。这一步还可以帮你估算损失，方便后续做成本复盘。

第三步，反查漏洞入口。对照前面5个漏洞清单，看是端口裸奔被扫描到了，还是没有认证被直接打了个正着，还是密钥泄露后被别人“借用”了账户。找到入口，才能针对性地修复。我见过一个案例，对方花了很久排查代码漏洞，最后发现其实是配置在镜像里的API Key被人拉走了，根本不需要打服务本身，直接用Key调模型API就行。这个方向起初完全被忽略了。

5.3 监控与告警的落地配置

安全加固做完，不代表一劳永逸，监控和告警要跟上。这里我建议关注两个层面：一是Docker层面的运行状态，二是应用层面的请求特征。

Docker层面的监控，最简单的方式是定期检查容器运行状态和资源占用。如果某个LangChain服务的CPU或内存持续飙高，很可能是被恶意请求打爆了。你可以用docker stats手动看，也可以接入简单的监控脚本，超过阈值就发个通知。

应用层面的告警更关键。核心指标是请求频率和Token消耗。如果你用的是大模型API，把每日消耗额度设一个告警阈值，超过即通知。很多平台的默认告警阈值设得很高，等通知到的时候钱已经烧了不少，建议把阈值调低一点。

日志方面，强烈建议开启结构化访问日志。使用FastAPI的话，可以通过中间件记录每个请求的来源IP、路径、状态码、耗时，输出到stdout，然后让Docker统一收日志。这样再发生问题的时候，docker logs就能直接看到攻击特征，不用再去容器里翻文件。

如果预算和精力允许，可以在反代层接入WAF规则，拦截常见的扫描路径和恶意头部。不过WAF不是万能的，它挡不住业务层逻辑漏洞，只能挡一部分自动化扫描和基础攻击。对大部分中小团队来说，把前面5个基础漏洞补好、再加上日志和告警，已经能挡住绝大多数攻击者。真正高段位的定向攻击，那是另一个量级的威胁，不是单靠Docker配置能解决的。

我个人在实际排查中体会最深的一点是：安全问题一半靠技术，一半靠流程。技术上的修复可能只需要一个下午，难的是让整个团队以后每一次部署都记得检查端口绑定、密钥管理和权限配置。我现在自己部署LangChain服务时，会把前面那张自查表放在项目文档最前面，每次上线之前照着过一遍。这个习惯看起来简单，但确实帮我避掉过不只一次潜在的翻车现场。希望这份清单对正在排查的你也有用，趁现在还没出事，花个十几分钟把5个漏洞过一遍，比事后补救要划算得多。