V2ray-core: V2Ray + WebSocket + TLS + CDN 几分钟左右就会出现一次断流

Created on 29 Jan 2020 · 45Comments · Source: v2ray/v2ray-core

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

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

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

3) 你看到的不正常的现象是什么？（请描述具体现象，比如访问超时，TLS 证书错误等）
V2Ray + WebSocket + TLS + CDN 大概从19年11月份开始，PC端我这边就开始频繁出现了断流现象了，现象大概2-5分钟后就会断流的情况，此时Chrome一般提示例如，xxx拒绝了我们的连接请求、访问超时、无响应等等。但奇怪的是V2RayN客户端这边，只要我点击“重启服务”，代理的连接又能恢复正常！如此反复。PS：其实自从11月份过后，不只我那台VPS服务器中的V2ray才会出现这种现象，SS也会，后面我换成了SSR，更改了加密方法、协议以及添加了混淆，SSR才躲过了此劫。但是我实在是想抢救一下V2ray啊，网上给出的解决方案搜遍了，除了换台VPS，其它方案我几乎都试过了，没用……

4) 你期待看到的正确表现是怎样的？
能正常稳定不断流的观看 YouTube 视频(*′▽｀)ノノ

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

服务器端配置:

    // 在这里附上服务器端配置文件
    {
    "log": {
        "access": "/var/log/v2ray/access.log",
        "error": "/var/log/v2ray/error.log",
        "loglevel": "warning"
    },
    "inbounds": [
        {
            "port": 2334,
            "protocol": "vmess",
            "settings": {
                "clients": [
                    {
                        "id": "88888888-8888-8888-8888-888888888888",
                        "level": 1,
                        "alterId": 233
                    }
                ]
            },
            "streamSettings": {
                "network": "ws"
            },
            "sniffing": {
                "enabled": true,
                "destOverride": [
                    "http",
                    "tls"
                ]
            }
        }
    ],
    "outbounds": [
        {
            "protocol": "freedom",
            "settings": {
                "domainStrategy": "UseIP"
            },
            "tag": "direct"
        },
        {
            "protocol": "blackhole",
            "settings": {},
            "tag": "blocked"
        },
        {
            "protocol": "mtproto",
            "settings": {},
            "tag": "tg-out"
        }
    ],
    "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",
                "protocol": [
                    "bittorrent"
                ],
                "outboundTag": "blocked"
            }
        ]
    },
    "transport": {
        "kcpSettings": {
            "uplinkCapacity": 100,
            "downlinkCapacity": 100,
            "congestion": true
        },
        "sockopt": {
            "tcpFastOpen": true
        }
    }

客户端配置:

    // 在这里附上客户端配置
    {
  "policy": {
    "system": {
      "statsInboundUplink": true,
      "statsInboundDownlink": true
    }
  },
  "log": {
    "access": "",
    "error": "",
    "loglevel": "warning"
  },
  "inbounds": [
    {
      "tag": "proxy",
      "port": 10808,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      },
      "settings": {
        "auth": "noauth",
        "udp": true,
        "ip": null,
        "address": null,
        "clients": null
      },
      "streamSettings": null
    },
    {
      "tag": "api",
      "port": 3355,
      "listen": "127.0.0.1",
      "protocol": "dokodemo-door",
      "sniffing": null,
      "settings": {
        "auth": null,
        "udp": false,
        "ip": null,
        "address": "127.0.0.1",
        "clients": null
      },
      "streamSettings": null
    }
  ],
  "outbounds": [
    {
      "tag": "proxy",
      "protocol": "vmess",
      "settings": {
        "vnext": [
          {
            "address": "www.prprprpr.top",
            "port": 443,
            "users": [
              {
                "id": "88888888-8888-8888-8888-888888888888",
                "alterId": 10,
                "email": "[email protected]",
                "security": "auto"
              }
            ]
          }
        ],
        "servers": null,
        "response": null
      },
      "streamSettings": {
        "network": "ws",
        "security": "tls",
        "tlsSettings": {
          "allowInsecure": true,
          "serverName": "www.prprprpr.top"
        },
        "tcpSettings": null,
        "kcpSettings": null,
        "wsSettings": {
          "connectionReuse": true,
          "path": "/233blog",
          "headers": {
            "Host": "www.prprprpr.top"
          }
        },
        "httpSettings": null,
        "quicSettings": null
      },
      "mux": {
        "enabled": false
      }
    },
    {
      "tag": "direct",
      "protocol": "freedom",
      "settings": {
        "vnext": null,
        "servers": null,
        "response": null
      },
      "streamSettings": null,
      "mux": null
    },
    {
      "tag": "block",
      "protocol": "blackhole",
      "settings": {
        "vnext": null,
        "servers": null,
        "response": {
          "type": "http"
        }
      },
      "streamSettings": null,
      "mux": null
    }
  ],
  "stats": {},
  "api": {
    "tag": "api",
    "services": [
      "StatsService"
    ]
  },
  "dns": null,
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "port": null,
        "inboundTag": [
          "api"
        ],
        "outboundTag": "api",
        "ip": null,
        "domain": null
      }
    ]
  }
}

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

服务器端错误日志:

    // 在这里附上服务器端日志
