利用国内vps作为中间代理转发请求到国外vps

[Rain Zen]

国外的vps可以帮助我们科学上网，但使用时间长了，很可能会出现限流或不稳定的情况。

这时如果通过国内的vps作为中转，情况可能会有所改善。

这里假设国内vps地址是aliyun.com，国外vps地址是linode.com，有两种方法。

第一种可以称之为桥式：

先架好桥墩

国外vps上(linode.com)：

gost -L=:1080

国内vps上(aliyun.com)：

gost -L=:8080

然后连接各个桥墩，就可以过桥了：

本地：

gost -L=:8888 -F=http://aliyun.com:8080 -F=socks://linode.com:1080

这种方式，由于各vps之间是独立的，所以灵活性较好，在vps较多时可以任意组合。 

另外一种称之为链式：

先构建一个链：

国外vps上(linode.com)：

gost -L=:1080

国内vps上(aliyun.com)：

gost -L=http+tls://:443 -F=socks://linode.com:1080

然后构建本地链：

本地：

gost -L=:8888 -F=http+tls://aliyun.com:443

这种方式虽然没有第一种灵活，但可以通过设置国内vps为https或shadowsocks代理，让支持此类型代理的应用直连国内vps就可以科学上网了。

[wz]

gost -L ss://aes-256-cfb:123456@:8338  -F socks://socks5_server:port 成功
国内ss-国外socks 是成功的
但是国内ss-国外ss 不知怎么配置

在 2015年12月23日星期三 UTC+8下午10:28:21，Rain Zen写道：

[Rain Zen]

-F与-L参数的格式是一样的：

gost -L ss://aes-256-cfb:123...@china.com:8338 -F ss://aes-256-cfb:123...@us.com:8338

在 2015年12月26日星期六 UTC+8下午6:47:29，wz写道：

[wz]

谢谢，成功了

在 2015年12月28日星期一 UTC+8上午9:31:39，Rain Zen写道：

-F与-L参数的格式是一样的：

gost -L ss://aes-256-cfb:123456@china.com:8338 -F ss://aes-256-cfb:123456@us.com:8338

[philip...@gmail.com]

非常好用，我用国外SS-国外SS，国内SS-国内SS都成功了。这个在特殊环境下，比前置代理好用多了。THX

Rain Zen於 2015年12月23日星期三 UTC+8下午10時28分21秒寫道：

[sdr...@gmail.com]

第二种链式，本地直接配置aliyun的是不是也可以，为啥本地还要再开一层？

在 2015年12月23日星期三 UTC+8下午10:28:21，Rain Zen写道：

国外的vps可以帮助我们科学上网，但使用时间长了，很可能会出现限流或不稳定的情况。

[Rain Zen]

如果是标准的代理协议(http/https/socks5)可以本地直接使用

在 2016年4月3日星期日 UTC+8下午12:19:27，sdr...@gmail.com写道：

[Basil]

用了挺长时间，非常好！

请问gost内置证书是否支持在chrome里直接添加https代理? 

另外有没有考虑-F支持backup或负载平衡等多服务器模式(类似MEOW这种策略 https://github.com/renzhn/MEOW)，因为单一转发链总存在一些不稳定性。 

谢谢！

[Del...@sanri.info]

学习了，有空试试

[amu1...@gmail.com]

国内VPS的低带宽怎么解决？

在 2015年12月28日星期一 UTC+8上午11:37:15，wz写道：

[wz]

现在docker很热，国内docker平台兴起，提供免费配额，速度不错，至于平台有哪几家，自己搜一下就知道了

在 2016年5月13日星期五 UTC+8下午6:03:12，amu1...@gmail.com写道：

[amu1...@gmail.com]

有推荐的吗？我测试了时速云，感觉速度很一般，还不如直连

在 2016年5月13日星期五 UTC+8下午8:03:58，wz写道：

[wz]

时速云限速5m，现在也取消免费的了，灵雀云不限速，每月免费流量10G

[jus...@gmail.com]

在中间跳转服务器，还可以有一种方式，也可以说是第二种方式变种，即端口转发。

不知道作者，或各位谁测过 gost 那种方式的时延、计算要求高低？

感觉端口转发效率要高一些。

另外，问一下作者，是否测过在跳转服务器，和终点代理服务器设置TCP BBR用来优化tcp算法，或者使用UDPspeeder https://github.com/wangyu-/UDPspeeder/ 加速quic 的效果如何？

[关刀]

我有A,B两台服务器在国内，有C,D两台服务器在国外。现在A和D通信：我要A经过B，然后B经过C，再通过C访问D的方式来通信。

配置如下：

C-server： gost  -L=:8080  -D

B-server： gost  -L=:8081  -D

A-server： gost  -L=:8082  -F=B-server:8081  -F=C-server:8080 -D

下面我通过curl，并指定A-server代理，结果能访问D-server：

curl  -x  A-server:8082  http://D-server:8080 

问题：我如何在A-server通过自己写的应用（tcp协议）来和D-server通信？ 因为我不知道如何另自己的应用走代理A 

在 2015年12月23日星期三 UTC+8下午10:28:21，ginuerzh写道：

[ginuerzh]

应用若想走代理，需要应用本身支持代理，可能需要你自己实现了。

如果你是与D-server上的单一服务进行通讯，也可以使用端口转发，将D-server上的服务映射到A-server上， 

这样，你的应用就可以直接在本地通讯，而不需要设置代理了。

例如，你想访问D-server上的1234端口，可以把1234端口映射到A-server的1234端口上：

gost -L tcp://:1234/D-server:1234 -F B-server:8081 -F C-server:8080

这样你的应用就可以与本地的1234端口直接通讯了。

端口转发的使用说明请参考：https://docs.ginuerzh.xyz/gost/port-forwarding/

在 2018年5月8日星期二 UTC+8上午12:43:24，travis写道：