V2ray-core: CloudFlare 拯救 IP，但是连接失败

Created on 29 Feb 2020  ·  12Comments  ·  Source: v2ray/v2ray-core

提交 Issue 之前请先阅读 Issue 指引，然后回答下面的问题，谢谢。
除非特殊情况，请完整填写所有问题。不按模板发的 issue 将直接被关闭。
如果你遇到的问题不是 V2Ray 的 bug，比如你不清楚要如何配置，请使用Discussion进行讨论。

1) 你正在使用哪个版本的 V2Ray？（如果服务器和客户端使用了不同版本，请注明）
当前 V2Ray 版本: v4.22.1 / 当前 V2Ray 管理脚本版本: v3.31

2) 你的使用场景是什么？比如使用 Chrome 通过 Socks/VMess 代理观看 YouTube 视频。
使用 Chrome 访问 Google

3) 你看到的不正常的现象是什么？（请描述具体现象，比如访问超时，TLS 证书错误等）
我用 CloudFlare 中转，WS+TLS 协议方式尝试拯救 IP，按照正常操作完成，但是还是无法访问 google 等网站

4) 你期待看到的正确表现是怎样的？
拯救 IP，并可以访问 google 等网站

5) 请附上你的配置（提交 Issue 前请隐藏服务器端IP地址）。

服务器端配置:

{
        "log": {
                "access": "/var/log/v2ray/access.log",
                "error": "/var/log/v2ray/error.log",
                "loglevel": "warning"
        },
        "inbounds": [
                {
                        "port": 33683,
                        "protocol": "vmess",
                        "settings": {
                                "clients": [
                                        {
                                                "id": "*******-0879-4899-9ce2-8d507c37df70",
                                                "level": 1,
                                                "alterId": 233
                                        }
                                ]
                        },
                        "streamSettings": {
                                "network": "ws"
                        },
                        "sniffing": {
                                "enabled": true,
                                "destOverride": [
                                        "http",
                                        "tls"
                                ]
                        }
                }
                //include_ss
                //include_socks
                //include_mtproto
                //include_in_config
                //
        ],
        "outbounds": [
                {
                        "protocol": "freedom",
                        "settings": {
                                "domainStrategy": "UseIP"
                        },
                        "tag": "direct"
                },
                {
                        "protocol": "blackhole",
                        "settings": {},
                        "tag": "blocked"
        },
                {
                        "protocol": "mtproto",
                        "settings": {},
                        "tag": "tg-out"
                }
                //include_out_config
                //
        ],
        "dns": {
                "servers": [
                        "https+local://1.1.1.1/dns-query",
                        "1.1.1.1",
                        "1.0.0.1",
                        "8.8.8.8",
                        "8.8.4.4",
                        "localhost"
                ]
        },
        "routing": {
                "domainStrategy": "IPOnDemand",
                "rules": [
                        {
                                "type": "field",
                                "ip": [
                                        "0.0.0.0/8",
                                        "10.0.0.0/8",
                                        "100.64.0.0/10",
                                        "127.0.0.0/8",
                                        "169.254.0.0/16",
                                        "172.16.0.0/12",
                                        "192.0.0.0/24",
                                        "192.0.2.0/24",
                                        "192.168.0.0/16",
                                        "198.18.0.0/15",
                                        "198.51.100.0/24",
                                        "203.0.113.0/24",
                                        "::1/128",
                                        "fc00::/7",
                                        "fe80::/10"
                                ],
                                "outboundTag": "blocked"
                        },
                        {
                                "type": "field",
                                "inboundTag": ["tg-in"],
                                "outboundTag": "tg-out"
                        }
                        ,
                        {
                                "type": "field",
                                "domain": [
                                        "domain:epochtimes.com",
                                        "domain:epochtimes.com.tw",
                                        "domain:epochtimes.fr",
                                        "domain:epochtimes.de",
                                        "domain:epochtimes.jp",
                                        "domain:epochtimes.ru",
                                        "domain:epochtimes.co.il",
                                        "domain:epochtimes.co.kr",
                                        "domain:epochtimes-romania.com",
                                        "domain:erabaru.net",
                                        "domain:lagranepoca.com",
                                        "domain:theepochtimes.com",
                                        "domain:ntdtv.com",
                                        "domain:ntd.tv",
                                        "domain:ntdtv-dc.com",
                                        "domain:ntdtv.com.tw",
                                        "domain:minghui.org",
                                        "domain:renminbao.com",
                                        "domain:dafahao.com",
                                        "domain:dongtaiwang.com",
                                        "domain:falundafa.org",
                                        "domain:wujieliulan.com",
                                        "domain:ninecommentaries.com",
                                        "domain:shenyun.com"
                                ],
                                "outboundTag": "blocked"
                        }                       ,
                {
                    "type": "field",
                    "protocol": [
                        "bittorrent"
                    ],
                    "outboundTag": "blocked"
                }
                        //include_ban_ad
                        //include_rules
                        //
                ]
        },
        "transport": {
                "kcpSettings": {
            "uplinkCapacity": 100,
            "downlinkCapacity": 100,
            "congestion": true
        }
        }

客户端配置:

image

6) 请附上出错时软件输出的错误日志。在 Linux 中，日志通常在 /var/log/v2ray/error.log 文件中。