2020/01/28 21:29:47 [Info] [1166531346] v2ray.com/core/proxy/vmess/inbound: received request for tcp:r3---sn-q4flrn7r.googlevideo.com:443
2020/01/28 21:29:47 [Info] [1166531346] v2ray.com/core/app/dispatcher: sniffed domain: r3---sn-q4flrn7r.googlevideo.com
2020/01/28 21:29:47 [Debug] v2ray.com/core/app/dns: DOHL//1.1.1.1 cache HIT r3---sn-q4flrn7r.googlevideo.com -> [2607:f8b0:4000:3e::8 209.85.165.104]
2020/01/28 21:29:47 [Info] [1166531346] v2ray.com/core/app/dispatcher: default route for tcp:r3---sn-q4flrn7r.googlevideo.com:443
2020/01/28 21:29:47 [Info] [1166531346] v2ray.com/core/proxy/freedom: opening connection to tcp:r3---sn-q4flrn7r.googlevideo.com:443
2020/01/28 21:29:47 [Debug] v2ray.com/core/app/dns: DOHL//1.1.1.1 cache HIT r3---sn-q4flrn7r.googlevideo.com -> [2607:f8b0:4000:3e::8 209.85.165.104]
2020/01/28 21:29:47 [Info] [1166531346] v2ray.com/core/proxy/freedom: dialing to to tcp:209.85.165.104:443
2020/01/28 21:29:47 [Info] [1166531346] v2ray.com/core/transport/internet/tcp: dialing TCP to tcp:209.85.165.104:443
2020/01/28 21:30:00 [Info] [3465548588] v2ray.com/core/proxy/vmess/inbound: received request for tcp:r3---sn-q4flrn7r.googlevideo.com:443
2020/01/28 21:30:00 [Info] [3465548588] v2ray.com/core/app/dispatcher: sniffed domain: r3---sn-q4flrn7r.googlevideo.com
2020/01/28 21:30:00 [Debug] v2ray.com/core/app/dns: DOHL//1.1.1.1 cache HIT r3---sn-q4flrn7r.googlevideo.com -> [2607:f8b0:4000:3e::8 209.85.165.104]
2020/01/28 21:30:00 [Info] [3465548588] v2ray.com/core/app/dispatcher: default route for tcp:r3---sn-q4flrn7r.googlevideo.com:443
2020/01/28 21:30:00 [Info] [3465548588] v2ray.com/core/proxy/freedom: opening connection to tcp:r3---sn-q4flrn7r.googlevideo.com:443
2020/01/28 21:30:00 [Debug] v2ray.com/core/app/dns: DOHL//1.1.1.1 cache HIT r3---sn-q4flrn7r.googlevideo.com -> [2607:f8b0:4000:3e::8 209.85.165.104]
2020/01/28 21:30:00 [Info] [3465548588] v2ray.com/core/proxy/freedom: dialing to to tcp:209.85.165.104:443
2020/01/28 21:30:00 [Info] [3465548588] v2ray.com/core/transport/internet/tcp: dialing TCP to tcp:209.85.165.104:443
2020/01/28 21:30:16 [Info] [1049517251] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/vmess/inbound: connection ends > context canceled
2020/01/28 21:30:16 [Info] [1049517251] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/freedom: connection ends > context canceled
2020/01/28 21:30:18 [Info] [544519331] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/freedom: connection ends > context canceled
2020/01/28 21:30:18 [Info] [544519331] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/vmess/inbound: connection ends > context canceled
2020/01/28 21:30:29 [Info] [1166531346] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/freedom: connection ends > context canceled
2020/01/28 21:30:29 [Info] [1166531346] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/vmess/inbound: connection ends > context canceled
2020/01/28 21:30:32 [Info] [3465548588] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/vmess/inbound: connection ends > context canceled
2020/01/28 21:30:32 [Info] [3465548588] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/freedom: connection ends > context canceled
2020/01/28 21:31:16 [Info] [922327696] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/vmess/inbound: connection ends > v2ray.com/core/proxy/vmess/inbound: failed to transfer request > websocket: close 1006 (abnormal closure): unexpected EOF
2020/01/28 21:31:16 [Info] [922327696] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/freedom: connection ends > context canceled
2020/01/28 21:31:20 [Info] [3559423309] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/vmess/inbound: connection ends > v2ray.com/core/proxy/vmess/inbound: failed to transfer request > websocket: close 1006 (abnormal closure): unexpected EOF
2020/01/28 21:31:20 [Info] [3559423309] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/freedom: connection ends > context canceled

客户端错误日志:

    // 在这里附上客户端日志
