V2ray-core: websocket+tls+nginx+cdn断流严重

Created on 12 Jun 2019 · 31Comments · Source: v2ray/v2ray-core

连开几台服务器都是IP被墙, 用websocket+tls+nginx+cdn想挽救一下被墙ip,连得上但很不稳定,断流严重

cdn用的cloudflare

1) 你正在使用哪个版本的 V2Ray？（如果服务器和客户端使用了不同版本，请注明）

v4.19.1

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

通过Chrome访问Google服务

3) 你看到的不正常的现象是什么？（请描述具体现象，比如访问超时，TLS 证书错误等）

时常完全无法连接, 但一旦连接得上速度会很快. 第一次打开一个网页连不上或只加载出一部分, 刷新一次又能正常打开. 上述现象每隔一段不固定的时间就会出现.

4) 你期待看到的正确表现是怎样的？

稳定的访问速度

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

服务器端配置:

    {
  "log": {
  "access": "/v2la",
  "error": "/v2le",
  "loglevel": "debug"
  },
  "inbounds": [
    {
      "port": #,
      "listen":"127.0.0.1",
      "protocol": "vmess",
      "settings": {
        "clients": [
          {
            "id": "#",
            "alterId": #
          }
        ]
      },
      "streamSettings": {
        "network": "ws",
        "wsSettings": {
        "path": "/ray"
        }
      }
    }
  ],
  "outbounds": [
    {
      "protocol": "freedom",
      "settings": {}
    }
  ]
}

客户端配置:

    {
    "log": {
        "error": "/v2ray_error.log",
        "loglevel": "debug"
    },
    "inbound": {
        "port": 1081,
        "listen": "127.0.0.1",
        "protocol": "socks",
        "settings": {
            "auth": "noauth",
            "udp": true,
            "ip": "127.0.0.1"
        }
    },
    "outbound": {
        "protocol": "vmess",
        "settings": {
            "vnext": [
                {
                    "address": "#",
                    "port": #,
                    "users": [
                        {
                            "id": "#",
                            "alterId": #,
                            "security": "auto"
                        }
                    ]
                }
            ]
        },
     "streamSettings": {
         "network":"ws",
         "security":"tls",
         "tlsSettings":{
             "serverName":"#",
             "allowInsecure": false
         },
         "wsSettings":{
             "path":"/ray"
         }
     },
        "mux": {
            "enabled": true
        }
    },
    "outboundDetour": [
        {
            "protocol": "freedom",
            "settings": {},
            "tag": "direct"
        }
    ],
    "dns": {
        "servers": [
            "8.8.8.8",
            "8.8.4.4",
            "localhost"
        ]
    },
    "routing": {
        "strategy": "rules",
        "settings": {
            "domainStrategy": "IPIfNonMatch",
            "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",
                        "geoip:cn",
                        "geoip:private",
                        "172.40.23.0/24"
                    ],
                    "outboundTag": "direct"
                },
                {
                    "type": "field",
                    "domain": [
                        "geosite:cn",
                        "vjudge.net"
                    ],
                    "outboundTag": "direct"
                },
                {
                    "type": "chinasites",
                    "outboundTag": "direct"
                },
                {
                    "type": "chinaip",
                    "outboundTag": "direct"
                }
            ]
        }
    }
}

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

服务器端错误日志:

    2019/06/12 07:55:00 [Info] [3447644883] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/freedom: connection ends > context canceled
2019/06/12 07:55:00 [Info] [3447644883] v2ray.com/core/common/mux: session 2 ends. > io: read/write on closed pipe

