v4.27.0+ 版本中 HTTP outbound 异常

zry98 commented 3 years ago

除非特殊情况，请完整填写所有问题。不按模板发的 issue 将直接被关闭。如果你遇到的问题不是 V2Ray 的 bug，比如你不清楚要如何配置，请使用Discussion进行讨论。

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

v4.27.0 无异常，v4.27.5 开始出现异常至最新 release v4.31.3

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

对指定域名与 IP，将通过 socks5 或 VLESS 等 inbound 进入的请求通过 http outbound 转发至运行在容器中的 nondanee/UnblockNeteaseMusic 项目

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

在 v4.27.0 版本中一切正常，在之后的版本中永远无法获得 HTTP 响应

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

正常获得 HTTP 响应

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

服务器端配置:

    // 可忽略，见客户端配置示意

客户端配置:

{
  "inbounds": [
    {
      "tag": "socks_unblock-netease-music",
      "port": 16388,
      "listen": "127.0.0.1",
      "protocol": "socks",
      "settings": {
        "auth": "noauth",
        "udp": false,
        "userLevel": 0
      },
      "sniffing": {
        "enabled": true,
        "destOverride": [
          "http",
          "tls"
        ]
      }
    }
  ],
  "outbounds": [
    {
      "tag": "proxy-to_unblock-netease-music",
      "protocol": "http",
      "settings": {
        "servers": [
          {
            "address": "192.168.1.5",
            "port": 16388
          }
        ]
      }
    }
  ],
  "routing": {
    "domainStrategy": "IPIfNonMatch",
    "rules": [
      {
        "type": "field",
        "inboundTag": [
          "socks_unblock-netease-music"
        ],
        "domain": [
          "music.163.com",
          "music.126.net",
          "push.126.net",
          "dun.126.net",
          "dun.163yun.com"
        ],
        "outboundTag": "proxy-to_unblock-netease-music"
      },
      {
        "type": "field",
        "inboundTag": [
          "socks_unblock-netease-music"
        ],
        "ip": [
          "59.111.181.0/24",
          "59.111.160.0/24",
          "163.171.135.0/24",
          "163.171.141.0/24",
          "103.126.92.0/24",
          "223.252.199.0/24",
          "104.126.103.0/24"
        ],
        "outboundTag": "proxy-to_unblock-netease-music"
      },
      {
        "type": "field",
        "inboundTag": [
          "socks_unblock-netease-music"
        ],
        "outboundTag": "direct"
      }
    ]
  }
}

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

服务器端错误日志:

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

客户端错误日志:

// v4.27.0
2020/10/26 02:42:55 [Info] v2ray.com/core/transport/internet/tcp: listening TCP on 127.0.0.1:16388
2020/10/26 02:42:55 [Warning] v2ray.com/core: V2Ray 4.27.0 started
2020/10/26 02:43:08 [Info] [3304336735] v2ray.com/core/proxy/socks: TCP Connect request to tcp:music.163.com:80
2020/10/26 02:43:08 [Info] [3304336735] v2ray.com/core/app/dispatcher: sniffed domain: music.163.com
2020/10/26 02:43:08 tcp:127.0.0.1:5226 accepted tcp:music.163.com:80 [proxy-to_unblock-netease-music]
2020/10/26 02:43:08 [Info] [3304336735] v2ray.com/core/app/dispatcher: taking detour [proxy-to_unblock-netease-music] for [tcp:music.163.com:80]
2020/10/26 02:43:08 [Info] [3304336735] v2ray.com/core/transport/internet/tcp: dialing TCP to tcp:192.168.1.5:16388
2020/10/26 02:43:09 [Info] [3304336735] v2ray.com/core/app/proxyman/outbound: failed to process outbound traffic > v2ray.com/core/proxy/http: connection ends > context canceled

// v4.27.0+ (以下为 v4.27.5，release 中第一个出现此异常的版本)
2020/10/26 02:45:43 [Info] [1009501354] v2ray.com/core/proxy/socks: TCP Connect request to tcp:music.163.com:80
2020/10/26 02:45:43 [Info] [1009501354] v2ray.com/core/app/dispatcher: sniffed domain: music.163.com
2020/10/26 02:45:43 [Info] [1009501354] v2ray.com/core/app/dispatcher: taking detour [proxy-to_unblock-netease-music] for [tcp:music.163.com:80]
2020/10/26 02:45:43 tcp:127.0.0.1:5300 accepted tcp:music.163.com:80 [proxy-to_unblock-netease-music]
2020/10/26 02:45:43 [Info] [1009501354] v2ray.com/core/transport/internet/tcp: dialing TCP to tcp:192.168.1.5:16388
// 卡在此处，在 curl 测试中永远无法获得 HTTP 响应

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

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

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

wireshark 抓包：