2020/01/28 21:29:14 [Info] [1573699911] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r3---sn-a5meknsy.googlevideo.com:443
2020/01/28 21:29:14 [Info] [1573699911] v2ray.com/core/app/dispatcher: sniffed domain: r3---sn-a5meknsy.googlevideo.com
2020/01/28 21:29:14 [Info] [1573699911] v2ray.com/core/app/dispatcher: default route for tcp:r3---sn-a5meknsy.googlevideo.com:443
2020/01/28 21:29:14 [Info] [1573699911] v2ray.com/core/transport/internet/websocket: creating connection to tcp:www.liitokala.top:443
2020/01/28 21:29:14 [Info] [1573699911] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r3---sn-a5meknsy.googlevideo.com:443 via tcp:www.liitokala.top:443
2020/01/28 21:29:17 [Info] [4024490750] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > write tcp 127.0.0.1:10808->127.0.0.1:3943: wsasend: An established connection was aborted by the software in your host machine.
2020/01/28 21:29:17 [Info] [4024490750] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2020/01/28 21:29:17 [Info] [275774822] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r3---sn-a5meknsy.googlevideo.com:443
2020/01/28 21:29:17 [Info] [275774822] v2ray.com/core/app/dispatcher: sniffed domain: r3---sn-a5meknsy.googlevideo.com
2020/01/28 21:29:17 [Info] [275774822] v2ray.com/core/app/dispatcher: default route for tcp:r3---sn-a5meknsy.googlevideo.com:443
2020/01/28 21:29:17 [Info] [275774822] v2ray.com/core/transport/internet/websocket: creating connection to tcp:www.liitokala.top:443
2020/01/28 21:29:17 [Info] [1590353343] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2020/01/28 21:29:17 [Info] [1590353343] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2020/01/28 21:29:20 [Info] [275774822] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r3---sn-a5meknsy.googlevideo.com:443 via tcp:www.liitokala.top:443
2020/01/28 21:29:21 [Info] [275774822] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > websocket: close 1000 (normal)
2020/01/28 21:29:21 [Info] [275774822] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
2020/01/28 21:29:22 [Info] [3603502193] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r3---sn-a5meknsy.googlevideo.com:443
2020/01/28 21:29:22 [Info] [3603502193] v2ray.com/core/app/dispatcher: sniffed domain: r3---sn-a5meknsy.googlevideo.com
2020/01/28 21:29:22 [Info] [3603502193] v2ray.com/core/app/dispatcher: default route for tcp:r3---sn-a5meknsy.googlevideo.com:443
2020/01/28 21:29:22 [Info] [3603502193] v2ray.com/core/transport/internet/websocket: creating connection to tcp:www.liitokala.top:443
2020/01/28 21:29:23 [Info] [3603502193] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r3---sn-a5meknsy.googlevideo.com:443 via tcp:www.liitokala.top:443
2020/01/28 21:29:26 [Info] [608692290] v2ray.com/core/proxy/socks: TCP Connect request to tcp:clients4.google.com:443
2020/01/28 21:29:26 [Info] [608692290] v2ray.com/core/app/dispatcher: sniffed domain: clients4.google.com
2020/01/28 21:29:26 [Info] [608692290] v2ray.com/core/app/dispatcher: default route for tcp:clients4.google.com:443
2020/01/28 21:29:26 [Info] [608692290] v2ray.com/core/transport/internet/websocket: creating connection to tcp:www.liitokala.top:443
2020/01/28 21:29:33 [Info] [608692290] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:clients4.google.com:443 via tcp:www.liitokala.top:443
2020/01/28 21:29:37 [Info] [3952348604] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r3---sn-a5meknsy.googlevideo.com:443
2020/01/28 21:29:37 [Info] [3952348604] v2ray.com/core/app/dispatcher: sniffed domain: r3---sn-a5meknsy.googlevideo.com
2020/01/28 21:29:37 [Info] [3952348604] v2ray.com/core/app/dispatcher: default route for tcp:r3---sn-a5meknsy.googlevideo.com:443
2020/01/28 21:29:37 [Info] [3952348604] v2ray.com/core/transport/internet/websocket: creating connection to tcp:www.liitokala.top:443
2020/01/28 21:29:38 [Info] [3603502193] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2020/01/28 21:29:38 [Info] [3603502193] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2020/01/28 21:29:39 [Info] [3952348604] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r3---sn-a5meknsy.googlevideo.com:443 via tcp:www.liitokala.top:443
2020/01/28 21:29:46 [Info] [338633586] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r3---sn-q4flrn7r.googlevideo.com:443
2020/01/28 21:29:46 [Info] [338633586] v2ray.com/core/app/dispatcher: sniffed domain: r3---sn-q4flrn7r.googlevideo.com
2020/01/28 21:29:46 [Info] [338633586] v2ray.com/core/app/dispatcher: default route for tcp:r3---sn-q4flrn7r.googlevideo.com:443
2020/01/28 21:29:46 [Info] [338633586] v2ray.com/core/transport/internet/websocket: creating connection to tcp:www.liitokala.top:443
2020/01/28 21:29:46 [Info] [338633586] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r3---sn-q4flrn7r.googlevideo.com:443 via tcp:www.liitokala.top:443
2020/01/28 21:29:56 [Info] [2940880730] v2ray.com/core/proxy/socks: TCP Connect request to tcp:r3---sn-q4flrn7r.googlevideo.com:443
2020/01/28 21:29:56 [Info] [2940880730] v2ray.com/core/app/dispatcher: sniffed domain: r3---sn-q4flrn7r.googlevideo.com
2020/01/28 21:29:56 [Info] [2940880730] v2ray.com/core/app/dispatcher: default route for tcp:r3---sn-q4flrn7r.googlevideo.com:443
2020/01/28 21:29:56 [Info] [2940880730] v2ray.com/core/transport/internet/websocket: creating connection to tcp:www.liitokala.top:443
2020/01/28 21:29:59 [Info] [2940880730] v2ray.com/core/proxy/vmess/outbound: tunneling request to tcp:r3---sn-q4flrn7r.googlevideo.com:443 via tcp:www.liitokala.top:443
2020/01/28 21:30:16 [Info] [3952348604] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2020/01/28 21:30:16 [Info] [3952348604] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2020/01/28 21:30:17 [Info] [1573699911] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2020/01/28 21:30:17 [Info] [1573699911] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2020/01/28 21:30:28 [Info] [338633586] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2020/01/28 21:30:28 [Info] [338633586] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2020/01/28 21:30:33 [Info] [2940880730] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > context canceled
2020/01/28 21:30:33 [Info] [2940880730] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > context canceled
2020/01/28 21:31:17 [Info] [608692290] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > websocket: close 1006 (abnormal closure): unexpected EOF
2020/01/28 21:31:17 [Info] [608692290] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > io: read/write on closed pipe
2020/01/28 21:31:26 [Info] [2037111749] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/vmess/outbound: connection ends > websocket: close 1006 (abnormal closure): unexpected EOF
2020/01/28 21:31:26 [Info] [2037111749] v2ray.com/core/app/proxyman/inbound: connection ends > v2ray.com/core/proxy/socks: connection ends > v2ray.com/core/proxy/socks: failed to transport all TCP response > io: read/write on closed pipe

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

    // 在这里附上服务器端日志
2019/08/05 21:29:47 117.44.140.68:14040 accepted tcp:mtalk.google.com:5228 
2019/08/05 21:33:52 117.44.140.68:36186 accepted udp:8.8.4.4:53 
2019/08/05 21:34:48 117.44.140.68:14318 accepted tcp:mtalk.google.com:5228 
2019/08/05 21:35:21 117.44.140.68:36190 accepted udp:8.8.4.4:53 
2019/08/05 21:38:21 117.44.140.68:36192 accepted udp:8.8.4.4:53 
2019/08/05 21:38:58 117.44.140.68:14517 accepted tcp:clients1.google.com:443 
2019/08/05 21:39:48 117.44.140.68:14541 accepted tcp:mtalk.google.com:5228 
2019/08/05 21:44:50 117.44.140.68:14965 accepted tcp:mtalk.google.com:5228 
2019/08/05 21:45:51 117.44.140.68:36200 rejected  v2ray.com/core/proxy/vmess/encoding: failed to read request header > websocket: close 1000 (normal)
2019/08/05 21:45:52 117.44.140.68:36202 accepted udp:8.8.8.8:53 
2019/08/05 21:45:52 117.44.140.68:36204 accepted tcp:p53-imap.mail.me.com:993 
2019/08/05 21:45:53 117.44.140.68:36210 accepted udp:8.8.4.4:53 
2019/08/05 21:45:54 117.44.140.68:36208 accepted tcp:p53-imap.mail.me.com:993 
2019/08/05 21:45:56 117.44.140.68:36214 accepted udp:8.8.4.4:53 
2019/08/05 21:47:24 117.44.140.68:36216 accepted udp:8.8.8.8:53 
2019/08/05 21:47:24 117.44.140.68:36220 accepted tcp:p53-imap.mail.me.com:993 
2019/08/05 21:47:25 117.44.140.68:36224 accepted tcp:safebrowsing.googleapis.com:443 
2019/08/05 21:47:25 117.44.140.68:36228 accepted tcp:p53-imap.mail.me.com:993 
2019/08/05 21:47:28 117.44.140.68:36218 rejected  v2ray.com/core/proxy/vmess/encoding: failed to read request header > websocket: close 1006 (abnormal closure): unexpected EOF
2019/08/05 21:47:28 117.44.140.68:36232 accepted udp:8.8.4.4:53