客户端错误日志:

    2019/06/12 13:47:17 [Warning] [4123969252] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: failed to find an available destination > v2ray.com/core/common/retry: [v2ray.com/core/transport/internet/websocket: failed to dial WebSocket > v2ray.com/core/transport/internet/websocket: failed to dial to (wss://#/ray): 403 Forbidden > websocket: bad handshake] > v2ray.com/core/common/retry: all retry attempts failed

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

    2019/06/12 08:55:31 61.187.87.194:37464 accepted tcp:www.gstatic.com:443 
2019/06/12 08:55:32 61.187.87.194:37468 accepted tcp:apis.google.com:443 
2019/06/12 08:55:59 61.187.87.194:37472 accepted udp:8.8.8.8:53 
2019/06/12 08:56:01 61.187.87.194:37474 accepted tcp:clients4.google.com:443 
2019/06/12 08:56:02 61.187.87.194:37478 accepted udp:8.8.4.4:53 
2019/06/12 08:56:03 61.187.87.194:37480 accepted tcp:safebrowsing.googleapis.com:443 
2019/06/12 08:56:04 61.187.87.194:37484 accepted tcp:safebrowsing.googleapis.com:443 
2019/06/12 08:56:12 61.187.87.194:37488 accepted tcp:clients1.google.com:443 
2019/06/12 08:56:29 61.187.87.194:37492 accepted tcp:clients4.google.com:443 
2019/06/12 08:56:31 61.187.87.194:37496 accepted tcp:clients4.google.com:443 
2019/06/12 08:57:01 61.187.87.194:37500 accepted tcp:clients1.google.com:443 
2019/06/12 08:58:09 61.187.87.194:37504 accepted tcp:clients4.google.com:443 
2019/06/12 08:59:37 61.187.87.194:37508 accepted udp:8.8.8.8:53 
2019/06/12 09:05:44 61.187.87.194:37510 accepted udp:8.8.8.8:53 
2019/06/12 09:05:50 61.187.87.194:37512 accepted tcp:safebrowsing.googleapis.com:443 
2019/06/12 09:06:03 61.187.87.194:37516 rejected  v2ray.com/core/proxy/vmess/encoding: failed to read request header > websocket: close 1000 (normal)
2019/06/12 09:06:16 61.187.87.194:37518 accepted udp:8.8.8.8:53 
2019/06/12 09:06:17 61.187.87.194:37520 accepted tcp:clients1.google.com:443 
2019/06/12 09:06:29 61.187.87.194:37524 accepted tcp:clients1.google.com:443 
2019/06/12 09:08:09 61.187.87.194:37528 accepted udp:8.8.4.4:53 
2019/06/12 09:09:33 61.187.87.194:37530 accepted udp:8.8.4.4:53 
2019/06/12 09:09:42 61.187.87.194:37532 rejected  v2ray.com/core/proxy/vmess/encoding: failed to read request header > websocket: close 1000 (normal)
2019/06/12 09:09:48 61.187.87.194:37534 accepted udp:8.8.8.8:53 
2019/06/12 09:09:49 61.187.87.194:37536 accepted tcp:clients4.google.com:443 
2019/06/12 09:09:50 61.187.87.194:37540 accepted tcp:clientservices.googleapis.com:80 
2019/06/12 09:10:22 61.187.87.194:37544 accepted tcp:clients4.google.com:443 
2019/06/12 09:10:35 61.187.87.194:37548 accepted tcp:clientservices.googleapis.com:443 
2019/06/12 09:15:51 61.187.87.194:37552 accepted udp:8.8.4.4:53 
2019/06/12 09:17:55 61.187.87.194:37554 rejected  v2ray.com/core/proxy/vmess/encoding: failed to read request header > websocket: close 1000 (normal)
2019/06/12 09:18:01 61.187.87.194:37556 accepted tcp:www.google.com:443

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

nginx配置:

location /ray
    {                            
        proxy_redirect off;
        proxy_pass http://127.0.0.1:1234;      
        proxy_http_version 1.1;
        proxy_set_header Upgrade $http_upgrade;
        proxy_set_header Connection "upgrade";
        proxy_set_header Host $http_host;
    }

nginx错误日志:

2019/06/11 22:53:37 [error] 23680#0: *1073 recv() failed (104: Connection reset by peer) while proxying upgraded connection, client: #, server: f.xccbk.cn, request: "GET /ray HTTP/1.1", upstream: "http://127.0.0.1:1234/ray", host: "#"

chrome错误信息:

ERR_SSL_VERSION_INTERFERENCE
ERR_EMPTY_RESPONSE
ERR_Connection_Closed
ERR_CONNECTION_TIMED_OUT

Source

utmtl

Most helpful comment

我找到根因了...
CloudFlare的默认防火墙限制有点严格, 在那种很多人共用一个公网IP的环境下会经常弹出验证码, 对于我的FQ流量直接reset...
在CF的Firewall那一项里面调一下之后快到飞起...

求教是在CF的Firewall里调哪一项

可以在Firewall rules里面添加一条Action为Allow规则, Field选IP(填你自己的IP)或者Path(v2ray服务的Path). 也可以在Tools里面的IP Access Rules添加一条你自己的IP选Whitelist. 还可以直接把settings里面的Security Level调成Essentially Off(这样会有被d的风险,不过一般不会发生). 亲测一起用效果最佳.

utmtl on 19 Aug 2019

👍29 ❤13

All 31 comments

跟cdn的质量和cdn分配的ip地址有很大关系.
晚上移动速度渣得爆炸

FirstJavaMaster on 12 Jun 2019

@FirstJavaMaster 我还以为是配置问题, 查了好久的错还全部重做了一遍......
那请问有什么优化或者解决的办法吗?

utmtl on 12 Jun 2019

@FirstJavaMaster 我还以为是配置问题, 查了好久的错还全部重做了一遍......
那请问有什么优化或者解决的办法吗?

没找到. 鱼与熊掌不可兼得

FirstJavaMaster on 12 Jun 2019

@FirstJavaMaster 我还以为是配置问题, 查了好久的错还全部重做了一遍......
那请问有什么优化或者解决的办法吗?

没找到. 鱼与熊掌不可兼得

的确. 而且被墙之后只剩一个选择了.

不过我也不期望有多快, 别完全断流得太频繁就行了

utmtl on 12 Jun 2019

加了cdn，我的移动是完全上不去，而不是断流。电信都可以的，目前暂时关掉cdn，只能小心翼翼

shiningelf on 14 Jun 2019

白天情况好很多,晚上变得很糟糕.
晚上移动宽带加cdn反而比不加cdn速度快上一丢丢
无论白天晚上电信宽带总比移动好一些

FirstJavaMaster on 14 Jun 2019

楼主你cdn选择就没对。这国外的cdn根本就不行啊

zhengweisk on 18 Jun 2019

楼主你cdn选择就没对。这国外的cdn根本就不行啊

主要是国内也不敢用呀...

FirstJavaMaster on 18 Jun 2019

cloudflare白天还行，晚上速度很慢的

blinkspark on 24 Jun 2019

断流似乎是因为mux，我关了mux，断流就少多了。

Abderrian on 13 Jul 2019

我找到根因了...
CloudFlare的默认防火墙限制有点严格, 在那种很多人共用一个公网IP的环境下会经常弹出验证码, 对于我的FQ流量直接reset...
在CF的Firewall那一项里面调一下之后快到飞起...

utmtl on 29 Jul 2019

👍14

我找到根因了...
CloudFlare的默认防火墙限制有点严格, 在那种很多人共用一个公网IP的环境下会经常弹出验证码, 对于我的FQ流量直接reset...
在CF的Firewall那一项里面调一下之后快到飞起...

求教是在CF的Firewall里调哪一项

voidiak on 19 Aug 2019

我找到根因了...
CloudFlare的默认防火墙限制有点严格, 在那种很多人共用一个公网IP的环境下会经常弹出验证码, 对于我的FQ流量直接reset...
在CF的Firewall那一项里面调一下之后快到飞起...

求教是在CF的Firewall里调哪一项

utmtl on 19 Aug 2019

👍29 ❤13

我找到根因了...
CloudFlare的默认防火墙限制有点严格, 在那种很多人共用一个公网IP的环境下会经常弹出验证码, 对于我的FQ流量直接reset...
在CF的Firewall那一项里面调一下之后快到飞起...

求教是在CF的Firewall里调哪一项

可以在Firewall rules里面添加一条Action为Allow规则, Field选IP(填你自己的IP)或者Path(v2ray服务的Path). 也可以在Tools里面的IP Access Rules添加一条你自己的IP选Whitelist. 还可以直接把settings里面的Security Level调成Essentially Off(这样会有被d的风险,不过一般不会发生). 亲测一起用效果最佳.

感谢！

voidiak on 19 Aug 2019

学习了

KinKir on 15 Oct 2019

亲测有效的！！之前看480P都卡，现在重回8k！

qiandog5324 on 2 Nov 2019

你好，遇到类似问题，请教下楼主。
上网方式websocket+tls+nginx+cdn
笔记本电脑连公司wifi，固定电信IP地址，经常不能访问Google，测试同时不能访问cloudflare，疑似公司固定IP地址被防火墙阻断。切换连接移动手机热点，正常访问Google和cloudflare。
使用楼主的方法，在防火漆规则里增加Allow规则，ip设置为公司固定ip地址。工具里添加公司固定ip地址为白名单。设置Security Level调成Essentially Off。公司wifi还是经常断网，不能访问外网。

callmepopo on 11 Nov 2019

连接公司wifi时设置dns为8.8.8.8 8.8.4.4 居然解决了

callmepopo on 11 Nov 2019

老哥问下，IP自动分配的话cloudflare那边防火墙该怎么改。。。

Inferior-Gentleman on 19 Nov 2019

Mark 一下，我被时不时不能使用的问题搞得不厌其烦，设备多，经常这个不能连，那个又能了，已经改了，试试能成不

Ryan-Shang on 20 Nov 2019

防火墙可以设置允许来自中国的所有IP，但是我发现断流与IP无关，与设备的DNS设置有关，改成8.8.8.8作为dns服务区，没有断流过了

Inferior-Gentleman notifications@github.com 于2019年11月19日周二下午8:41写道：

老哥问下，IP自动分配的话cloudflare那边防火墙该怎么改。。。

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

callmepopo on 26 Nov 2019

防火墙可以设置允许来自中国的所有IP，但是我发现断流与IP无关，与设备的DNS设置有关，改成8.8.8.8作为dns服务区，没有断流过了 Inferior-Gentleman notifications@github.com 于2019年11月19日周二下午8:41写道：
…

不同的dns解析出来的ip还能不一样吗？

forever8938 on 26 Nov 2019

我找到根因了...
CloudFlare的默认防火墙限制有点严格, 在那种很多人共用一个公网IP的环境下会经常弹出验证码, 对于我的FQ流量直接reset...
在CF的Firewall那一项里面调一下之后快到飞起...

求教是在CF的Firewall里调哪一项

可以在Firewall rules里面添加一条Action为Allow规则, Field选IP(填你自己的IP)或者Path(v2ray服务的Path). 也可以在Tools里面的IP Access Rules添加一条你自己的IP选Whitelist. 还可以直接把settings里面的Security Level调成Essentially Off(这样会有被d的风险,不过一般不会发生). 亲测一起用效果最佳.

感谢！

请问ip是填写自己的主机ip么，谢谢

whynotgithub on 29 Nov 2019

我找到根因了...
CloudFlare的默认防火墙限制有点严格, 在那种很多人共用一个公网IP的环境下会经常弹出验证码, 对于我的FQ流量直接reset...
在CF的Firewall那一项里面调一下之后快到飞起...

求教是在CF的Firewall里调哪一项

可以在Firewall rules里面添加一条Action为Allow规则, Field选IP(填你自己的IP)或者Path(v2ray服务的Path). 也可以在Tools里面的IP Access Rules添加一条你自己的IP选Whitelist. 还可以直接把settings里面的Security Level调成Essentially Off(这样会有被d的风险,不过一般不会发生). 亲测一起用效果最佳.

感谢！

请问ip是填写自己的主机ip么，谢谢

ip是填你本地客户端机器的ip

voidiak on 1 Dec 2019

我这里的情况确实是改掉dns 8888 8844 有一定效果

jmsht777 on 21 Dec 2019

我找到根因了...
CloudFlare的默认防火墙限制有点严格, 在那种很多人共用一个公网IP的环境下会经常弹出验证码, 对于我的FQ流量直接reset...
在CF的Firewall那一项里面调一下之后快到飞起...

求教是在CF的Firewall里调哪一项

可以在Firewall rules里面添加一条Action为Allow规则, Field选IP(填你自己的IP)或者Path(v2ray服务的Path). 也可以在Tools里面的IP Access Rules添加一条你自己的IP选Whitelist. 还可以直接把settings里面的Security Level调成Essentially Off(这样会有被d的风险,不过一般不会发生). 亲测一起用效果最佳.

感谢！

请问ip是填写自己的主机ip么，谢谢

ip是填你本地客户端机器的ip

是外网ip吗？

mike0902adf on 14 Jan 2020

我找到根因了...
CloudFlare的默认防火墙限制有点严格, 在那种很多人共用一个公网IP的环境下会经常弹出验证码, 对于我的FQ流量直接reset...
在CF的Firewall那一项里面调一下之后快到飞起...

求教是在CF的Firewall里调哪一项

可以在Firewall rules里面添加一条Action为Allow规则, Field选IP(填你自己的IP)或者Path(v2ray服务的Path). 也可以在Tools里面的IP Access Rules添加一条你自己的IP选Whitelist. 还可以直接把settings里面的Security Level调成Essentially Off(这样会有被d的风险,不过一般不会发生). 亲测一起用效果最佳.

自己的ip变化太多了，现在直接防火墙关了效果不错，之前一直以为bbr的原因

hunkkt on 8 Feb 2020

我找到根因了...
CloudFlare的默认防火墙限制有点严格, 在那种很多人共用一个公网IP的环境下会经常弹出验证码, 对于我的FQ流量直接reset...
在CF的Firewall那一项里面调一下之后快到飞起...

求教是在CF的Firewall里调哪一项

可以在Firewall rules里面添加一条Action为Allow规则, Field选IP(填你自己的IP)或者Path(v2ray服务的Path). 也可以在Tools里面的IP Access Rules添加一条你自己的IP选Whitelist. 还可以直接把settings里面的Security Level调成Essentially Off(这样会有被d的风险,不过一般不会发生). 亲测一起用效果最佳.

自己的ip变化太多了，现在直接防火墙关了效果不错，之前一直以为bbr的原因

CF免费版似乎不能完全关闭防火墙求教具体操作？

utmtl on 10 Feb 2020

mark

msghost on 22 Mar 2020

我找到根因了...
CloudFlare的默认防火墙限制有点严格, 在那种很多人共用一个公网IP的环境下会经常弹出验证码, 对于我的FQ流量直接reset...
在CF的Firewall那一项里面调一下之后快到飞起...

求教是在CF的Firewall里调哪一项

可以在Firewall rules里面添加一条Action为Allow规则, Field选IP(填你自己的IP)或者Path(v2ray服务的Path). 也可以在Tools里面的IP Access Rules添加一条你自己的IP选Whitelist. 还可以直接把settings里面的Security Level调成Essentially Off(这样会有被d的风险,不过一般不会发生). 亲测一起用效果最佳.

感谢似乎我遇到的也是这个情况，目前良好。

LianglRen on 31 May 2020

我找到根因了...
CloudFlare的默认防火墙限制有点严格, 在那种很多人共用一个公网IP的环境下会经常弹出验证码, 对于我的FQ流量直接reset...
在CF的Firewall那一项里面调一下之后快到飞起...

求教是在CF的Firewall里调哪一项

可以在Firewall rules里面添加一条Action为Allow规则, Field选IP(填你自己的IP)或者Path(v2ray服务的Path). 也可以在Tools里面的IP Access Rules添加一条你自己的IP选Whitelist. 还可以直接把settings里面的Security Level调成Essentially Off(这样会有被d的风险,不过一般不会发生). 亲测一起用效果最佳.

是的，这样是效果不错！感谢分享！