v4.27.0: v4.27.0抓包

v4.27.5: v4.27.5抓包

docker 容器的日志：

v4.27.0: TUNNEL > localhost:16388 MITM > music.163.com

v4.27.5: TUNNEL > localhost:16388 （之后再无新条目）

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

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

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

通常的命令为 journalctl -u v2ray。

请预览一下你填的内容再提交。

zw963 commented 3 years ago

@kslr , 我猜我遇到了同样的问题，也许我发错了地方，这可能属于新版本 v2ray 引入的问题.

https://github.com/v2fly/discussion/issues/56

kslr commented 3 years ago

这需要调查下，但最近没有时间。我记忆里改动的只有一个0 RTT你可以把这些移除再测试

xianren78 commented 3 years ago

@darhwa https://github.com/v2fly/v2ray-core/commit/d05ddc8f78dabc66efce2dc2ead520d28b4ab710 难道是这个commit的原因？

zry98 commented 3 years ago

@darhwa d05ddc8 难道是这个 commit 的原因？

我把 proxy/http/client.go 回退到这之前的一个 commit cae278d（然后把第 50 行的参数 *rec 改成 rec ）就正常了，看来是 0-RTT 的问题

zw963 commented 3 years ago

题外话，可能跟这个 issue 无关，是不是上面的那些改动会影响采用 http3 协议的浏览器访问 Web 页面？

我的火狐开启了如下设定：

about:config => network.http.http3.enabled, 设置为 true

RPRX commented 3 years ago

题外话，可能跟这个 issue 无关，是不是上面的那些改动会影响采用 http3 协议的浏览器访问 Web 页面？

我的火狐开启了如下设定：

about:config => network.http.http3.enabled, 设置为 true

不会影响，因为 HTTP 代理不支持 UDP，换句话说，HTTP/3 始终无法被代理，最终会回到 TCP。

（这个竞争过程应该不会和那个 commit 冲突？）

zw963 commented 3 years ago

@rprx , 您觉得是否会造成我的那个问题？

v2fly/discussion#56

darhwa commented 3 years ago

@zry98 感谢报告。

之前添加的0-RTT机制是把首个payload紧接着CONNECT请求头发送，而不等待服务器2xx响应。在被代理流量是明文http的情况下，首个payload也是一个http请求。这时到底该把它当成是被代理流量，还是当成另一个请求（http pipelining），RFC并没有明确规定，甚至不同地方措辞相互矛盾。我当初试过用http outbound连caddy+forwardproxy，haproxy，polipo，v2ray自己的http inbound，都是没有问题的，但是现在问题终于还是出现。

所以最好还是不给http/1.x tunnel用0-rtt，因为标准本身不明确，别人有不同实现我也不能说他错了。对h2 tunnel还是继续保留，一是h2 tunnel目前我知道只有haproxy和caddy+forwardproxy支持，这两个都没有问题，二是h2的被代理流量都在DATA frame里，避免了http/1.x tunnel的这种二义性，因此也不太可能出现问题。

已提交PR #372

darhwa commented 3 years ago

@zw963 我看了你在 v2fly/discussion#56 里的配置，没有用到http outbound，因此你的问题与本issue无关。

zry98 commented 3 years ago

@zry98 感谢报告。

之前添加的 0-RTT 机制是把首个 payload 紧接着 CONNECT 请求头发送，而不等待服务器 2xx 响应。在被代理流量是明文 http 的情况下，首个 payload 也是一个 http 请求。这时到底该把它当成是被代理流量，还是当成另一个请求（http pipelining），RFC 并没有明确规定，甚至不同地方措辞相互矛盾。我当初试过用 http outbound 连 caddy+forwardproxy，haproxy，polipo，v2ray 自己的 http inbound，都是没有问题的，但是现在问题终于还是出现。

所以最好还是不给 http/1.x tunnel 用 0-rtt，因为标准本身不明确，别人有不同实现我也不能说他错了。对 h2 tunnel 还是继续保留，一是 h2 tunnel 目前我知道只有 haproxy 和 caddy+forwardproxy 支持，这两个都没有问题，二是 h2 的被代理流量都在 DATA frame 里，避免了 http/1.x tunnel 的这种二义性，因此也不太可能出现问题。

已提交 PR #372

已编译测试，完美 fix，感谢！

zw963 commented 3 years ago

@zw963 我看了你在 v2fly/discussion#56 里的配置，没有用到http outbound，因此你的问题与本issue无关。

嗯，谢谢，我这个问题我最终发现，似乎只在我最新编译的 Firefox nightly 上才有，我安装 Arch 自带的 Firefox/Chrome 似乎都没问题，所以，可能仅仅是 Firefox config 或编译的问题。

v2fly / v2ray-core

v4.27.0+ 版本中 HTTP outbound 异常 #357