服务器端错误日志:

    // 在这里附上服务器端日志

客户端错误日志:

客户端会一直提示这个错误

[Warning] failed to handler mux client connection > ***.com/core/proxy/vmess/outbound: failed to find an available destination > ***.com/core/common/retry: [***.com/core/transport/internet/websocket: failed to dial WebSocket > ***.com/core/transport/internet/websocket: failed to dial to (wss://***.com/): 301 Moved Permanently > websocket: bad handshake] > ***.com/core/common/retry: all retry attempts failed

7) 请附上访问日志。在 Linux 中，日志通常在 /var/log/v2ray/access.log 文件中。

    // 在这里附上服务器端日志

8) 其它相关的配置文件（如 Nginx）和相关日志。

9) 如果 V2Ray 无法启动，请附上 --test 输出。

通常的命令为 /usr/bin/v2ray/v2ray --test --config /etc/v2ray/config.json。请按实际情况修改。

10) 如果 V2Ray 服务运行不正常，请附上 journal 日志。

通常的命令为 journalctl -u v2ray。

请问是什么问题？

Need Config Need Logs Response Timeout
Source
picture Jamestone

Most helpful comment

我還是來說明一下好了。

Cloudflare 支援的源站 HTTP 端口是：

  • 80
  • 8080
  • 8880
  • 2052
  • 2082
  • 2086
  • 2095

Cloudflare 支援的源站 HTTPS 端口是：

  • 443
  • 2053
  • 2083
  • 2087
  • 2096
  • 8443

但位於中國境內的源站，由於眾所周知的原因，Cloudflare Apps 代理和 Cloudflare 緩存只支援 80 和 443 端口。

數據來源：https://support.cloudflare.com/hc/en-us/articles/200169156-Identifying-network-ports-compatible-with-Cloudflare-s-proxy

我看過的許多教程都建議直接選擇「Flexible SSL」，這的確是最省事的，卻也是最不靠譜的，這意味著 Cloudflare 與源站的通訊使用的是 HTTP，即「明文傳輸」。

也有的教程則是建議直接選擇「Full」，這比前一個要好很多，因為 Cloudflare 與源站的通訊已經是 HTTPS，即「加密傳輸」了。

但，「Full」的情況下，Cloudflare 並不會驗證源站的證書，也就是說，無論你是「域不匹配」，還是自簽的證書，Cloudflare 都將正常與源站通訊。

什麼是「域不匹配」？舉個例子：

你的源站域名是 example.com，你在 Cloudflare 要部署域名則是 cdn.example.com，但你只從 Let's Encrypt 獲取了 example.com 的證書，這個證書只支援 example.com，而不支援 cdn.example.com，這就是「域不匹配」。

那如何「域匹配」？舉個例子：

你的源站域名是 example.com，你在 Cloudflare 要部署域名則是 cdn.example.com，你不僅從 Let's Encrypt 獲取了 example.com 的證書，還獲取了 cdn.example.com 的證書。

但這樣就有兩個證書了呢，解決方案很簡單。舉個例子：

你從 Let's Encrypt 獲取了同時支援 example.com 和 cdn.example.com 的證書，這樣就是一個證書啦。

除此以外，也可以考慮獲取泛域名證書。

解決了「域匹配」後，就可以直接選擇「Full (strict)」。

再特別說明一下：

  • 不要使用 Let's Encrypt 的「Staging Environment」來獲取證書，這樣的證書不受到 Cloudflare 信任，同樣無法開啟「Full (strict)」。
  • 若搞定了「Full (strict)」，也可以考慮在「SSL/TLS」=>「Origin Server」所在處參考「文檔」開啟「Authenticated Origin Pulls」。
  • 源站甚至可以只開啟 HTTPS 端口。
  • Cloudflare 上「SSL/TLS」=>「Edge Certificates」所在處的「Always Use HTTPS」，在開啟狀態不會對源站造成影響，但「可能」會影響通過 HTTP-01 挑戰方式申請證書，可參見「文檔」，若有影響，可考慮關閉「Always Use HTTPS」，轉而在「Page Rules」裡設定你所需要的 HTTP 跳轉 HTTPS。

