@ugvfpdcuwfnh emmm ，已经在 Linux 下了，就没必要开 docker 然后配旁路由了吧，不过 docker 用来启动软件还行……
我是直接开 ss-redir ，用 systemd 做开机自启，然后用 nftables （或者 iptables ）直接配规则转发。
如果用 v2ray 之类的，也可以在 v2ray 里再配规则。

Google 上用 ios http proxy setting gone 关键词搜索，找到有人问过类似的问题。应该是你安装了某个软件全局接管了代理设置……

Google 的客服，你多提交几次，前几次是模板回答，里面应该有一些一般步骤，你就说跟着步骤问题仍然没有解决，多发几轮就会有人工回复了。
之前因为他们的 bug 导致我扩展程序不能通过就是这样，前几轮都是模板邮件，回了 4 次，就收到人工回复了。

@919615766 前两天研究 TLS 指纹识别的时候（主要是部分服务器会拦截非浏览器的请求，在研究原因），然后搜到了这篇文章
https://httptoolkit.tech/blog/tls-fingerprinting-node-js/
文章中提到了上面那个 TLS1.3 的图解，然后页面底部给了 TLS1.2 和 GitHub 的链接。
觉得挺好，就收藏了。

@jinliming2 #2 群里技术氛围挺好，入群请先看公告，不要讨论无关话题……一个一个 +1 的消息我比较尴尬……

@ppllss 所以 for 循环要登录 steam 么……
stream ？还是 iterator ？

@justNoBody github 上搜仓库名，可以搜到 fork

觉得可以看看这个，应该比较容易：
TLS1.2： https://tls.ulfheim.net/
TLS1.3： https://tls13.ulfheim.net/

没做错误处理、自己处理一下
server 端：
cert, err := tls.LoadX509KeyPair(*cert, *key)

CA := x509.NewCertPool()
file, err := ioutil.ReadFile(*ca)
CA.AppendCertsFromPEM(file)

tlsConfig := tls.Config{
GetCertificate: func(info *tls.ClientHelloInfo) (*tls.Certificate, error) {
return &cert, nil
},
ClientAuth: tls.RequireAndVerifyClientCert,
ClientCAs: CA,
// ...
}

客户端：
cert, err := tls.LoadX509KeyPair(*cert, *key)

CA := x509.NewCertPool()
file, err := ioutil.ReadFile(*ca)
CA.AppendCertsFromPEM(file)

tlsConfig := tls.Config{
Certificates: []tls.Certificate{cert},
RootCAs: certPool,
ClientAuth: tls.RequireAndVerifyClientCert,
ClientCAs: certPool,
// ...
}

@daoqiongsi1101 http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server 对于 HTTP/1 upstream ，可以通过 max_conns 限制连接数、keepalive 限制连接池。

先说一下 HTTP/1 、HTTP/2 、HTTP/3：
HTTP/1 在单个 TCP 上以 keep-alive 的形式复用，按照“请求-响应-请求-响应”的顺序进行，后面的请求会受到前面请求的阻塞，叫做“线头阻塞 Head-of-line blocking” https://en.wikipedia.org/wiki/Head-of-line_blocking
HTTP/2 在单个 TCP 上分帧复用连接，多个请求可以同时发送、同时接收。但这个“同时”只是在应用层的 HTTP 协议眼中看起来是“同时”的，而在传输层的 TCP 眼中来看还是串行的。就是将多个 HTTP 请求响应拆成小片，然后在单个 TCP 连接中交替（也不一定是交替）传输。所以仍然存在“线头阻塞”，只不过是 TCP 层面的线头阻塞。
HTTP/3 将传输层协议给替换掉了，改成了基于 UDP 的 QUIC ，由于 UDP 属于无状态的，所以传输层的包也是同时发送了，这就消除了传输层的线头阻塞。

