233 脚本 WebSocket + TLS 模式 Caddy V2 反代 v2ray 反代伪装网站
233 脚本一直是使用 Caddy V1。我想用 Caddy V2 实现 反代 v2ray 反代伪装网站。
先说一句闲话,我比较喜欢 233 脚本的设计:
在 Caddy 这一层把 path 去掉了,v2ray 设置的是空 path 的 Websocket。
在 Caddy 这一层把 TLS 验证也做了,v2ray 设置与证书无关。
这样 v2ray 的配置变得更简单和稳定,不管你的域名换不换,path
这样还有一个好处是,可以用多个域名或 path 来给多个用户提供互相隔离的节点。而这个实现在 Caddy 层,与 v2ray 无关。参见我的具体实践:多域名
233 脚本的
你的域名{
tls 一个邮箱@gmail.com
gzip
timeouts none
proxy / https://你反代伪装的网站 / {
except /v2ray的 path
}
proxy /v2ray的 path 127.0.0.1:v2ray 的端口 {
without /v2ray的 path
websocket
}
}
我们要改成 Caddy V2 格式的,一点一点来。
tls 部分,Caddy V2 支持一个 on_demand 模式,等到有请求的时候再去申请证书。
tls 一个邮箱@gmail.com {
on_demand
}
gzip 变成了 encode gzip。
timeouts none 不支持,去掉。
proxy 命令,在 V2 变成了 reverse_proxy。不再用 except 去区分 path。without 也变成了
handle /foo/* {
file_server
}
handle {
reverse_proxy 127.0.0.1:8080
}
终于明白了 V2 如何对不同的 path 分流。再参考了 handle-path 的文档以后改写成下面这个样子。
handle_path /v2ray的 path {
reverse_proxy localhost:v2ray的端口
}
handle {
reverse_proxy https://你反代伪装的网站 {
header_up Host {upstream_hostport}
header_up X-Forwarded-Host {host}
}
}
这样确实更合理,对比 V1 的配置文件,V2 的配置文件中,v2ray的
对了,websocket 在 V2 中是默认打开的了,所以不用写了。而 reverse_proxy 时,默认是 transparent 的。如果去了另一个域名,就需要修改 header_up。
至此,来看看我们的结果吧。
你的域名{
tls 一个邮箱@gmail.com {
on_demand
}
encode gzip
handle_path /v2ray的 path {
reverse_proxy localhost:v2ray的端口
}
handle {
reverse_proxy https://你反代伪装的网站 {
header_up Host {upstream_hostport}
header_up X-Forwarded-Host {host}
}
}
}
===================
update
Caddy V2.5.0
你的域名 # 改这里{tls Y3JhenlwZWFjZQ@gmail.comencode gziphandle_path /分流 path { # 改这里 reverse_proxy localhost:你的 v2ray 内部端口 # 改这里 }handle {reverse_proxy https://你反代伪装的网站 { # 改这里 trusted_proxies 0.0.0.0/0header_up Host {upstream_hostport}}}}
===================
注意反代网站地址的末尾没有 / 符号
参考:https://caddyserver.com/docs/caddyfile/directives/reverse_proxy
注意 handle_path 与 handle 的区别. handle_path 是一种快捷写法, 用于自动移除 path, 比如 a.com/abc 想要代理 b.com, 想要访问 b.com/b 的等效地址为 a.com/abc/b, 这时就会使用 handle_path.
在做 v2ray 代理的时候, 一般不需要 handle_path, handle 即可.
你说的每个字都是正确的。
换不换,都和 v2ray 没关系。不用修改配置文件,也就少了出错的机会。”
你愿意在修改 path 的时候,既修改 caddy 配置文件 caddyfile 也修改 v2ray 配置文件 config.json,那是你的自由。
删除但是我的思路(出发点)和你不一样,而且我写在了正文中。
“先说一句闲话,我比较喜欢 233 脚本的设计:
在 Caddy 这一层把 path 去掉了,v2ray 设置的是空 path 的 Websocket。
在 Caddy 这一层把 TLS 验证也做了,v2ray 设置与证书无关。
这样 v2ray 的配置变得更简单和稳定,不管你的域名换不换,path
能否把您的 v2ray 服务端的配置也一并贴出来?便于理解
回复删除比如服务端 ws 的 path 是留空还是设置为 / 是开还是关
删除tls
请见 https://zelikk.blogspot.com/2022/05/v2ray-websocket-tls-caddy-path-data-flow.html 设置为 /,因为在我的 Caddy 配置文件写法中,把 path 去掉了。别人的方案中,有可能 v2ray 服务端的配置中,path 不应设置为 / 设置为关, 因为在 Caddy 这一层把 tls 解开了。
删除path
tls
好的,谢谢
删除好吧,搞半天我发现我的协议用的是 vmess。那请问你这种配置方式支持 vmess 吗?
删除当然支持 vmess, 理论知识还是见此教程
https://zelikk.blogspot.com/2022/05/v2ray-websocket-tls-caddy-path-data-flow.html
你把 v2ray 服务端配置文件里的 protocol 改为 vmess 就行了。 这一层并不理解 websocket 里面装着什么。所以 caddy 只是解开 tls,我的方案还会清理掉 path,然后就转到 v2ray 服务端去了。 v2ray 服务端设置数据协议为 vmess 还是 VLESS, 和 caddy 这一层的设置没有关系。
删除caddy
所以
好的好的
回复删除请教一个问题。不知道 caddy 是否能实现一个功能,我当前有两个服务器,一个在国内 CN,一个在外国 SG。CN 服务器上面有一些服务我是使用 cloudflare 的 tunnel 来访问的一个类似导航页面(页面上的所有链接也是 CF tunnel 的),这样能避免一些备案方面的问题。
cf 的 tunnel 的网站的话,是绕一圈美国再回来,我现在想用 SG 机器上用 caddy(域名 SG.COM)来反代 CN 机器上的网页(CN.COM),用你上面写的方法可以了。
CN.COM 页面上的其他链接也能通过 SG 的 caddy 来一起反代 页面里面有下面几个链接)
需要怎么设置?
回复删除但是大陆这边访问使用
不过我想让
例如:(CN.COM
A.CN.COM
B.CN.COM
D.CN.COM
Z.OTHER.NET
感谢
你的意思是, cn.com 上面的网页,内容是 a.cn.com; b.cn.com; ...
你希望用 sg.com 反代以后,内容变成 a.sg.com; b.sg.com; ...
是吗?
删除可能我前面表述不太清晰,请见谅。 机器上面有自己学习建的一些服务,现在是通过 cloud flare tunnel,来访问这些服务。
CN.COM(用了 CF tunnel),来放这些服务的链接。包括导航页本身也是走的 CF tunnel。 但是我在本地 ping 这个 cn.com,近 300 的延迟。 网上的资料说是免费 CF 用户的 tunnel,从大陆访问是需要先绕美国。
SG 的机器上 ping 这个 cn.com,是 10 以内的延迟。我本机访问这个 SG 机器,是 50 左右的延迟。
SG 网站上的 caddy,用 SG.COM 域名来反代 CN.COM,包括 CN.COM 网页上的那些链接,都是想通过 SG 反向代理来访问,这样能达到降低延迟的目的。
SG 反代之后,那些链接是否会变成 A.SG.COM,倒是没有想过。目标是要访问 SG.COM 时,通过 SG 代理访问了 CN.COM(已按你的实现了),然后进一步目标时,我在访问 SG.COM 的时候看到的链接(CN.COM 页面上的其他链接),点进去也能通过 SG 服务器来访问。
能否实现这样的功能。期待并感谢你的回复!
删除我当前的情况是这样:
1、CN
2、我在这机器上弄了个导航页的网站
3、而我在
所以我想实现一个目标,就是通过在
至于通过
不知道我这样表述能否清晰,caddy
你好!欢迎交流! “我在访问 SG.COM 的时候看到的链接(CN.COM 页面上的其他链接),点进去也能通过 SG 服务器来访问。” 在访问这个链接时,还是要通过域名解析等步骤,也就是说如果是访问一个 a.cn.com 的链接,你会解析成哪个 IP 呢?肯定还是 cn.com 的 IP 对吧? SG.COM 速度才变快的对观吧?
这样,在你访问的是 SG.COM 时,你访问 ./linka 就是访问 SG.COM/linka; 在你访问的是 CN.COM 时,你访问 ./linka 就是访问 CN.COM/linka
如你所说
你再回想一下,你是因为访问了
-
不过我在想一个方案,你把页面上的链接写成 ./linka ./linkb ./linkc
有一点不符合【如果是访问一个 a.cn.com 的链接,你会解析成哪个 IP 呢?肯定还是 cn.com 的 IP 对吧?】,
是走 cf tunnel 的访问,然后页面上的全部链接的域名 (也是国内其他机器)都是走 cf tunnel 的访问的,比如说页面上的 url:A.CN.COM 这个链接,不一定是跟 CN.COM 在同一个服务器上的,也不一定解析到同一个 ip,因为我也不清楚 cftunnel 里面怎么走的。我看 CF 里面的 DNS 记录:CN.COM , A.CN.COM 这些域名是 cname 到 cf 内部的域名地址。
SG 服务器上反向代理来访问这些域名,因为会比国内直接访问这些域名要快。比如我在国内电信 ping 这个 CN.COM,延迟在 260ms 左右,我在 SG 的机器上 ping,延迟在 5ms 以内,然后我国内电信 ping 这个 SG 的机器在 50ms 以内,所以感觉通过这样中转一下比较快。
Heimdall 的 docker 来做的导航页。
删除CN.COM
所以我才想通过
而且我是个新手,不太理解你这个方案是如何实现。我是使用
谢谢!
你现在的反代就是通过通过访问 SG.COM 来返回 CN.COM 的内容对吧?
那不是同样的操作, 你用 一个 A.SG.COM 反代 A.CN.COM,然后你访问 A.SG.COM 就返回 A.CN.COM 的内容?
中文环境下叫 相对路径 参考 https://www.w3school.com.cn/html/html_filepaths.asp
所以问题还是在于:你访问 CN.COM 返回的内容里面链接是 A.CN.COM 而不是 A.SG.COM 啊。
所以我的想法是使用 Relative URLs 参考 https://www.w3schools.com/html/html_links.asp
谢谢回复。
CN.COM(在 VPS2)上面的所有 URL,链接的都不是在 VPS2 里面的 URL,都是 VPS3/4/5 的链接,而且这些链接都是通过 cloudflare tunnel 获得的(目的是不需要备案,用户访问这个内地的 VPS 都能使用 https)。
CN.COM 在同一个 VPS2 上的 url,才能用相对路径吧,我的理解对吗?
CN.COM 上面那些 URL 为相对路径,来实现在 SG.COM 统一反代。
chatgpt(3.5 版本)来找解决方案,它提供了一个在 caddy 配置文件里,通过 rewrite 的方式来处理。但是它给出的所有配置示例,我放在 SG.COM(vps1)上面都会造成 caddy 无法运行。我也提示了 chatgpt,我的 caddy 版本是 v2.6.2。因为个人水平有限,我暂时看不明白错误信息提示的是什么意思,只是把全部错误信息反馈给 chatgpt 了,它修改了几次我发现都是反反复复的,总是运行不起来 caddy。
回复删除em……我这个
我看你介绍的【相对路径】的文章,按我的理解,好像只能使用跟
也就是说,按我现在的情况,好像无法通过更改
我尝试使用
这一块我就不太熟了。
删除祝你顺利!