針對「Always Use HTTPS」處於開啟狀態下 HTTP-01 挑戰方式申請證書，本人測試過的（工具為 OpenBSD 下的 acme-client）：

  1. 僅申請 A/AAAA 記錄下開啟 Cloudflare 代理站點的證書無影響。
  2. 同時申請 A/AAAA 記錄下未開啟 Cloudflare 代理站點和使用 CNAME 記錄下開啟 Cloudflare 代理站點的證書受到影響（兩站點屬於一個未開啟 CDN，一個開啟 CDN 的關係，即站點內容一致）。

如有誤，則歡迎各位指正，並參與折騰。

picture ghost on 1 Mar 2020
👍10

All 12 comments

wss:// 这个错误 检查下 是否开启了 ws 代理 和 服务器域名是否正常

puzzle9 picture puzzle9 on 29 Feb 2020

首先一點是，你的打碼沒有起到作用，你提供的錯誤日誌，即便僅僅只有一行，也已經暴露出你的域名。

然後我查詢了你這個域名的解析，Cloudflare 的 IP 是有了，可惜站點根本打不開。

這說明是在 Cloudflare 的配置上出了問題。

我個人的猜測是：

  1. 你也許在「SSL/TLS」=>「Overview」這個設定裡選擇了「Full (strict)」，但源地址不存在「未過期，並由受信任的 CA 或 Cloudflare 來源 CA 簽名」。
  2. 你也許在「SSL/TLS」=>「Overview」這個設定裡選擇了「Full」，但源地址不支持「HTTPS」。

若以上猜測成立，而你又想省事，請在「SSL/TLS」=>「Overview」這個設定裡選擇「Flexible SSL」。

ghost picture ghost on 29 Feb 2020

順便一提，這個域名實在是有些明目張膽了呢，GFW 是看不見內容，但不代表看不見你訪問的是哪，建議換一個子域，並考慮一下建設一個真正運作的站點。

ghost picture ghost on 29 Feb 2020

端口改成80，tls关闭，即可使用，注意Cloudflare上关闭https跳转和tls回源功能

1265578519 picture 1265578519 on 1 Mar 2020
👍1

我還是來說明一下好了。

Cloudflare 支援的源站 HTTP 端口是：

  • 80
  • 8080
  • 8880
  • 2052
  • 2082
  • 2086
  • 2095

Cloudflare 支援的源站 HTTPS 端口是：

  • 443
  • 2053
  • 2083
  • 2087
  • 2096
  • 8443

但位於中國境內的源站，由於眾所周知的原因，Cloudflare Apps 代理和 Cloudflare 緩存只支援 80 和 443 端口。

數據來源：https://support.cloudflare.com/hc/en-us/articles/200169156-Identifying-network-ports-compatible-with-Cloudflare-s-proxy

我看過的許多教程都建議直接選擇「Flexible SSL」，這的確是最省事的，卻也是最不靠譜的，這意味著 Cloudflare 與源站的通訊使用的是 HTTP，即「明文傳輸」。

也有的教程則是建議直接選擇「Full」，這比前一個要好很多，因為 Cloudflare 與源站的通訊已經是 HTTPS，即「加密傳輸」了。

但，「Full」的情況下，Cloudflare 並不會驗證源站的證書，也就是說，無論你是「域不匹配」，還是自簽的證書，Cloudflare 都將正常與源站通訊。

什麼是「域不匹配」？舉個例子：

你的源站域名是 example.com，你在 Cloudflare 要部署域名則是 cdn.example.com，但你只從 Let's Encrypt 獲取了 example.com 的證書，這個證書只支援 example.com，而不支援 cdn.example.com，這就是「域不匹配」。

那如何「域匹配」？舉個例子：

你的源站域名是 example.com，你在 Cloudflare 要部署域名則是 cdn.example.com，你不僅從 Let's Encrypt 獲取了 example.com 的證書，還獲取了 cdn.example.com 的證書。

但這樣就有兩個證書了呢，解決方案很簡單。舉個例子：

你從 Let's Encrypt 獲取了同時支援 example.com 和 cdn.example.com 的證書，這樣就是一個證書啦。

除此以外，也可以考慮獲取泛域名證書。

