shell 脚本嵌套加速 在http服务器 脚本内容替换为了https

[crazypeace]

问题描述

shell 脚本嵌套加速 在http服务器 脚本内容替换为了https

复现步骤

1. ghproxy环境
   修改配置文件为打开 脚本嵌套加速

用这样的命令启动服务

docker run -p 7210:8080 -v ./ghproxy/log/run:/data/ghproxy/log -v ./ghproxy/log/caddy:/data/caddy/log -v ./ghproxy/config:/data/ghproxy/config --restart always wjqserver/ghproxy

2. 使用环境
   github.com 不能直接访问

用这样的方法使用 ghproxy

bash -x <( curl -L http://ghproxy环境的IP:7210/raw.githubusercontent.com/233boy/v2ray/master/install.sh )

结果
脚本内容被替换为 https://ghproxy环境的IP:7210/xxxxxxxxxx

预期行为

脚本内容应该被替换为 http://ghproxy环境的IP:7210/xxxxxxxxxx

实际行为

脚本内容被替换为 https://ghproxy环境的IP:7210/xxxxxxxxxx

截图

见描述过程

环境信息

docker run -p 7210:8080 -v ./ghproxy/log/run:/data/ghproxy/log -v ./ghproxy/log/caddy:/data/caddy/log -v ./ghproxy/config:/data/ghproxy/config --restart always wjqserver/ghproxy
Log Level: info
GHProxy Version: 4.3.4
A Go Based High-Performance Github Proxy 
Made by WJQSERVER-STUDIO
Power by Touka
2025/09/14 00:19:45 Touka HTTP server listening on http://0.0.0.0:8080

附加信息

[WJQSERVER]

@crazypeace 这是预期行为, 设计此功能之初就考虑过这个问题

[crazypeace]

我不理解.
搭建者只搭了 http 服务,
使用者明确要求使用 http 服务.

为什么替换时要替换为 https?

[WJQSERVER]

判断经过多层转手后, 无法确认原始proto, 更何况不少cdn也有http回源模式, 用户自行流转代理中间盒行为更加不明

[WJQSERVER]

proto 和 host都是通过header获取的, 如果改为配置文件定义倒是可以解决这个问题
但用户使用和迁移起来就太麻烦了

[crazypeace]

你的意思是, 担心数据传输过程中被人 篡改 ?
但 服务搭建者 和使用者 都是我自己啊.

[WJQSERVER]

你的意思是, 担心数据传输过程中被人 篡改 ? 但 服务搭建者 和使用者 都是我自己啊.

@crazypeace 确认proto要依靠 X-Forwarded-Proto和 Forwarded，这两个一个不是RFC标准头, 一个在不少情况下不存在, 后端程序在前方存在多个中间盒的情况下想确认真实使用的proto实在是难

[WJQSERVER]

@crazypeace

[WJQSERVER]

你的意思是, 担心数据传输过程中被人 篡改 ? 但 服务搭建者 和使用者 都是我自己啊.

不是数据安全性问题, 而是想确认用户使用的是http还是https这件事本身就很麻烦且不确定性很大

[crazypeace]

好吧. 可能你这个项目功能多, 考虑的因素多.

我的目的本身只是解决一下访问github.com拉脚本和资源的问题.

那么, 我推一下这个ghproxy方案吧,
https://github.com/crazypeace/gh-proxy/
搭建者可以用 python 搭简单的 http 服务,
使用者可以使用这个 http 服务.

示例
https://youtu.be/Cf5tWuGMm6U?si=avAdiI_wqt1v6ZqS&t=141

效果