反向代理可能用内部HTTP连接源站，但客户实际访问HTTPS。应用若不知道外部协议，可能生成错误链接或重定向；修复应建立可信代理头的处理边界，并核对规范域名，不能无条件相信客户端自填的转发信息。
画出外部和内部两段连接
记录浏览器访问的域名协议、代理到源站的Host和连接方式，确认TLS在哪一层终止。外部HTTPS并不要求每一段都采用相同配置，但应用必须正确识别面向客户的地址。先排除站点URL设置本身错误，不把所有链接异常归为代理头。
核对代理实际发送的字段
Host、X-Forwarded-Proto及其他字段的默认行为和可配置方式不同，读取有效代理配置与源站收到的内容。多层代理可能追加、重写或保留旧值，应明确由哪一层提供权威信息。临时诊断应遮盖Cookie和认证数据，不公开回显全部请求头。
只信任经过控制的来源
如果源站可被互联网直连，无条件把任意X-Forwarded-Proto当作真实协议可能被伪造。应按架构限制可信代理来源并采用经核实的处理方式。站点规范域名也要明确，防止从不可信Host生成重置链接或外部跳转。
验证链接和重定向方向
从正式域名检查页面资源、登录、表单、下载和规范地址，确认没有混合内容或循环跳转。对HTTP入口、www及无效主机名按设计测试，核对源站与代理日志一致。修复后记录依赖，迁移或更换代理时重新验证，而不是把补丁当作所有主机通用配置。
关键区别
外部协议：客户真正使用的入口；可能与内部连接不同。
转发头：传递入口信息；必须来自可信代理。
规范域名：网站公开身份；不能任意取客户端Host。
怎样确认处理到位
正式入口生成正确HTTPS与规范域名链接，无循环和混合资源，直接与代理请求的信任边界经过核对，敏感请求头未公开泄露。
容易误判的边界
不宜无条件信任所有转发头；WordPress地址设置、代理规则与源站可达范围需要一起判断。