解決了「域匹配」後，就可以直接選擇「Full (strict)」。

再特別說明一下：

  • 不要使用 Let's Encrypt 的「Staging Environment」來獲取證書，這樣的證書不受到 Cloudflare 信任，同樣無法開啟「Full (strict)」。
  • 若搞定了「Full (strict)」，也可以考慮在「SSL/TLS」=>「Origin Server」所在處參考「文檔」開啟「Authenticated Origin Pulls」。
  • 源站甚至可以只開啟 HTTPS 端口。
  • Cloudflare 上「SSL/TLS」=>「Edge Certificates」所在處的「Always Use HTTPS」，在開啟狀態不會對源站造成影響，但「可能」會影響通過 HTTP-01 挑戰方式申請證書，可參見「文檔」，若有影響，可考慮關閉「Always Use HTTPS」，轉而在「Page Rules」裡設定你所需要的 HTTP 跳轉 HTTPS。

針對「Always Use HTTPS」處於開啟狀態下 HTTP-01 挑戰方式申請證書，本人測試過的（工具為 OpenBSD 下的 acme-client）：

  1. 僅申請 A/AAAA 記錄下開啟 Cloudflare 代理站點的證書無影響。
  2. 同時申請 A/AAAA 記錄下未開啟 Cloudflare 代理站點和使用 CNAME 記錄下開啟 Cloudflare 代理站點的證書受到影響（兩站點屬於一個未開啟 CDN，一個開啟 CDN 的關係，即站點內容一致）。

如有誤，則歡迎各位指正，並參與折騰。

ghost picture ghost on 1 Mar 2020
👍10

其实配合zerotier 内网穿透拯救ip我觉得方便又快捷。

wangmice picture wangmice on 4 Mar 2020
👍1

IP被封，在虚拟局域网中还能连接？

On Wed, Mar 4, 2020 at 7:58 PM shu wang notifications@github.com wrote:

其实配合zerotier 内网穿透拯救ip我觉得方便又快捷。

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/v2ray/v2ray-core/issues/2298?email_source=notifications&email_token=AE34YTHBAAIKAKDQT7YULNTRFY64PA5CNFSM4K6JVIKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENXQPSQ#issuecomment-594479050,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE34YTC5IWEGHAJCN6GPNXDRFY64PANCNFSM4K6JVIKA
.

qingfengshi picture qingfengshi on 4 Mar 2020

IP被封，在虚拟局域网中还能连接？
…
On Wed, Mar 4, 2020 at 7:58 PM shu wang @.*> wrote: 其实配合zerotier 内网穿透拯救ip我觉得方便又快捷。 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2298?email_source=notifications&email_token=AE34YTHBAAIKAKDQT7YULNTRFY64PA5CNFSM4K6JVIKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENXQPSQ#issuecomment-594479050>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE34YTC5IWEGHAJCN6GPNXDRFY64PANCNFSM4K6JVIKA .

可以啊，vps 和 家里路由均装好zerotier，建立好虚拟网络，比如虚拟网址10.X.X.X，为vps的私有地址，v2ray 直接设置这个地址为服务器地址就行。前提是你想办法在封掉的vps上安装配置好zerotier，现在有ipv6了，一般ipv6地址不会封吧？

wangmice picture wangmice on 4 Mar 2020

你这么一说，我开始为zerotier还能用多久担心了，悲剧啊

On Wed, Mar 4, 2020 at 10:17 PM shu wang notifications@github.com wrote:

IP被封，在虚拟局域网中还能连接？
… <#m_6915129501293196156_>
On Wed, Mar 4, 2020 at 7:58 PM shu wang @.*> wrote: 其实配合zerotier
内网穿透拯救ip我觉得方便又快捷。 — You are receiving this because you are subscribed to
this thread. Reply to this email directly, view it on GitHub <#2298
https://github.com/v2ray/v2ray-core/issues/2298?email_source=notifications&email_token=AE34YTHBAAIKAKDQT7YULNTRFY64PA5CNFSM4K6JVIKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENXQPSQ#issuecomment-594479050>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE34YTC5IWEGHAJCN6GPNXDRFY64PANCNFSM4K6JVIKA
.

可以啊，vps 和 家里路由均装好zerotier，建立好虚拟网络，比如虚拟网址10.X.X.X，为vps的私有地址，v2ray
直接设置这个地址为服务器地址就行。

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/v2ray/v2ray-core/issues/2298?email_source=notifications&email_token=AE34YTHZUAU6LPYX4BMR4TDRFZPGBA5CNFSM4K6JVIKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENYBQPY#issuecomment-594548799,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE34YTCL3RS3IT743ZR5453RFZPGBANCNFSM4K6JVIKA
.

