企业官网建设流程全解析

天津网站建设哪家设计好,教做甜品的网站,有哪些网站建设的方法,白山商城网站建设我遇到了一个k8s的ingress透传https流量的问题#xff0c;问题详情如下#xff1a; 我的k8s集群背景信息: 1. 集群中的ingress controller的nodeport为30080#xff08;http#xff09;和30443#xff08;https#xff09;。 2. 集群中的ingress controller开启了问题详情如下我的k8s集群背景信息:1. 集群中的ingress controller的nodeport为30080http和30443https。2. 集群中的ingress controller开启了--enable-ssl-passthrough即ssl流量透传。3. 172.16.80.16是集群的1个worker节点。然后我做了以下操作1. 部署了一个nginx的deployment并开启nginx的https功能并在default server_name部署了自签发证书。2. 部署了一个nginx-service类型为ClusterIp用于将https流量转发给nginx pod。3. 部署了一个ingress用于将集群外流量转发给nginx域名为nginx.k8s.local并且在当前主机上已经将nginx.k8s.local到172.16.80.16的映射写入/etc/hosts。ingress.yaml内容如下 apiVersion: networking.k8s.io/v1 kind: Ingress metadata: name: nginx-https-ingress annotations: nginx.ingress.kubernetes.io/ssl-passthrough: true # nginx.ingress.kubernetes.io/backend-protocol: HTTPS spec: ingressClassName: nginx rules: - host: nginx.k8s.local http: paths: - path: / pathType: Prefix backend: service: name: nginx-https-service port: number: 443我发现有以下现象 如果我将ingress.yaml中的”nginx.ingress.kubernetes.io/backend-protocol: HTTPS这条配置注释掉然后发布上述资源我发现用不同的请求方式结果不同具体如下1. 使用curl -k -H Host: nginx.k8s.local https://nginx.k8s.local:30443访问可以得到正确的响应结果。2. 使用curl -k -H Host: nginx.k8s.local https://172.16.80.16:30443访问响应结果为nginx的400错误页面页面提示“The plain HTTP request was sent to HTTPS port”3. 使用curl -k https://172.16.80.16:30443访问响应结果为nginx的404页面。这是为什么你遇到的 K8s Ingress HTTPS 透传问题核心是SSL PassthroughSSL 透传的工作机制、Nginx Pod 的 HTTPS 服务配置逻辑以及curl 请求中 Host 头、域名解析的作用三者共同作用的结果下面逐一拆解每个现象的原因一、先明确核心前提你的 Ingress Controller 已开启--enable-ssl-passthrough且 Ingress 配置了nginx.ingress.kubernetes.io/ssl-passthrough: true这意味着Ingress Controller 不会解密 HTTPS 流量仅做 “纯 TCP 层的流量转发”不解析 HTTP 协议、不修改请求内容包括 Host 头流量会直接透传给后端 Nginx Service:443。后端 Nginx Pod 已配置 HTTPS 服务且绑定了server_name nginx.k8s.localdefault server 为兜底配置仅对匹配该域名的 HTTPS 请求返回正确响应。nginx.k8s.local已映射到 172.16.80.16worker 节点 IPIngress Controller 的 HTTPS NodePort 为 30443所有请求最终都会访问该节点的 30443 端口。二、逐个现象拆解原因现象 1curl -k -H Host: nginx.k8s.local https://nginx.k8s.local:30443访问成功域名解析层面curl访问nginx.k8s.local时通过/etc/hosts映射到172.16.80.16最终访问的是 Ingress Controller 的 NodePort30443。SSL 透传层面Ingress Controller 收到该 HTTPS 连接后因开启 SSL Passthrough直接将 TCP 连接透传给后端nginx-https-service:443无需解密 HTTP 内容。后端 Nginx 层面后端 Nginx Pod 收到的 HTTPS 请求中携带了Host: nginx.k8s.local头与 Nginx 配置的server_name完全匹配因此返回正确的响应结果。注释backend-protocol: HTTPS不影响此场景因为 SSL Passthrough 是 TCP 层转发无需 Ingress Controller 感知后端协议类型该注解仅用于非透传场景告知 Ingress Controller 后端是 HTTPS 服务。现象 2curl -k -H Host: nginx.k8s.local https://172.16.80.16:30443返回 400 错误The plain HTTP request was sent to HTTPS port这个错误的核心是Ingress Controller 的 SSL Passthrough 转发规则未触发导致请求被 Ingress Controller 自身的 Nginx而非透传给后端 Pod处理进而返回异常。SSL Passthrough 的触发条件Nginx Ingress Controller 的 SSL Passthrough 功能仅对 “请求域名与 Ingress 配置的host完全匹配” 的 HTTPS 连接才会触发透传。当你直接访问https://172.16.80.16:30443时curl在建立 SSL/TLS 连接时会发送SNIServer Name Indication扩展字段而 SNI 字段中携带的是IP 地址 172.16.80.16而非 Ingress 配置的nginx.k8s.local。Ingress Controller 收到 SNI 为 IP 地址的 HTTPS 连接后无法匹配到对应 Ingress 的host你的 Ingress host 是nginx.k8s.local因此不会触发 SSL Passthrough 透传。请求被 Ingress Controller 自身处理未触发透传时Ingress Controller 会尝试自己解密 HTTPS 流量使用自身默认证书或未匹配到有效证书然后按普通 Ingress 规则处理。此时 Ingress Controller 自身的 Nginx会将该请求当作 “普通 HTTP 请求”实际是解密失败或协议不匹配转发到后端而后端是 HTTPS 端口443无法处理明文 HTTP 请求最终返回The plain HTTP request was sent to HTTPS port错误本质是协议不匹配前端发明文 HTTP后端收 HTTPS 端口。补充-H Host: nginx.k8s.local仅在 HTTP 层生效无法修改 SSL/TLS 握手阶段的 SNI 字段SNI 是 TCP/TLS 层的字段早于 HTTP 层因此无法触发 SSL Passthrough。现象 3curl -k https://172.16.80.16:30443返回 404 页面该现象是现象 2 的延伸未触发 SSL Passthrough且缺少 Host 头匹配导致 Ingress Controller 自身兜底处理返回 404同样因 SNI 携带的是 IP 地址172.16.80.16无法触发 SSL Passthrough请求被 Ingress Controller 自身处理。该curl命令未携带Host头Ingress Controller 自身的 Nginx 无法匹配到任何 Ingress 规则你的 Ingress 规则要求Host: nginx.k8s.local。最终请求被 Ingress Controller 自身的default server默认兜底服务处理而默认 server 没有对应的路由配置因此返回 404 Not Found 错误。三、关键总结SSL Passthrough 是TCP 层透传依赖SSL/TLS 握手阶段的 SNI 字段携带 Ingress 配置的host域名触发与 HTTP 层的 Host 头无关。直接访问节点 IP172.16.80.16时SNI 携带 IP 而非配置域名导致透传失效请求被 Ingress Controller 自身处理。backend-protocol: HTTPS注解仅用于非透传场景Ingress Controller 解密 HTTPS 后以 HTTPS 协议转发给后端透传场景下无需配置不影响结果。400 错误是 “明文 HTTP 请求发往 HTTPS 端口” 的协议不匹配404 错误是无对应 Ingress 路由规则的兜底响应二者均由 Ingress Controller 自身处理请求导致而非后端 Nginx Pod。那这么看的话实际上第一个请求有两个部分指明了域名nginx.k8s.local: 第一个是sni提供了域名sni的域名是供ssl透传使用的并不属于请求header中的部分。在header传输之前的tls握手阶段就可以获取了。即使ingress controller采取了透传方式也可以从sni中获取域名来匹配ingress规则。 第二个是header中的Host字段这个是tls握手之后传递数据的阶段传输的如果采取了透传方式ingress controller是读不到的。 这么理解对吗你的理解完全正确而且精准抓住了 SSL 透传SSL Passthrough的核心工作流程和两个域名载体的本质区别我们再对这个理解做进一步的梳理和强化让逻辑更清晰一、你的两个核心判断均成立SNI 提供的域名用于 SSL 透传触发不属于 HTTP 请求 Header且在 TLS 握手阶段提前获取SNIServer Name Indication是TLS 协议扩展字段并非 HTTP 协议的一部分因此它不属于 HTTP Request Header 范畴。时序上TLS 握手是 HTTP 数据传输的前置步骤客户端先与服务端完成 TLS 握手协商加密套件、验证证书、生成会话密钥这个过程中会携带 SNI 字段之后才会进行 HTTP 数据包括 Host Header 等的加密传输。对 Nginx Ingress Controller 而言开启ssl-passthrough后它无需解密 HTTPS 流量保持流量加密状态但可以在 TLS 握手阶段读取到未加密的 SNI 字段SNI 本身是明文携带在 TLS 握手请求中的并通过 SNI 中的域名匹配 Ingress 配置的host规则从而触发 TCP 层的 SSL 透传转发。Header 中的 Host 字段TLS 握手后传输SSL 透传模式下 Ingress Controller 无法读取Host 是HTTP 协议的核心 Header 字段用于告知后端服务客户端要访问的域名它在 TLS 握手完成后随 HTTP 报文一起被加密传输。在 SSL 透传模式下Ingress Controller 仅做「透明的 TCP 连接转发」不会对 HTTPS 流量进行解密操作因此无法获取到加密后的 HTTP 报文内容自然也无法读取 Host Header。这个 Host Header 最终会被完整地透传给后端 Nginx Pod由后端 Nginx 根据自身的server_name配置进行匹配这也是现象 1 能返回正确响应的关键后端 Nginx 匹配到了 Host Header 中的nginx.k8s.local。二、补充一个关键关联SSL 透传的触发核心就是 SNI 匹配你已经精准洞察到 SNI 的作用这里再强化一点Nginx Ingress Controller 的ssl-passthrough功能唯一的核心触发条件就是 SNI 域名与 Ingress 配置的host完全匹配。现象 1 中curl https://nginx.k8s.local:30443时客户端会自动将 SNI 字段设为nginx.k8s.local与 Ingress 的host一致因此触发透传。现象 2、3 中访问的是 IP 地址172.16.80.16客户端的 SNI 字段会携带该 IP 而非配置域名无法匹配 Ingress 规则透传失效请求才会被 Ingress Controller 自身处理。总结你的理解完全准确核心要点回顾SNITLS 层非 HTTP Header、明文、握手阶段传输、供 Ingress Controller 匹配 Ingres 规则以触发 SSL 透传。Host HeaderHTTP 层、加密后传输、TLS 握手完成后发送、SSL 透传模式下 Ingress Controller 不可读仅后端服务可读取并用于域名匹配。SSL 透传是 TCP 层转发不解密 HTTPS 流量仅依赖 SNI 完成规则匹配与 HTTP 层的 Host Header 无关联Host Header 仅作用于后端服务。因此实际上第一个请求能成功以https透传方式转发给nginx pod是因为ingress controller直接从sni中获取到了域名这样就匹配到了已发布的ingress并按照ingress中规定的透传规则来进行传输。如果去掉第一种请求方式中的-H参数ingress controller依然能够从sni中获取到域名并匹配到ingress透传规则从而正确透传https流量给后端的nginx pod。对吗你的判断完全正确这是个非常关键的核心结论我们拆解验证一下让逻辑更扎实1. 核心结论去掉 - H 参数请求依然会成功透传我们先验证这个结论执行curl -k https://nginx.k8s.local:30443会成功原因如下触发透传的核心是 SNI和 HTTP 的 Host 头无关当你用https://nginx.k8s.local:30443访问时curl 会自动把 SNI 设为 nginx.k8s.localIngress Controller 读取 SNI 后匹配到对应的 Ingress 规则直接触发 SSL 透传把加密的 TCP 连接转发给后端 nginx-service:443。后端 Nginx 的匹配逻辑兜底保障了成功响应你的后端 Nginx 配置了default server_name 这是关键带-H Host加密的 HTTP 请求里带了 Host 头后端 Nginx 精准匹配server_name nginx.k8s.local返回对应响应。不带-H Host加密的 HTTP 请求里没有 Host 头后端 Nginx 会匹配default_server同样返回正确响应因为你证书部署在 default 上。2. 两个关键补充帮你彻底理清边界补充 1 SNI 与 Host 头的独立性透传场景下这是你理解的关键点再强化一次字段作用对象透传场景下作用是否必须SNIIngress Controller匹配 Ingress 规则触发 SSL 透传必须Host Header后端 Pod (nginx)匹配后端 server_name非必须有 default 就兜底透传的唯一触发条件是 SNI 匹配 Ingress 的 host和 Host 头毫无关系Host 头只影响后端服务的路由不影响 Ingress Controller 的透传决策补充 2 反过来验证SNI 不匹配加再多 Host 头也没用对应你之前的现象 2curl -k -H Host: nginx.k8s.local https://172.16.80.16:30443失败根源就是访问 IPcurl 的 SNI 是 172.16.80.16无法匹配 Ingress 的 host (nginx.k8s.local)透传不触发Ingress Controller 自己处理请求此时即便加了 Host 头后续转发协议不匹配必然 400 错误3. 最终提炼一句话记牢SSL 透传场景下Ingress 看 SNI决定是否透传后端看 Host决定如何响应SNI 是透传的命脉Host 是后端的配置二者互不干扰。接下来我们可以实操一步验证这个结论要不要现在就执行curl -k https://nginx.k8s.local:30443命令看看是否能成功返回响应对于第二种请求方式ingress controller会先尝试根据sni来匹配透传规则但由于sni只能获取到ip无法匹配到任何ingress中的透传规则。接下来ingress controller会终结https流量进而从请求头中获取到了Host然后根据Host就匹配到了ingress转发规则之后就通过http请求转发给nginx pod。这就造成了后端nginx pod虽然收到了流量却是http流量从而返回400错误页面。对吗你的理解完全正确精准说透了第二种请求失败的完整链路我们把这个流程拆成一步步再补 2 个关键细节让你彻底吃透这个场景✅ 第二种请求完整失败链路和你的描述完全一致请求命令curl -k -H Host: nginx.k8s.local https://172.16.80.16:30443第一步TLS 握手阶段SNI 携带 IP透传规则匹配失败curl 访问的是 IPSNI 字段自动填充为 172.16.80.16而非 Ingress 配置的nginx.k8s.localIngress Controller 读取 SNI 后找不到对应host的透传 Ingress 规则SSL 透传不触发第二步Ingress Controller 终结解密HTTPS 流量透传失效后Ingress Controller 会按普通 HTTPS Ingress 逻辑处理自己终结 HTTPS 连接用自身默认证书或临时证书-k跳过证书校验所以能建立连接第三步解密后读取 Host 头匹配普通 Ingress 转发规则解密后拿到 HTTP 请求里的Host: nginx.k8s.local成功匹配到你 Ingress 里的host规则第四步默认用 HTTP 协议转发给后端协议不匹配触发 400你注释了backend-protocol: HTTPSIngress Controller 默认用明文 HTTP协议转发到后端 nginx-service:443后端 nginx Pod 的 443 端口监听的是 HTTPS只接收加密流量收到明文 HTTP 请求直接返回The plain HTTP request was sent to HTTPS port400 错误✨ 补充 2 个关键细节帮你区分边界避免踩坑细节 1 透传失效后Ingress Controller 的转发协议由backend-protocol决定这是你这个场景的核心关键也是 400 错误的直接诱因你注释了backend-protocol: HTTPS→ 控制器默认用HTTP转发若没注释该注解 → 控制器会用HTTPS转发给后端 443此时请求就能成功但这就不是透传了是控制器解密再加密转发细节 2 「终结 HTTPS」和「透传」是互斥的二选一Ingress Controller 处理 HTTPS 请求只有 2 种模式不会同时触发透传模式优先触发SNI 匹配透传 Ingress → 不解密、TCP 层转发 → 后端自己处理 HTTPS终结模式兜底模式SNI 不匹配透传规则 → 控制器解密 → 按 HTTP 规则转发 → 转发协议由backend-protocol决定 一句话总结第二种请求失败根源SNI 不匹配导致透传失效 → 控制器解密 HTTPS → Host 头匹配普通规则 → 未配置backend-protocol默认 HTTP 转发 → 后端 HTTPS 端口拒收明文 HTTP → 400 错误也就是说第二种请求方式中客户端收到的ssl证书其实是ingress controller的证书对吗但是我只给后端的nginx pod配置了自签名证书并没有显式的在ingress controller中配置书它是如何和客户端建立tls连接的呢难道说ingress controller会自动签发一个证书作为默认证书吗你的判断完全正确我们一步步把这个证书问题讲透这也是 Ingress 处理 HTTPS 的核心知识点1. 结论先行第二种请求客户端收到的就是 Ingress Controller 的证书而非后端 Nginx 的证书因为透传没触发Ingress Controller 自己终结了 HTTPS 连接所以客户端是和 Ingress Controller 完成 TLS 握手自然拿到的是它的证书和后端 Nginx 证书完全没关系2. 关键问题你没给 Ingress Controller 配证书它怎么建立 TLS 连接答案Nginx Ingress Controller 会自动生成并使用一个自签名的默认证书这个是默认行为不用你手动配置这个默认证书的来龙去脉生成时机Ingress Controller Pod 启动时会自动生成一套自签名证书证书路径默认存放在 Pod 内/etc/nginx/ssl/default-fake-certificate.{crt,key}生成逻辑由 Controller 内置脚本自动生成CN通用名一般是localhost无实际业务意义触发条件当 Ingress Controller 需要终结 HTTPS但找不到对应 Host 的有效证书时就会用这个默认证书兜底你的场景刚好命中透传失效 → 必须终结 HTTPS你没给 Ingress 配置tls字段没有绑定任何证书 → 无对应 Host 证书直接兜底用默认自签名证书和客户端握手3. 补充验证如何确认你拿到的是 Ingress 的默认证书给你 2 个实操命令一眼就能验证对应你的第二种请求验证 1查看证书归属区分 Ingress 默认证书 vs 后端 Nginx 证书命令 1访问 IP第二种请求查看证书信息curl -k -v https://172.16.80.16:30443 21 | grep subject:命令 2直接访问后端 Nginx先端口转发查看后端证书kubectl port-forward svc/nginx-https-service 8443:443curl -k -v https://localhost:8443 21 | grep subject:✅ 结果对比两个命令输出的subject:证书主体完全不一样证明证书来源不同命令 1是 Ingress 默认证书subject 一般是/CNlocalhost命令 2是你给后端 Nginx 配的自签名证书subject 是你配置的内容验证 2为啥 curl 加-k就能访问因为这个默认证书是自签名的不被客户端信任-k的作用就是跳过证书校验否则 curl 会直接报错证书不信任连握手都完成不了4. 延伸知识点Ingress Controller 证书的优先级避免踩坑Ingress Controller 终结 HTTPS 时证书匹配有优先级默认证书是最后兜底的优先级从高到低绑定 Ingress 的专属证书给 Ingress 的spec.tls字段配置 secret对应具体 host→ 优先匹配Ingress Controller 全局证书通过--default-ssl-certificate参数指定集群内一个 secret → 全局兜底Controller 内置默认证书就是上面说的自动生成的证书 → 最终兜底无任何配置时用你的场景就是走到了第 3 步所以用了默认证书5. 呼应之前的链路证书环节补全第二种请求完整流程curl 访问https://172.16.80.16:30443→ SNI172.16.80.16 → 透传失败Ingress Controller 启动终结模式发现无对应证书 → 拿出内置默认自签名证书客户端curl和 Ingress Controller 完成 TLS 握手-k跳过证书校验Ingress Controller 解密 HTTPS读取 Host 头匹配 Ingress 规则未配置backend-protocol→ 明文 HTTP 转发给后端 443 → 后端返回 400 错误一句话总结证书核心逻辑透传→用后端证书终结→用 Ingress 证书有配置用配置无配置用默认自签名要不要我给你写一段配置给 Ingress 绑定你后端的同一份证书看看第二种请求的证书会不会变成你配置的证书还真是我用“curl -v -k -H Host: nginx.k8s.local https://172.16.80.16:30443”指令进行请求控制台输出的是“subject: OAcme Co; CNKubernetes Ingress Controller Fake Certificate”说明这是ingress controller自签发的fake证书我用“curl -v -k -H Host: nginx.k8s.local https://nginx.k8s.local:30443”控制台输出的是我手动生产的自签名证书信息。这个验证结果完美印证了我们之前的所有推论太关键了这两个curl -v的输出差异就是SSL 透传模式和Ingress 终结 HTTPS 模式最直观的区别我们再把这个验证结果对应到核心逻辑帮你彻底闭环一、两个请求的证书差异对应两种完全不同的 TLS 握手对象1. 成功透传请求https://nginx.k8s.local:30443→ 拿到后端 Nginx 证书✅ 完整链路TLS 握手 转发curl 访问域名SNInginx.k8s.local匹配 Ingress 透传规则触发 SSL 透传Ingress Controller 不终结 HTTPS仅做 TCP 转发相当于 “中间人透明转发”客户端的 TLS 握手直接穿透 Ingress和后端 Nginx Pod建立连接因此你拿到的是后端 Nginx 的手动自签名证书和 Ingress Controller 无关2. 透传失败请求https://172.16.80.16:30443→ 拿到 Ingress Fake 证书✅ 完整链路TLS 握手 转发curl 访问 IPSNI172.16.80.16无法匹配透传规则透传失效Ingress Controller 触发终结 HTTPS 模式必须和客户端完成 TLS 握手你没给 Ingress 配证书Controller 兜底用内置 Fake 证书CNKubernetes Ingress Controller Fake Certificate客户端和 Ingress Controller 完成握手自然拿到的是这个 Fake 证书和后端 Nginx 无关二、这个验证结果的 3 个核心价值帮你吃透本质最直观区分「透传」和「终结」看证书归属就够了拿到后端证书 透传成功TLS 握手在客户端↔后端拿到 Ingress Fake 证书 透传失败TLS 握手在客户端↔Ingress验证了 SNI 的核心作用SNI 匹配域名才触发透传匹配 IP 则必然终结哪怕 Host 头一致SNI 不对握手对象就变了后续全错坐实了-k的作用不管是后端自签证书还是 Ingress Fake 证书都是不被信任的-k是跳过校验的关键少了它连握手都失败三、补充 2 个易错点避免后续踩坑误区透传模式下Ingress 不需要证书也不用配置 Ingress 的tls字段✅ 正确透传时 Ingress 不解密证书只需要后端配Ingress 侧无需任何证书配置误区只要配置了ssl-passthrough: true就一定透传✅ 正确透传的前提是SNI 域名和 Ingress 的 host 完全匹配缺一不可SNI 是前提中的前提四、最终闭环你的整个场景逻辑链从证书到转发全打通透传成功场景域名访问SNI 匹配→透传触发→客户端↔后端握手后端证书→加密流量透传→后端匹配 Host或 default→响应成功透传失败场景IP 访问SNIIP 不匹配→透传失效→Ingress 终结 HTTPSFake 证书→解密读 Host 匹配规则→默认 HTTP 转发→后端 HTTPS 端口拒收明文→400 错误到这里你这个 Ingress HTTPS 透传的问题就彻底吃透了从触发条件到证书流程再到转发逻辑都闭环了。当使用第三种请求方式时由于既无法从sni中获取域名因此不会匹配ingress中的透传规则也没有从header获取到Host因此不会通过Host匹配到ingress转发规则因此ingress controller直接使用默认的404页面作为响应内容返回了。对吗你的理解完全正确我们把第三种请求的完整链路拆透彻底闭环这个场景✅ 核心结论第三种请求curl -k https://172.16.80.16:30443返回 404 的根本原因就是透传规则和普通转发规则都没匹配上最终被 Ingress Controller 的默认兜底规则处理返回 404一步步拆解第三种请求完整链路请求命令curl -k https://172.16.80.16:30443第一步TLS 握手阶段SNIIP透传规则匹配失败和第二种请求一致curl 访问 IPSNI 自动填充172.16.80.16和 Ingress 配置的host: nginx.k8s.local完全不匹配透传不触发Ingress Controller 进入终结 HTTPS 模式用内置 Fake 证书完成握手所以-k能成功建立连接第二步解密后读取 HTTP 请求无 Host 头普通 Ingress 转发规则匹配失败这个请求没带任何 Host 头HTTP 请求头里的 Host 字段默认是172.16.80.16:30443你的 Ingress 规则只匹配Host: nginx.k8s.local自然匹配不到任何已配置的 Ingress 转发规则第三步无任何匹配规则触发 Ingress Controller 默认兜底返回 404Ingress Controller 自身的 Nginx 配置里会有一个默认 server兜底服务专门处理「无匹配规则」的请求这个默认 server 没有配置任何路由转发规则也没有绑定后端服务因此直接返回404 Not Found补充 3 个关键细节帮你区分二、三种请求的差异你已经分清了核心逻辑再明确 3 个边界避免混淆细节 1 第二种请求 vs 第三种请求为啥一个 400 一个 404两者第一步透传失败 终结 HTTPS完全一致差异在第二步的规则匹配第二种请求带了Host: nginx.k8s.local→ 匹配到 Ingress 转发规则 → 转发给后端协议不匹配 400第三种请求没带 Host 头 → 匹配不到任何 Ingress 转发规则 → 走默认兜底无路由 404✅ 一句话区分匹配到规则转发错了是 400没匹配到规则直接兜底是 404细节 2 第三种请求的 Host 默认值为啥匹配不上curl 没手动指定 Host 时会自动填充「访问地址」作为 Host 头你的请求地址是https://172.16.80.16:30443→ 默认 Host 头是172.16.80.16:30443你的 Ingress 只认nginx.k8s.local自然匹配不上本质还是「无有效 Host 匹配」细节 3 兜底 404 是 Ingress Controller 返回的不是后端 Nginx这个很关键和透传场景区分开透传成功响应来自后端 Nginx Pod第三种请求根本没转发到后端响应来自Ingress Controller 自身和后端 Pod 毫无关系延伸验证如何让第三种请求不返回 404给 2 个实操思路印证我们的逻辑你可以按需测试思路 1 手动带正确 Host 头 → 匹配规则变成第二种请求返回 400命令curl -k -H Host: nginx.k8s.local https://172.16.80.16:30443→ 400而非 404思路 2 给 Ingress 加 IP 匹配的 Host → 匹配规则给你的 Ingress 加一行host: 172.16.80.16重新部署后再请求会匹配规则转发同样返回 400最终总结三种请求的核心差异一张表理清请求方式SNI 内容透传是否触发是否带正确 Host匹配规则响应来源结果1. 域名 Hostnginx.k8s.local✅ 是✅ 是透传规则后端 Nginx成功2.IPHost172.16.80.16❌ 否✅ 是普通转发规则后端 Nginx4003. 纯 IP172.16.80.16❌ 否❌ 否无匹配规则Ingress Controller404到这里你这三个请求的所有疑问就全部闭环了从 SNI、Host 头到证书、转发规则的逻辑都串通了。所以当我开启了nginx.ingress.kubernetes.io/backend-protocol: HTTPS这条配置后这三种请求方式的结果如下对于第一种请求由于可以从sni获取到域名ingress controller会采取透传方式因此能够正确将https流量转发给nginx pod客户端可以得到正确的响应结果。对于第二种请求由于无法从sni获取到域名因此ingress controller无法匹配到ingress透传规则仍然会按照之前的方式终结https流量但是由于开启了nginx.ingress.kubernetes.io/backend-protocol: HTTPS这条配置ingress controller在根据host匹配到转发规则后会按照这条配置使用https请求转发给nginx pod从而客户端能够获得正确的响应结果。对于第三种请求由于ingress controller无法从sni和host中获取到域名不会匹配任何ingress规则从而使用默认的404页面作为响应内容返回。因此开启nginx.ingress.kubernetes.io/backend-protocol: HTTPS配置后第一、三中请求结果不变但是第二种能够获得正确的响应。对吗你的分析完全正确精准抓住了backend-protocol: HTTPS的核心作用边界 —— 仅影响非透传场景的转发协议对透传场景和无规则兜底场景完全无影响我们逐一验证并补全细节彻底坐实结论✅ 开启backend-protocol: HTTPS后3 种请求结果预判完全准确1. 第一种请求结果不变依然成功透传不受该注解影响核心逻辑SNInginx.k8s.local匹配透传规则透传模式优先触发backend-protocol是非透传场景的配置Ingress 需要解密后转发时才生效透传时 Ingress 只做 TCP 转发不关心后端协议因此该注解形同虚设流量还是加密透传给后端 Nginx客户端拿后端证书响应成功✅ 关键结论SSL 透传模式下backend-protocol不生效有没有该配置都不影响结果2. 第二种请求结果改变从 400→成功该注解的核心作用场景这是该注解的核心价值完整链路修正SNI172.16.80.16透传失败Ingress 终结 HTTPS用 Fake 证书握手解密后读取Host: nginx.k8s.local匹配普通转发规则开启backend-protocol: HTTPSIngress 不再用默认 HTTP 转发而是用 HTTPS 协议加密转发给后端 nginx-service:443后端 Nginx 443 端口接收 HTTPS 流量协议匹配且 Host 头正确返回正确响应✅ 关键修正之前 400 是「HTTP 明文→HTTPS 端口」协议不匹配现在是「HTTPS 加密→HTTPS 端口」协议匹配问题根治3. 第三种请求结果不变依然 404无规则可匹配注解无机会生效核心逻辑透传失败SNIIP→ 终结 HTTPS无 Host 头匹配不到任何 Ingress 转发规则直接走 Ingress 默认兜底 server兜底逻辑是 Ingress 自身返回 404根本不会触发「转发后端」的动作因此backend-protocol连生效的机会都没有✅ 关键结论只有匹配到 Ingress 转发规则时backend-protocol才生效无规则匹配时和它无关✨ 补充 2 个关键细节避免后续踩坑细节 1backend-protocol: HTTPS的生效前提3 个缺一不可透传未触发透传优先生效优先级低于ssl-passthrough: true成功匹配到 Ingress 的hostpath转发规则后端 Service 端口是 HTTPS 监听如 443你的第二种请求刚好满足这 3 个条件因此注解生效1、3 种请求不满足因此无影响细节 2第二种请求成功后证书还是 Ingress 的 Fake 证书即使第二种请求响应成功你用curl -v看证书依然是CNKubernetes Ingress Controller Fake Certificate原因该场景是Ingress 终结 HTTPSHTTPS 转发客户端只和 Ingress 做 TLS 握手和后端证书无关相当于 Ingress 做了 “中间人加密转发” 最终结论一张表闭环所有场景请求方式透传是否触发backend-protocol是否生效转发协议结果开启注解后证书来源1. 域名 Host✅ 是❌ 不生效TCP 透传HTTPS 加密成功不变后端 Nginx2.IPHost❌ 否✅ 生效HTTPS 加密转发成功从 400→成功Ingress Fake3. 纯 IP❌ 否❌ 不生效无转发兜底404不变Ingress Fake额外延伸帮你拓展场景如果想让第二种请求也拿到后端 Nginx 的证书该怎么做→ 只能让透传触发即访问时保证SNInginx.k8s.local比如给curl手动指定 SNIcurl -k -H Host: nginx.k8s.local https://172.16.80.16:30443 --resolve nginx.k8s.local:30443:172.16.80.16这个命令会强制 SNInginx.k8s.local触发透传证书就变成后端的了