回到你这个链接里讨论的不支持 HTTP/2 ，总结一下原因：
1 ，支持 HTTP/2 作为 upstream ，那么所有连接复用同一个 TCP ，会受到 TCP 线头阻塞和拥塞控制问题的影响，对 nginx 来说，会使得事情变得复杂
2 ，用单个连接传输，几乎消除了连接数的限制，但是实际上 nginx 本身也没有主动做这样的限制（除非你自己指定 max_conns ），所以这个没啥意义
3 ，（感觉也是最主要的一点）实现 HTTP/2 进行单路复用，需要对 upstream 模块做重大修改，风险比较高
If you still think that talking to backends via HTTP/2 is something needed - feel free to provide patches.（翻译：老子嫌麻烦不想做，你要觉得有必要，你做好了把 patch 提交上来）

所以，风险大于收益，他们觉得没有实现的必要。
这也是 2015 、2016 年的帖子了，那时候 HTTP/2 才刚起步。
现在 HTTP/3 的时代快来了，云厂商都在部署 h3 了，不知道是不是 nginx 的时代已经快过去了？（瞎说的）

@daoqiongsi1101 所以啊，你只要想一想，你 10 个 goroutine 请求是同时请求的，还是有先后顺序的？肯定是同时的啊。

实际上，同时并发请求数受到操作系统的限制（端口数、ulimit 、maxfiles 之类的），为了避免达到操作系统限制，同时降低建立 TCP 的开销，所以浏览器才会实现较小的并发限制。
实际上，具体是看你 golang 代码怎么写的。多个 goroutine 是用的同一个 http.Client 还是不同的，单域名连接数配置的多少。
如果是使用默认的 http.Client 来请求的话，那么走的就是默认的 http.Transport 配置，里面指定的单域名连接数 MaxConnsPerHost 默认是 0 ，也就是不限制。那么你只要没有达到操作系统限制，并发就是能建立多少 TCP 就建立多少 TCP 来并发请求，所以 10 个 goroutine 就是 10 个 TCP 。
而另外，可以针对单个 http.Client 对象来限制连接数，那么使用同一个实例来请求就会受到限制，达到限制就会阻塞等待。

另外注意，这个连接数跟连接池关系不大。默认的 http.Transport 的连接池有两个配置：全部连接池大小 MaxIdleConns 默认是 100 、单域名连接池大小 DefaultMaxIdleConnsPerHost 默认是 2 。这两个配置不影响并发请求的 TCP 连接数。

假设现在是单域名，单域名连接池大小 DefaultMaxIdleConnsPerHost 是 2 ，MaxConnsPerHost 并发数设置了 5 。那么此时你开了 10 个 goroutine 并发，并且每个请求都是 1 秒响应，则会发生这样的情况（实际情况可能受各种竞争因素影响）：
1 ，建立 5 个 TCP 连接并发，剩余 5 个连接阻塞等待。
2 ，5 个连接请求结束，只有 2 个 TCP 连接进入连接池复用，剩余 3 个 TCP 连接被 close 。
3 ，剩下的 5 个连接开始请求，其中 2 个复用之前连接池中的 TCP 连接，另外 3 个则建立新的 TCP 连接进行请求。
4 ，所有请求都结束，连接池中持有 2 个连接等待复用，其余连接都被 close 。
5 ，如果没有更多请求了，则连接池中的连接在超时（ IdleConnTimeout ）后被自动 close 。或者等待 TCP 自己的 keepalive 超时规则（ tcp_keepalive_time 、tcp_keepalive_intvl 、tcp_keepalive_probes ）来关闭连接。

等下，HTTP/1.1 的请求，并行不是复用同一个 TCP 啊？串行才是复用同一个 TCP 的啊！队头阻塞也是复用同一个 TCP 连接的串行 HTTP ，后面的请求要等待前面的请求响应啊。
Chrome 并发连接数限制是指创建的 TCP 的连接数啊，并且仅限 HTTP/1 。

HTTP/1 还没有分帧并发的技术，所有数据都是串行发送的，不存在你说的“并发请求、顺序响应”。要实现并发，就得建立多条 TCP ，在多个 TCP 连接上同时请求。
HTTP/1 的 keep-alive 是指一轮 请求-响应 结束后，不关闭 TCP 连接，可以直接在当前 TCP 连接上进行新的 HTTP 请求-响应。

本地启个 v2ray 后台进程，出口自己配路由指定不同域名走不同代理，或者不走代理。然后 Chrome 启动直接全局代理 127.0.0.1