qingfengshi picture qingfengshi on 5 Mar 2020

你这么一说，我开始为zerotier还能用多久担心了，悲剧啊
…
On Wed, Mar 4, 2020 at 10:17 PM shu wang @.> wrote: IP被封，在虚拟局域网中还能连接？ … <#m_6915129501293196156_> On Wed, Mar 4, 2020 at 7:58 PM shu wang *@.*> wrote: 其实配合zerotier 内网穿透拯救ip我觉得方便又快捷。 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#2298 <#2298>?email_source=notifications&email_token=AE34YTHBAAIKAKDQT7YULNTRFY64PA5CNFSM4K6JVIKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENXQPSQ#issuecomment-594479050>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE34YTC5IWEGHAJCN6GPNXDRFY64PANCNFSM4K6JVIKA . 可以啊，vps 和 家里路由均装好zerotier，建立好虚拟网络，比如虚拟网址10.X.X.X，为vps的私有地址，v2ray 直接设置这个地址为服务器地址就行。 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2298?email_source=notifications&email_token=AE34YTHZUAU6LPYX4BMR4TDRFZPGBA5CNFSM4K6JVIKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENYBQPY#issuecomment-594548799>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE34YTCL3RS3IT743ZR5453RFZPGBANCNFSM4K6JVIKA .

应该没事吧，只不过在v2ray的基础上再包一层zerotier的隧道。别直接用zero 去fq就是了吧。

wangmice picture wangmice on 5 Mar 2020

通过zerotier端口发送的数据也是加密的，某种程度上和VPN有些相似，要是官方盯上了估计命不久矣。

On Thu, Mar 5, 2020 at 8:32 PM shu wang notifications@github.com wrote:

你这么一说，我开始为zerotier还能用多久担心了，悲剧啊
… <#m_-8503449043275401811_>
On Wed, Mar 4, 2020 at 10:17 PM shu wang @.> wrote: IP被封，在虚拟局域网中还能连接？
… <#m_6915129501293196156_> On Wed, Mar 4, 2020 at 7:58 PM shu wang @.>
wrote: 其实配合zerotier 内网穿透拯救ip我觉得方便又快捷。 — You are receiving this because you
are subscribed to this thread. Reply to this email directly, view it on
GitHub <#2298 https://github.com/v2ray/v2ray-core/issues/2298 <#2298
https://github.com/v2ray/v2ray-core/issues/2298>?email_source=notifications&email_token=AE34YTHBAAIKAKDQT7YULNTRFY64PA5CNFSM4K6JVIKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENXQPSQ#issuecomment-594479050>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE34YTC5IWEGHAJCN6GPNXDRFY64PANCNFSM4K6JVIKA
. 可以啊，vps 和 家里路由均装好zerotier，建立好虚拟网络，比如虚拟网址10.X.X.X，为vps的私有地址，v2ray
直接设置这个地址为服务器地址就行。 — You are receiving this because you commented. Reply to
this email directly, view it on GitHub <#2298
https://github.com/v2ray/v2ray-core/issues/2298?email_source=notifications&email_token=AE34YTHZUAU6LPYX4BMR4TDRFZPGBA5CNFSM4K6JVIKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENYBQPY#issuecomment-594548799>,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE34YTCL3RS3IT743ZR5453RFZPGBANCNFSM4K6JVIKA
.

应该没事吧，只不过在v2ray的基础上再包一层zerotier的隧道。

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/v2ray/v2ray-core/issues/2298?email_source=notifications&email_token=AE34YTG5OCJVUSV5CUKTAELRF6LURA5CNFSM4K6JVIKKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEN5B4LQ#issuecomment-595205678,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AE34YTHA7B7SLG4I4GM3WGDRF6LURANCNFSM4K6JVIKA
.

qingfengshi picture qingfengshi on 5 Mar 2020

看你这个配置就知道是有问题的
"port": 33683

Cloudflare 只支持80和443. 要么v2ray port:80 用CF转发(TLS关闭)
要么Apache NGINX caddy 加载证书在443做反向代理

mivtec picture mivtec on 16 Mar 2020
Was this page helpful?
0 / 5 - 0 ratings

Related issues

sunsan05 picture sunsan05  ·  3Comments
ghost picture ghost  ·  4Comments
gzzchh picture gzzchh  ·  3Comments
samjoeyang picture samjoeyang  ·  4Comments
supersndqd picture supersndqd  ·  3Comments