Stale

Source

Leeray-Lau

Most helpful comment

我最近也遇到了“断流”，只要我坐到窗户边工作，就会偶尔出现这个问题，但坐在床边就没有问题了。

kslr on 3 Feb 2020

😄24 👍2 😕1

All 45 comments

有沒有試過用手機客戶端連接？例如shadowrocket之類的，如果手機客戶端連接正常，那就能排除問題出在v2ray身上了，是PC客戶端的問題。

我也是在用你這個設置，套了CDN，我把VPN借了給大陸親戚，平時他不看牆外新聞的，可能是疫情關係，這個1月他忽然就看上了癮，我親戚看了40GB的YouTube 流量也沒聽見他說有甚麼封鎖斷流。(他用手機shadowrocket連接我的VPN)

cwyin7788 on 29 Jan 2020

@i553041
1.我试过IOS版的V2ray客户端：kitsunebi，结论是断流现象似乎确实好很多。没有那么频繁了。PS：kitsunebi似乎有断连重连的功能。因此即使手机端这边表现稍微正常一些了。我也不能用排除法断定即是PC客户端这边的问题了。

2.Windows10这边，除了V2RayN，我还测试了其他的GUI客户端，比如qv2ray、V2RayW。结论是同样会出现几分钟后就会断流的现象。

3.我也尝试过HTTP2协议、KCP协议（不套CDN），在PC端这边均会出现断流现象。

Leeray-Lau on 29 Jan 2020

你可以首先测试本地网络是否稳定

kslr on 29 Jan 2020

你可以首先测试本地网络是否稳定

@kslr
本地网络…唔...应该是稳定的，家里200M电信光纤电脑连接的是网线。断流现象和在学校时的表现一样，目前访问国内的视频站均没有出现任何网络不稳定现象_(:_」∠)_。

Leeray-Lau on 29 Jan 2020

@i553041
1.我试过IOS版的V2ray客户端：kitsunebi，结论是断流现象似乎确实好很多。没有那么频繁了。PS：kitsunebi似乎有断连重连的功能。因此即使手机端这边表现稍微正常一些了。我也不能用排除法断定即是PC客户端这边的问题了。

2.Windows10这边，除了V2RayN，我还测试了其他的GUI客户端，比如qv2ray、V2RayW。结论是同样会出现几分钟后就会断流的现象。

3.我也尝试过HTTP2协议、KCP协议（不套CDN），在PC端这边均会出现断流现象。

PS：kitsunebi似乎有断连重连的功能。＜－－－如何得知有這個功能呢？

會不會是DNS被干擾呢？我見你的access.log有些8.8.8.8:53的請求，我的access.log是沒有這些的，我沒有自定DNS，猜想㑹不㑹是這個原因？

cwyin7788 on 29 Jan 2020

@i553041
1.关于kitsunebi断连重连的功能，在软件的“更多”一栏里面，之前我有在twitter关注过这个作者一段时间，因为经常有用户反映kitsunebi断流的问题，可能由于IOS设备的特殊性吧，我将iPhone息屏后，再次打开，kitsunebi在状态一栏显示的“已连接”计时，每次时间都被重置了，重新从00:00开始计时。

2.然后是关于DNS，8.8.8.8和8.8.4.4不是Google提供的免费DNS服务器的IP地址么……

Leeray-Lau on 29 Jan 2020

@i553041
1.关于kitsunebi断连重连的功能，在软件的“更多”一栏里面，之前我有在twitter关注过这个作者一段时间，因为经常有用户反映kitsunebi断流的问题，可能由于IOS设备的特殊性吧，我将iPhone息屏后，再次打开，kitsunebi在状态一栏显示的“已连接”计时，每次时间都被重置了，重新从00:00开始计时。

2.然后是关于DNS，8.8.8.8和8.8.4.4不是Google提供的免费DNS服务器的IP地址么……

DNS方面，是我思路上想錯了，請忽略。

或者你試試我現在使用正常的設置，看有沒有幫助吧，你只需將現時的設定檔改個名，試一下我的設定檔而已，我這個設定檔很正常，一直使用了好幾個月了。

我曾經在這裡開過一個issue，後來證實是客戶端問題，不關v2ray的事，下面連結有我的設定檔，改一點配置試試看吧。

https://github.com/v2ray/v2ray-core/issues/2073

cwyin7788 on 29 Jan 2020

@i553041
感谢回复。

刚刚我又测了下IOS版的v2ray客户端，把“自动重连”功能关闭了，观看youtube视频1个小时，发现没有出现任何断流的现象。“已连接”计时的时间也没有被重置。

似乎问题只出现在windows端啊，奇怪了。V2ray的配置我从搭建至今就没怎么改过。从2019年11月份左右开始才出现的断流现象，唯一变就是更新了window10系统，更新了v2ray-windows-64-Core，以及更新了v2rayN。

Leeray-Lau on 29 Jan 2020

CDN节点丢包率如何？如果丢包率很高，只有出国才能正常稳定高速。

forever8938 on 30 Jan 2020

CDN节点丢包率如何？如果丢包率很高，只有出国才能正常稳定高速。

@forever8938
我尝试过不使用CDN，结果是依旧几分钟后会断流(￣ェ￣;)

Leeray-Lau on 30 Jan 2020

会不会是 windows 端时间设置的问题

DolorHunter on 30 Jan 2020

会不会是 windows 端时间设置的问题

@DolorHunter
测了VPS linux上的时间，和windows端的一样〒▽〒

Leeray-Lau on 30 Jan 2020

T T我也遇到了相同的问题，配置基本相同，只不过我没有使用CDN。
尝试过在nginx修改超时时长，但仍然断流。

NiceBowl335 on 31 Jan 2020

exactly same here

emiyalee1005 on 2 Feb 2020

websocket: close 1006，连接被断开，你改成其他模式试一下，比如说TCP。
或者去掉TLS尝试下，不要加密网页，不然运营商不好识别流量策略，这个应该是当地运营商做了什么超时策略，强行断开原因导致。
毕竟安卓端和PC端实现方式原理都不一样，安卓是VPN式，创建一个虚拟网卡通道，Windows是代理式，感觉应该有不同的实现方案。
如果真是运营商搞的话，或者用TCP可以让运营商检测为游戏流量，就不会断开了

1265578519 on 2 Feb 2020

