AWS Varnish调用内部Varnish返回404问题排查求助

排查方向整理 #

1. 修正转发时的Host头 #

健康探针访问内部服务时，会自动使用后端配置的.host值（inhouse.myhost.com）作为请求的Host头，因此能正常返回200。但实际用户请求AWS Varnish时，请求的Host头是aws.myhost.com，这个值会被直接转发到内部服务。如果内部服务/内部Varnish是基于Host头做路由或权限校验的，就会返回404。

修改marker_rules子例程，强制设置转发到后端的Host头：

sub marker_rules {
  set req.backend_hint = marker_service.backend(client.identity);
  # 替换Host头为内部服务认可的域名
  set req.http.Host = "inhouse.myhost.com";
  return (pass);
}

2. 验证内部服务的Host头兼容性 #

在AWS Varnish服务器上执行以下命令，模拟带错误Host头的请求，确认是否返回404：

curl -v http://inhouse.myhost.com/marker/actuator/health -H "Host: aws.myhost.com"

如果返回404，说明内部服务或内部Varnish拒绝了aws.myhost.com这个Host头的请求，此时要么在AWS Varnish转发时替换Host头，要么在内部服务添加该Host头的白名单。

3. 查看AWS Varnish的转发日志详情 #

用varnishlog工具查看实际转发到后端的请求细节，确认Host头、URL、后端返回状态：

varnishlog -g request -q "ReqUrl ~ ^/marker/actuator/health"

重点关注以下字段：

• ReqHeader: Host：转发到后端的Host头是否正确
• BackendOpen：是否成功连接到inhouse.myhost.com:80
• RespStatus：后端返回的状态码（是404还是其他）
• RespReason：后端返回的状态描述

4. 排查VCL中的其他干扰规则 #

检查vcl_recv中的其他逻辑，确认是否存在对aws.myhost.com或/marker/*路径的额外处理：

• 是否有URL重写规则（比如set req.url = ...）导致路径被修改
• 是否有其他条件分支提前返回了响应（比如return (synth(404))）
• 是否有缓存规则影响了请求转发（虽然这里用了return(pass)，但仍需确认）

5. 核对内部Varnish的请求日志 #

查看内部Varnish的日志，确认是否收到了AWS Varnish转发的请求：

• 如果日志中没有该请求，说明AWS Varnish到内部Varnish的网络存在隐性拦截（比如安全组、防火墙规则），但探针能通，这个可能性较低
• 如果日志中有该请求，对比探针请求的Host头和URL差异，定位内部Varnish的路由规则问题

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