Node.js中间件在AKS集群与本地运行的行为差异排查

1. 为何AKS上api_key请求头丢失，而apikey可被获取？ #

核心原因是AKS集群默认使用的Nginx Ingress代理会过滤带下划线的HTTP请求头。早期部分HTTP服务器对下划线处理存在兼容性问题，Nginx默认开启了underscores_in_headers off配置，会直接丢弃含下划线的请求头，所以api_key会被过滤，无下划线的apikey则能正常传递。

另外你的app.js存在CORS配置顺序问题：先手动设置了Access-Control-Allow-Headers，之后又调用app.use(cors())，若cors()未显式配置允许api_key，可能覆盖之前的设置，但这是次要因素，主要还是Ingress的过滤规则导致。

2. 为何process.env.API_KEY包含\n，而客户端密钥没有？ #

这是创建K8s Secret的操作细节导致的：

• 若你通过kubectl create secret generic xxx --from-literal=API_KEY=$(cat keyfile.txt)创建Secret，且keyfile.txt末尾自带换行符，这个换行会被一并写入Secret；
• 若用echo "your-api-key" | kubectl create secret ...，echo命令默认会在输出末尾添加换行符，最终导致Secret中的API_KEY值带\n。

本地环境你是直接在终端或配置文件中设置环境变量，不会引入额外换行，所以客户端和本地环境的密钥都无\n，和AKS环境的变量值校验不通过。

3. 为何仅AKS环境出现该问题，本地运行正常？ #

本地与AKS环境的核心差异导致：

• 请求链路不同：本地请求直接打到Node.js服务，没有经过AKS的Ingress代理，不存在请求头过滤问题，api_key能正常被服务获取；
• 环境变量来源不同：本地的API_KEY是纯字符串直接设置，无额外换行符；而AKS的API_KEY来自K8s Secret，创建时引入了换行符，导致校验失败。

本地没有AKS特有的代理环节和Secret创建的细节问题，所以所有功能正常。

内容的提问来源于stack exchange，提问作者Vincenzo