websocket: close 1006，连接被断开，你改成其他模式试一下，比如说TCP。
或者去掉TLS尝试下，不要加密网页，不然运营商不好识别流量策略，这个应该是当地运营商做了什么超时策略，强行断开原因导致。
毕竟安卓端和PC端实现方式原理都不一样，安卓是VPN式，创建一个虚拟网卡通道，Windows是代理式，感觉应该有不同的实现方案。
如果真是运营商搞的话，或者用TCP可以让运营商检测为游戏流量，就不会断开了

@kslr @1265578519
(Ｔ▽Ｔ)救救我啊大佬们！！就在2月1号左右，我的VPS IP被墙了，所以现在v2ray其他模式我也没的选择了，必须使用ws+tls+cdn转发才行了……

然后经过我这几天的测试发现，我的V2ray断流情况，目前只在我频繁使用的这台笔记本Win10系统环境下才会呈现。而V2ray同样的配置、版本。我均在路由器上、WindowsSandbox、VM虚拟机、IOS端、另外一台Win7电脑上测试了一遍，结果令人大跌眼镜，都不会断流！！太玄学了吧？难道墙还能精确识别到你常用的设备，然后给你强行断开不成？或者换句话说，难道我经常上网的设备有比较明显、固定的流量特征不成？

PS：
1.VM虚拟机使用的Win10系统内核版本和笔记本真实环境下的一致
2.上述测试的多个不同环境下的V2ray客户端，在笔记本V2ray客户端出现断流的情况之后，不影响其他设备的V2ray客户端的正常使用，均连接正常。

Leeray-Lau on 3 Feb 2020

我最近也遇到了“断流”，只要我坐到窗户边工作，就会偶尔出现这个问题，但坐在床边就没有问题了。

kslr on 3 Feb 2020

😄24 👍2 😕1

CN2-GIA从来不断流

forever8938 on 3 Feb 2020

我最近也遇到了“断流”，只要我坐到窗户边工作，就会偶尔出现这个问题，但坐在床边就没有问题了。

@kslr
因...因吹斯汀(눈‸눈)

Leeray-Lau on 3 Feb 2020

你试试sstap吧，添加一个sock5服务器，127.0.0.1 10808，v2rayn客户端上设置关闭http代理，直接用看看有没有问题

1265578519 on 3 Feb 2020

你试试sstap吧，添加一个sock5服务器，127.0.0.1 10808，v2rayn客户端上设置关闭http代理，直接用看看有没有问题

@1265578519 刚才试了，不行，还是会断……

Leeray-Lau on 3 Feb 2020

那应该就不是系统上客户端的毛病了，流量被运营商卡擦了，要不然你换个IP直接用TCP模式吧

1265578519 on 3 Feb 2020

那应该就不是系统上客户端的毛病了，流量被运营商卡擦了，要不然你换个IP直接用TCP模式吧

可奇怪的是除了我的笔记本会出现这个问题以外，其余上述提到的任何一种环境均不会出现这个问题。如果是VPS的IP被“关照”了，那所有的环境都应该都一视同仁才对啊，我找不到其他原因了……

Leeray-Lau on 3 Feb 2020

那应该就不是系统上客户端的毛病了，流量被运营商卡擦了，要不然你换个IP直接用TCP模式吧

可奇怪的是除了我的笔记本会出现这个问题以外，其余上述提到的任何一种环境均不会出现这个问题。如果是VPS的IP被“关照”了，那所有的环境都应该都一视同仁才对啊，我找不到其他原因了……

你是用TLS 1.2還是1.3？還是2者都在使用？㑹不㑹是你只用TLS 1.3而Windows客戶端對該協定的支持度還不太穩定？

cwyin7788 on 4 Feb 2020

@i553041 已经解决了，就是我这台笔记本Win10操作系统的问题。具体原因不知道，不过我排查以及重置了系统一堆的配置，刚好碰巧给解决了，实在是太玄学了(ಥ_ಥ) ……

后续补充几句，给遇到同样问题的童鞋提供一个思路，虽然怎么解决的具体原因仍然不清楚，但当时我是这样操作的：

1.重置了IE的配置
2.重置了LSP和清理了DNS缓存
3.我结束了QQProtect进程
（还有一些我认为无关紧要的操作，我就不列举出来了）

这个时候我用火绒自定义防护功能监视了v2ray的文件夹，并用火绒剑开启了日志监控，看看是谁在访问v2ray（但这次没有逮到QQProtect）

经过上面的步骤后，我重启电脑，V2ray恢复正常了，虽然QQProtect也照常开机启动，但V2ray确实是恢复正常了，不确定QQProtect.exe是否有反侦探手段。

PS：关于第3点，我为什么会怀疑是QQProtect.exe捣的鬼呢，因为腾讯的名声向来就不太好，比如利用这个QQProtect.exe进程病毒式的植入广告、或者利用游戏的 TenProtect扫描用户SSR、V2ray等、具体这个 TenProtect和聊天工具的 QQProtect 有没有共用一套信息收集逻辑就不得而知了，我当时没有逮到。腾讯的这些骚操作，早有用户反映过了，网上都是可以查到的，链接：国服游戏收集用户数据读取酸酸乳配置信息

反正我大致上这样操作了之后就解决了间歇性断流问题了。

Leeray-Lau on 4 Feb 2020

👍1

@i553041 已经解决了，就是我这台笔记本Win10操作系统的问题。具体原因不知道，不过我排查以及重置了系统一堆的配置，刚好碰巧给解决了，实在是太玄学了(ಥ_ಥ) ……

后续补充几句，给遇到同样问题的童鞋提供一个思路，虽然怎么解决的具体原因仍然不清楚，但当时我是这样操作的：

1.重置了IE的配置
2.重置了LSP和清理了DNS缓存
3.结束了QQProtect进程，并用火绒自定义防护功能监视了v2ray的文件夹

PS：关于第3点，我为什么会怀疑QQProtect.exe捣的鬼呢，因为腾讯的名声向来就不太好，比如利用这个QQProtect.exe进程病毒式的植入广告、或者利用游戏的 TenProtect扫描用户SSR、V2ray等、具体这个 TenProtect和聊天工具的 QQProtect 有没有共用一套信息收集逻辑就不得而知了，我当时没有逮到。腾讯的这些骚操作，早有用户反映过了，网上都是可以查到的
国服游戏收集用户数据读取酸酸乳配置信息
反正我大致上是这样操作了之后就解决了间歇性断流问题了。

