同版本Wget在不同环境下链接转换结果不一致问题排查

这确实是个让人头疼的问题——相同版本的Wget、完全一致的命令，结果却出现差异，大概率是环境中的隐性配置或上下文差异导致的。我整理了几个针对性的排查方向，你可以逐一验证：

1. 核对容器内Wget的实际编译/配置差异 #

虽然版本号都是1.18，但不同Docker镜像编译Wget时可能启用了不同的编译选项，或者依赖库（如libssl、libcurl）版本不同，这会直接影响链接转换的逻辑。

• 在两个环境的容器内分别执行：

  wget --version
  

  仔细对比输出中的编译选项（比如是否有--enable-xxx/--disable-xxx差异）和依赖库版本（如OpenSSL版本）。
• 检查Wget的默认配置文件：

  cat /etc/wgetrc
  # 同时检查用户目录下的自定义配置
  cat ~/.wgetrc
  

  看是否存在adjust_extension相关的配置，覆盖了命令行参数的行为。

2. 验证服务器返回的CSS文件响应头 #

Wget的-E（--adjust-extension）参数会根据HTTP响应的Content-Type字段判断是否添加扩展名。如果有问题的环境中，服务器返回的CSS文件Content-Type不是text/css，而是text/html或其他Wget认为需要追加.html的类型，就会触发这个问题。

• 在两个环境中分别用curl测试目标CSS文件的响应头：

  curl -I --header "Cookie: myCookie=123" "http://path.to/assets/ss-standard-931774a45f6c2e79b3fb8ac6ce1eca4e4a9208b3c80a1c289f36b317b830db6b.css"
  

  重点对比Content-Type字段，正常应该返回text/css。如果异常环境中返回的是其他值，问题可能出在Rails资产管道配置、EB环境的反向代理或CDN修改了响应头。

3. 检查Wget工作目录与文件系统状态 #

Wget的--convert-links会基于本地保存的文件路径转换链接，如果两个环境中Wget的工作目录不同，或文件系统权限/结构有差异，可能导致Wget误判文件类型。

• 执行Wget命令后，在容器内检查文件的实际保存路径：

  find . -name "*.css*"
  

  对比两个环境中CSS文件的路径，看是否存在路径差异导致Wget错误追加.html。
• 确认Wget执行时的工作目录一致，比如都是/app或其他固定路径（可以在执行Wget前添加pwd命令验证）。

4. 排查Elastic Beanstalk环境的隐性配置差异 #

即使都是EB测试环境，也可能存在配置差异：

• 环境变量：对比两个环境的环境变量，重点看与Rails资产、HTTP头相关的变量（如RAILS_ENV、是否有自定义CONTENT_TYPE变量）。
• 反向代理配置：如果EB使用Nginx，检查/etc/nginx/conf.d/下的配置文件，看是否有修改响应头的规则（比如将CSS的Content-Type改为text/html）。
• Rails资产配置：在容器内启动rails console，查看资产管道的配置：

  Rails.application.config.assets
  

  重点对比digest、compile等设置，确保两个环境一致。

5. 简化Wget命令，逐步定位参数影响 #

把命令简化，逐步去掉参数，观察问题是否消失，定位到触发异常的参数组合：

• 先去掉-N（--timestamping）：时间戳逻辑可能影响Wget是否重新下载文件，进而干扰链接转换；
• 去掉--restrict-file-names=windows：这个参数会修改文件名处理规则，可能与扩展名调整冲突；
• 去掉-H（--span-hosts）：跨域资产的域名解析差异可能导致Wget误判文件类型。

6. 直接在容器内手动执行Wget，排除exec命令干扰 #

有时候docker exec的参数传递可能存在转义或环境变量继承问题。可以直接进入容器：

docker exec -it xxxxxxxx sh

然后在容器内手动执行完整的Wget命令，看结果是否与之前一致。如果手动执行正常，说明是docker exec的命令参数存在问题（比如引号转义错误，导致部分参数未被正确解析）。

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