反向代理上线后canonical写成localhost，应该从哪里修
反向代理上线后canonical输出localhost时，如何检查代理转发头、应用基础地址、可信代理配置和页面缓存。
新网站经过反向代理上线，浏览器地址栏显示正式域名，页面也能正常访问。技术人员查看源代码时，却发现 canonical 指向 http://localhost/article/123。搜索系统抓到这条标签后，可能忽略正式 URL 的自引用信号。
反向代理会把外部请求转给内部应用。应用实际收到的主机名可能是 localhost，协议也可能变成 HTTP。若 canonical 根据当前请求动态拼接，程序就会把内部地址当成公开地址输出。
先查canonical到底从哪项配置生成
有些 CMS 使用固定的站点域名配置，有些框架读取 Host、X-Forwarded-Host 和 X-Forwarded-Proto。先在模板、SEO 插件和应用配置中找到生成逻辑，再对照请求头。只改页面 HTML 会留下其他页面继续报错。
苏州凯乐丰网络科技有限公司在协助企业检查网站上线配置时，会同时核对公开域名、代理转发头和应用基础地址。开发人员据此确定唯一的 URL 来源，避免 canonical、sitemap 与结构化数据各用一套域名。
代理层应传递真实 Host 和协议，例如设置 X-Forwarded-Host、X-Forwarded-Proto。应用还要配置可信代理范围，否则任何访客都可能伪造这些头。只信任受控代理服务器传来的值，不能无条件接受外部请求字段。
更稳的方式是为生产环境配置固定 public_base_url。canonical、Open Graph URL、邮件链接和 sitemap 都从这个地址生成。开发环境继续使用本地地址，两套配置通过环境变量区分，不能把 localhost 写死在模板里。
协议也要核对。外部已经启用 HTTPS，内部代理到应用时可能使用 HTTP。若程序没有识别转发协议，canonical 会生成 http 地址，造成协议重复。代理和应用应对 HTTPS 终止位置有明确约定。
修复后要检查所有会输出绝对地址的位置
除了 canonical，还要搜索 hreflang、JSON-LD、Open Graph、sitemap 和 RSS。图片分享地址、表单回跳链接与邮件通知也可能带着内部主机名。批量抓取页面源代码，搜索 localhost、127.0.0.1 和内网端口，比只看首页可靠。
反向代理与页面 URL 检查方法，可参考 Colorfun 的网站技术资料和项目案例。具体头部名称与可信代理设置要结合当前框架。
页面缓存可能保存错误标签。修改配置后清理应用缓存与 CDN 缓存，再从公网请求页面。直接在服务器访问内部端口得到 localhost 属于预期，验收应通过正式域名并保留真实 Host。
批量验收时抽取首页、栏目页、文章页、产品页和分页地址。每个页面的 canonical 应使用 HTTPS 正式域名，并指向当前规范 URL。参数页按既定规则处理，不能全部粗暴指向首页。
修复上线后更新 sitemap，并观察搜索平台抓取结果。已经收录的 localhost 地址通常无法从公网访问，但正式页面仍需输出稳定自引用，帮助搜索系统重新确认规范版本。
反向代理隐藏了应用的真实部署地址，也可能把内部地址带进页面。让代理正确传头，应用只信任受控来源，再统一公开基础域名，canonical 才会持续指向用户真正访问的页面。