那QQ怎么开？

missmuxixi on 11 Feb 2020

原来是火绒的锅

1265578519 on 11 Feb 2020

原来是火绒的锅

@1265578519
(ಥ_ಥ) 可能我写的让你有点误会，上面的意思是“腾讯的锅”，但我也不能确定。

Leeray-Lau on 11 Feb 2020

@i553041 已经解决了，就是我这台笔记本Win10操作系统的问题。具体原因不知道，不过我排查以及重置了系统一堆的配置，刚好碰巧给解决了，实在是太玄学了(ಥ_ಥ) ……
后续补充几句，给遇到同样问题的童鞋提供一个思路，虽然怎么解决的具体原因仍然不清楚，但当时我是这样操作的：
1.重置了IE的配置
2.重置了LSP和清理了DNS缓存
3.结束了QQProtect进程，并用火绒自定义防护功能监视了v2ray的文件夹
PS：关于第3点，我为什么会怀疑QQProtect.exe捣的鬼呢，因为腾讯的名声向来就不太好，比如利用这个QQProtect.exe进程病毒式的植入广告、或者利用游戏的 TenProtect扫描用户SSR、V2ray等、具体这个 TenProtect和聊天工具的 QQProtect 有没有共用一套信息收集逻辑就不得而知了，我当时没有逮到。腾讯的这些骚操作，早有用户反映过了，网上都是可以查到的
国服游戏收集用户数据读取酸酸乳配置信息
反正我大致上是这样操作了之后就解决了间歇性断流问题了。

那QQ怎么开？

@missmuxixi
如果你遇到跟我同样问题的话，可以尝试上面提到的方案。没有的话QQ照常开。我只是说有这种可能性，我也无法再次复现之前的那样的v2ray间歇性断流的场景……

PS：现在用了一个多礼拜了，V2Ray + WebSocket + TLS + CDN，稳的一B……

Leeray-Lau on 11 Feb 2020

应该不是QQ的锅，我有一台电脑的QQ和V2ray基本都是24小时开着的，没有出现这个问题。不过受你的启发，我还是使用win10自带的安全软件，添加了“受保护的文件夹”。

On Tue, Feb 11, 2020 at 10:15 PM Leeray-Lau notifications@github.com
wrote:

@i553041 https://github.com/i553041
已经解决了，就是我这台笔记本Win10操作系统的问题。具体原因不知道，不过我排查以及重置了系统一堆的配置，刚好碰巧给解决了，实在是太玄学了(ಥ_ಥ)
……
后续补充几句，给遇到同样问题的童鞋提供一个思路，虽然怎么解决的具体原因仍然不清楚，但当时我是这样操作的：
1.重置了IE的配置
2.重置了LSP和清理了DNS缓存
3.结束了QQProtect进程，并用火绒自定义防护功能监视了v2ray的文件夹
PS：关于第3点，我为什么会怀疑QQProtect.exe捣的鬼呢，因为腾讯的名声向来就不太好，比如利用这个QQProtect.exe进程病毒式的植入广告、或者利用游戏的
TenProtect扫描用户SSR、V2ray等、具体这个 TenProtect和聊天工具的 QQProtect
有没有共用一套信息收集逻辑就不得而知了，我当时没有逮到。腾讯的这些骚操作，早有用户反映过了，网上都是可以查到的
国服游戏收集用户数据读取酸酸乳配置信息
https://laod.cn/black-technology/hips-tengxun-s-s.html
反正我大致上是这样操作了之后就解决了间歇性断流问题了。

那QQ怎么开？

如果你遇到跟我同样问题的话，可以尝试上面提到的方案。没有的话QQ照常开。我只是说有这种可能性，我也无法再次复现之前的那样的v2ray间歇性断流的场景……

PS：现在用了一个多礼拜了，V2Ray + WebSocket + TLS + CDN，稳的一B……

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

qingfengshi on 12 Feb 2020

应该不是QQ的锅，我有一台电脑的QQ和V2ray基本都是24小时开着的，没有出现这个问题。不过受你的启发，我还是使用win10自带的安全软件，添加了“受保护的文件夹”。
…
On Tue, Feb 11, 2020 at 10:15 PM Leeray-Lau @.*> wrote: @i553041 https://github.com/i553041 已经解决了，就是我这台笔记本Win10操作系统的问题。具体原因不知道，不过我排查以及重置了系统一堆的配置，刚好碰巧给解决了，实在是太玄学了(ಥ_ಥ) …… 后续补充几句，给遇到同样问题的童鞋提供一个思路，虽然怎么解决的具体原因仍然不清楚，但当时我是这样操作的： 1.重置了IE的配置 2.重置了LSP和清理了DNS缓存 3.结束了QQProtect进程，并用火绒自定义防护功能监视了v2ray的文件夹 PS：关于第3点，我为什么会怀疑QQProtect.exe捣的鬼呢，因为腾讯的名声向来就不太好，比如利用这个QQProtect.exe进程病毒式的植入广告、或者利用游戏的 TenProtect扫描用户SSR、V2ray等、具体这个 TenProtect和聊天工具的 QQProtect 有没有共用一套信息收集逻辑就不得而知了，我当时没有逮到。腾讯的这些骚操作，早有用户反映过了，网上都是可以查到的国服游戏收集用户数据读取酸酸乳配置信息 https://laod.cn/black-technology/hips-tengxun-s-s.html 反正我大致上是这样操作了之后就解决了间歇性断流问题了。那QQ怎么开？如果你遇到跟我同样问题的话，可以尝试上面提到的方案。没有的话QQ照常开。我只是说有这种可能性，我也无法再次复现之前的那样的v2ray间歇性断流的场景…… PS：现在用了一个多礼拜了，V2Ray + WebSocket + TLS + CDN，稳的一B…… — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2198?email_source=notifications&email_token=AE34YTFHSIGRCHWSZAC5RLLRCKXG5A5CNFSM4KM7S6SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELMSBEQ#issuecomment-584654994>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE34YTHN6FCMPWNDAWBAWO3RCKXG5ANCNFSM4KM7S6SA .

我把那个qqprotect 关了还真就不断了。。。我也是服了

blackforest1840 on 27 Feb 2020

