先给结论:当同一批 URL 在部分入口正常、部分入口 404,而服务器上文件确实存在时,优先怀疑域名或子目录映射层对路径大小写做了不同处理,而不是先改文件。选择域名的阶段就要决定是否把大小写一致性写进映射规则,否则上线后只能靠重定向补洞。判断方法是:把同一路径分别用全小写、原大小写、混合大小写请求三次,比较状态码和最终落点;如果只有全小写稳定返回 200,说明映射层在规范化大小写,需要在域名配置里统一声明,而不是逐个文件改名。
典型表现是:站内链接写的是 /Images/Banner.jpg,浏览器能打开;外部引用或站点地图里写成 /images/banner.jpg,却返回 404。反过来也可能成立。文件系统本身不区分大小写时,两种写法都能命中;一旦迁移到区分大小写的环境,或经过一层会改写路径的代理,差异立刻暴露。这时“文件在不在”已经不是关键变量,关键是请求在到达文件系统之前被谁改过。
解释一:域名或子目录的映射规则把路径强制转成小写后再查找,因此只有小写形式能命中真实文件。解释二:映射层原样透传路径,大小写差异只是文件系统本身区分大小写造成的,与域名配置无关。两者都会产生 404,但修复位置完全不同:前者要改映射规则,后者要统一文件命名或加重定向。
要区分它们,不能只看一次请求结果。可以构造一组对照:同一文件准备两份,一份全小写命名,一份保留原大小写;分别通过同一域名请求四种组合——小写路径对小写文件、原大小写路径对原大小写文件、小写路径对原大小写文件、原大小写路径对小写文件。如果前两种都成功、后两种都失败,说明映射层原样透传,问题在文件系统;如果只有全小写组合成功,说明映射层在做规范化,问题在域名配置。
更直接的证据来自服务器访问日志和重定向链。假设映射层做了小写规范化,日志里记录的请求路径应当已经是小写,或者能看到一条 301 指向小写形式;如果日志里保留的是客户端发来的原始大小写,且没有重定向记录,则更支持原样透传。另一个证据是:直接在服务器本地用文件系统命令访问同一路径,如果本地也区分大小写,而通过域名访问时结果不同,说明中间层改过路径。
需要提醒的是,抓取量或请求量突然下降不能单独证明是大小写映射问题。它也可能来自 robots.txt 规则变化、站点地图失效、入口链接被删或平台推荐波动。把日志里的 404 路径按大小写模式分组,才能把范围收窄到映射层。
如果证据指向映射层规范化,动作是在域名或子目录配置里显式声明大小写策略,而不是依赖默认行为。常见做法是:在 Web 服务器或反向代理层加一条规则,把请求路径统一转为小写后再查找,同时保留原始路径用于日志。执行后重新请求四种组合,如果全部返回 200 或统一 301 到同一落点,说明映射层已经一致;如果仍有组合失败,说明还有一层未覆盖,需要继续向上游排查。
如果证据指向原样透传,动作是统一文件命名或加显式重定向。此时不要只改站内链接,因为外部引用和已收录 URL 不会同步更新。更稳的做法是保留原文件,对旧大小写路径加 301 到规范路径,并确认重定向链不超过一跳。做完后观察日志里是否还有旧路径直接返回 404;如果 404 减少但未归零,说明仍有入口在发旧路径,需要回到链接来源继续处理。
是否需要在域名层统一大小写,取决于三个条件:目标环境是否区分大小写、是否有外部系统按固定大小写引用、以及是否允许重定向链存在。三者都偏向严格时,应在域名配置阶段就固定一种写法,并把它写进部署检查项。反之,如果目标环境不区分大小写且没有外部固定引用,可以暂不处理,但要接受迁移时可能集中爆发 404 的风险。
robots.txt 的抓取限制不等于可靠的索引移除,站点地图也不保证收录,HTTPS 同样不保证安全无漏洞或排名。这些与大小写映射不是同一层的问题,不要用它们替代映射层的修复。不同搜索引擎对大小写路径的支持情况须分别核查,不能假设一家通过就全部通过。
最后给一个假设例子说明比较方法:假设某站有 100 个图片路径,其中 30 个含大写字母。迁移后只对全小写路径做请求测试,得到 70 个成功、30 个失败,这只能说明大小写相关,不能说明映射层是规范化还是透传。把 30 个失败路径分别用原大小写再请求一次,如果全部成功,则映射层原样透传;如果仍失败,则映射层做了小写规范化。两种结果对应两种修复动作,先做这一步再决定改配置还是改文件。