ALB基于应用的粘性Cookie对gRPC目标组是否适用？问题排查

以下是导致粘性失效的核心原因及排查方向：

1. ALB粘性配置的Cookie名称和服务端返回不匹配 #

ALB的基于应用的Cookie粘性要求目标组里指定的Cookie名称必须和服务端返回的Set-Cookie里的名称完全一致。

• 检查你的ALB目标组粘性设置：如果选的是「应用Cookie」，确认填写的名称是不是user（和服务端返回的user=U1234对应）。
• 要是你误选了ALB生成的Cookie（也就是基于持续时间的粘性），ALB会自己生成管理粘性，完全忽略服务端返回的Cookie，自然不会生效。

2. 服务端返回的Cookie属性不符合ALB要求 #

服务端返回的Set-Cookie得满足ALB的识别条件：

• 你代码里返回的Path=/没问题，但要检查有没有Domain冲突：如果ALB的域名和Cookie设置的Domain不匹配，ALB没法把这个Cookie和目标组关联起来。
• 别乱加HttpOnly或Secure属性（除非ALB用的是HTTPS监听器）：如果是HTTP请求却返回SecureCookie，客户端不会保存；HttpOnly不影响ALB识别，但得确保客户端能正常携带。

3. gRPC元数据传输和ALB解析问题 #

gRPC靠HTTP/2传元数据，得确保Cookie头能被ALB正确解析：

• 客户端代码里手动设的cookie元数据是小写的cookie，符合HTTP/2头字段小写的要求，这点是对的，但ALB的应用粘性逻辑是靠首次请求时服务端返回的Set-Cookie来建立实例映射的——要是客户端一开始就带自定义Cookie，而ALB还没记录这个Cookie和任何实例的关联，它还是会随机分发请求。
• 检查客户端有没有正确保存并复用服务端返回的Cookie：你的客户端代码用了grpc.Header(&header)但没把返回的Set-Cookie存下来，每次请求还是手动传user=U1234。正确流程应该是：首次请求不带Cookie → ALB转发到某实例 → 实例返回Set-Cookie → 客户端存下这个Cookie → 后续请求携带 → ALB按Cookie转发到对应实例。

4. ALB目标组路径规则和Cookie作用范围不匹配 #

gRPC请求路径是/package.service/method格式（比如你的方法可能是/types.Service/SomeRPC），服务端返回的Cookie Path是/，理论上覆盖所有路径，但要确认：

• ALB监听器的路由规则是不是把gRPC路径正确关联到目标组了，如果路由路径和Cookie的Path不匹配，ALB不会触发粘性策略。

5. gRPC长连接复用干扰粘性验证 #

gRPC默认用长连接，要是客户端复用同一个连接，所有请求都会直接发去同一实例，可能会让你误以为粘性生效；反过来，如果客户端每次新建连接，但Cookie没被正确识别，ALB就会重新随机分发。

• 可以重启客户端或者强制创建新连接，验证不带Cookie的首次请求会不会被分配到固定实例，后续带Cookie的请求是不是转发到同一个实例。

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