@i553041 已经解决了，就是我这台笔记本Win10操作系统的问题。具体原因不知道，不过我排查以及重置了系统一堆的配置，刚好碰巧给解决了，实在是太玄学了(ಥ_ಥ) ……
后续补充几句，给遇到同样问题的童鞋提供一个思路，虽然怎么解决的具体原因仍然不清楚，但当时我是这样操作的：
1.重置了IE的配置
2.重置了LSP和清理了DNS缓存
3.结束了QQProtect进程，并用火绒自定义防护功能监视了v2ray的文件夹
PS：关于第3点，我为什么会怀疑QQProtect.exe捣的鬼呢，因为腾讯的名声向来就不太好，比如利用这个QQProtect.exe进程病毒式的植入广告、或者利用游戏的 TenProtect扫描用户SSR、V2ray等、具体这个 TenProtect和聊天工具的 QQProtect 有没有共用一套信息收集逻辑就不得而知了，我当时没有逮到。腾讯的这些骚操作，早有用户反映过了，网上都是可以查到的
国服游戏收集用户数据读取酸酸乳配置信息
反正我大致上是这样操作了之后就解决了间歇性断流问题了。

那QQ怎么开？

@missmuxixi
如果你遇到跟我同样问题的话，可以尝试上面提到的方案。没有的话QQ照常开。我只是说有这种可能性，我也无法再次复现之前的那样的v2ray间歇性断流的场景……

PS：现在用了一个多礼拜了，V2Ray + WebSocket + TLS + CDN，稳的一B……

建议进一步关掉alibaba protect，刚发现的和qqprotect 性质一样

blackforest1840 on 27 Feb 2020

@blackforest1840
你的断流问题解决了嘛？

不过最近的Cloudflare CDN是真的慢啊，估计用来搭梯子的人多了……

Leeray-Lau on 27 Feb 2020

@Leeray-Lau 建议用备案域名百度云加速，国内的速度快，好了，，此贴终结，可以关闭了

1265578519 on 27 Feb 2020

我linux也会有断

kmvan on 22 Mar 2020

请问断流指的是什么？指的是断几秒，然后突然爆发式地暴涨一下吗？像是0kbps 0kbps ... 30Mbps 0kbps 这样的？谢谢！

LiJiasen-00921 on 18 May 2020

我之前也是这种状况但是把域名的dns解析到提供商提供的dns（不是用cdn）以后问题解决了，我也不知道是什么原因如果有知道的可以说一声。谢谢

fengbj-web on 5 Jun 2020

可以参考https://github.com/v2ray/v2ray-core/issues/1742
把CDN（或DNS服务商）的防火墙设置改一下就解决了。

Dante-y on 9 Jun 2020

好像是pc端有问题，手机端v2rayNg就没问题。

FunAomi on 19 Jun 2020

我的最近也开始断了，但是有一点不同的是我的v2ray添加了5个不同地点的节点，只要一个Tcping不通其他的都不通,过几分钟又恢复了，所有这些现象在安卓手机上没有出现过

qq-137 on 21 Jul 2020

我的最近也开始断了，但是有一点不同的是我的v2ray添加了5个不同地点的节点，只要一个Tcping不通其他的都不通,过几分钟又恢复了，所有这些现象在安卓手机上没有出现过

一模一样

Csxy on 11 Sep 2020

还有就是某些sb软件造成的自动强制关闭代理，如下图
8H4O{` N6VGU{$F%2697 PL
同样的问题详见：https://github.com/Fndroid/clash_for_windows_pkg/issues/312

xzp21st on 11 Nov 2020

应该不是QQ的锅，我有一台电脑的QQ和V2ray基本都是24小时开着的，没有出现这个问题。不过受你的启发，我还是使用win10自带的安全软件，添加了“受保护的文件夹”。
…
On Tue, Feb 11, 2020 at 10:15 PM Leeray-Lau _@_.*> wrote: @i553041 @i553041 已经解决了，就是我这台笔记本Win10操作系统的问题。具体原因不知道，不过我排查以及重置了系统一堆的配置，刚好碰巧给解决了，实在是太玄学了(ಥ_ಥ) …… 后续补充几句，给遇到同样问题的童鞋提供一个思路，虽然怎么解决的具体原因仍然不清楚，但当时我是这样操作的： 1.重置了IE的配置 2.重置了LSP和清理了DNS缓存 3.结束了QQProtect进程，并用火绒自定义防护功能监视了v2ray的文件夹 PS：关于第3点，我为什么会怀疑QQProtect.exe捣的鬼呢，因为腾讯的名声向来就不太好，比如利用这个QQProtect.exe进程病毒式的植入广告、或者利用游戏的 TenProtect扫描用户SSR、V2ray等、具体这个 TenProtect和聊天工具的 QQProtect 有没有共用一套信息收集逻辑就不得而知了，我当时没有逮到。腾讯的这些骚操作，早有用户反映过了，网上都是可以查到的国服游戏收集用户数据读取酸酸乳配置信息 laod.cn/black-technology/hips-tengxun-s-s.html 反正我大致上是这样操作了之后就解决了间歇性断流问题了。那QQ怎么开？如果你遇到跟我同样问题的话，可以尝试上面提到的方案。没有的话QQ照常开。我只是说有这种可能性，我也无法再次复现之前的那样的v2ray间歇性断流的场景…… PS：现在用了一个多礼拜了，V2Ray + WebSocket + TLS + CDN，稳的一B…… — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2198?email_source=notifications&email_token=AE34YTFHSIGRCHWSZAC5RLLRCKXG5A5CNFSM4KM7S6SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELMSBEQ#issuecomment-584654994>, or unsubscribe github.com/notifications/unsubscribe-auth/AE34YTHN6FCMPWNDAWBAWO3RCKXG5ANCNFSM4KM7S6SA .

应该不是QQ的锅，我有一台电脑的QQ和V2ray基本都是24小时开着的，没有出现这个问题。不过受你的启发，我还是使用win10自带的安全软件，添加了“受保护的文件夹”。
…
On Tue, Feb 11, 2020 at 10:15 PM Leeray-Lau _@_.*> wrote: @i553041 @i553041 已经解决了，就是我这台笔记本Win10操作系统的问题。具体原因不知道，不过我排查以及重置了系统一堆的配置，刚好碰巧给解决了，实在是太玄学了(ಥ_ಥ) …… 后续补充几句，给遇到同样问题的童鞋提供一个思路，虽然怎么解决的具体原因仍然不清楚，但当时我是这样操作的： 1.重置了IE的配置 2.重置了LSP和清理了DNS缓存 3.结束了QQProtect进程，并用火绒自定义防护功能监视了v2ray的文件夹 PS：关于第3点，我为什么会怀疑QQProtect.exe捣的鬼呢，因为腾讯的名声向来就不太好，比如利用这个QQProtect.exe进程病毒式的植入广告、或者利用游戏的 TenProtect扫描用户SSR、V2ray等、具体这个 TenProtect和聊天工具的 QQProtect 有没有共用一套信息收集逻辑就不得而知了，我当时没有逮到。腾讯的这些骚操作，早有用户反映过了，网上都是可以查到的国服游戏收集用户数据读取酸酸乳配置信息 laod.cn/black-technology/hips-tengxun-s-s.html 反正我大致上是这样操作了之后就解决了间歇性断流问题了。那QQ怎么开？如果你遇到跟我同样问题的话，可以尝试上面提到的方案。没有的话QQ照常开。我只是说有这种可能性，我也无法再次复现之前的那样的v2ray间歇性断流的场景…… PS：现在用了一个多礼拜了，V2Ray + WebSocket + TLS + CDN，稳的一B…… — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2198?email_source=notifications&email_token=AE34YTFHSIGRCHWSZAC5RLLRCKXG5A5CNFSM4KM7S6SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELMSBEQ#issuecomment-584654994>, or unsubscribe github.com/notifications/unsubscribe-auth/AE34YTHN6FCMPWNDAWBAWO3RCKXG5ANCNFSM4KM7S6SA .

我把那个qqprotect 关了还真就不断了。。。我也是服了

希望跟进报告一下，关了qqprotect之后接下来是否还有断流，因为我观察到qqprotect并没有进行重置系统代理的操作

SekiBetu on 13 Nov 2020

应该不是QQ的锅，我有一台电脑的QQ和V2ray基本都是24小时开着的，没有出现这个问题。不过受你的启发，我还是使用win10自带的安全软件，添加了“受保护的文件夹”。
…
On Tue, Feb 11, 2020 at 10:15 PM Leeray-Lau _@_.*> wrote: @i553041 @i553041 已经解决了，就是我这台笔记本Win10操作系统的问题。具体原因不知道，不过我排查以及重置了系统一堆的配置，刚好碰巧给解决了，实在是太玄学了(ಥ_ಥ) …… 后续补充几句，给遇到同样问题的童鞋提供一个思路，虽然怎么解决的具体原因仍然不清楚，但当时我是这样操作的： 1.重置了IE的配置 2.重置了LSP和清理了DNS缓存 3.结束了QQProtect进程，并用火绒自定义防护功能监视了v2ray的文件夹 PS：关于第3点，我为什么会怀疑QQProtect.exe捣的鬼呢，因为腾讯的名声向来就不太好，比如利用这个QQProtect.exe进程病毒式的植入广告、或者利用游戏的 TenProtect扫描用户SSR、V2ray等、具体这个 TenProtect和聊天工具的 QQProtect 有没有共用一套信息收集逻辑就不得而知了，我当时没有逮到。腾讯的这些骚操作，早有用户反映过了，网上都是可以查到的国服游戏收集用户数据读取酸酸乳配置信息 laod.cn/black-technology/hips-tengxun-s-s.html 反正我大致上是这样操作了之后就解决了间歇性断流问题了。那QQ怎么开？如果你遇到跟我同样问题的话，可以尝试上面提到的方案。没有的话QQ照常开。我只是说有这种可能性，我也无法再次复现之前的那样的v2ray间歇性断流的场景…… PS：现在用了一个多礼拜了，V2Ray + WebSocket + TLS + CDN，稳的一B…… — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2198?email_source=notifications&email_token=AE34YTFHSIGRCHWSZAC5RLLRCKXG5A5CNFSM4KM7S6SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELMSBEQ#issuecomment-584654994>, or unsubscribe github.com/notifications/unsubscribe-auth/AE34YTHN6FCMPWNDAWBAWO3RCKXG5ANCNFSM4KM7S6SA .

应该不是QQ的锅，我有一台电脑的QQ和V2ray基本都是24小时开着的，没有出现这个问题。不过受你的启发，我还是使用win10自带的安全软件，添加了“受保护的文件夹”。
…
On Tue, Feb 11, 2020 at 10:15 PM Leeray-Lau _@_.*> wrote: @i553041 @i553041 已经解决了，就是我这台笔记本Win10操作系统的问题。具体原因不知道，不过我排查以及重置了系统一堆的配置，刚好碰巧给解决了，实在是太玄学了(ಥ_ಥ) …… 后续补充几句，给遇到同样问题的童鞋提供一个思路，虽然怎么解决的具体原因仍然不清楚，但当时我是这样操作的： 1.重置了IE的配置 2.重置了LSP和清理了DNS缓存 3.结束了QQProtect进程，并用火绒自定义防护功能监视了v2ray的文件夹 PS：关于第3点，我为什么会怀疑QQProtect.exe捣的鬼呢，因为腾讯的名声向来就不太好，比如利用这个QQProtect.exe进程病毒式的植入广告、或者利用游戏的 TenProtect扫描用户SSR、V2ray等、具体这个 TenProtect和聊天工具的 QQProtect 有没有共用一套信息收集逻辑就不得而知了，我当时没有逮到。腾讯的这些骚操作，早有用户反映过了，网上都是可以查到的国服游戏收集用户数据读取酸酸乳配置信息 laod.cn/black-technology/hips-tengxun-s-s.html 反正我大致上是这样操作了之后就解决了间歇性断流问题了。那QQ怎么开？如果你遇到跟我同样问题的话，可以尝试上面提到的方案。没有的话QQ照常开。我只是说有这种可能性，我也无法再次复现之前的那样的v2ray间歇性断流的场景…… PS：现在用了一个多礼拜了，V2Ray + WebSocket + TLS + CDN，稳的一B…… — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#2198?email_source=notifications&email_token=AE34YTFHSIGRCHWSZAC5RLLRCKXG5A5CNFSM4KM7S6SKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOELMSBEQ#issuecomment-584654994>, or unsubscribe github.com/notifications/unsubscribe-auth/AE34YTHN6FCMPWNDAWBAWO3RCKXG5ANCNFSM4KM7S6SA .

我把那个qqprotect 关了还真就不断了。。。我也是服了

希望跟进报告一下，关了qqprotect之后接下来是否还有断流，因为我观察到qqprotect并没有进行重置系统代理的操作