如果想快速测试但是又不想起一个 nginx 实际的话，这里有一个网站可以让你调试，配两个 server 块，A server 发请求，B server 收请求并且输出$request_uri 就能看到结果了。https://tech-playground.com/playgrounds/nginx/

你这段配置确实很难第一时间理解处理逻辑……主要还是 nginx 太智能了，很多时候喜欢给你搞分场景自动处理。你这里的不仅仅在于 rewrite ，还有 location 和 proxy_pass 的 uri 拼接逻辑。
实测之前基本上没人敢给你准确答案。
比如
1.proxy_pass 带变量和不带变量是两种处理逻辑
2.proxy_pass 带 uri 和不带 uri 是两种处理逻辑
4.location 用正则和非正则是两种处理逻辑

@ysc3839 rewrite 虽然不匹配参数，但是可以改参数的，比如他这里，会追加一个 name 参数到原参数列表里面（ rewrite 甚至帮你处理好?和&的拼接问题了）

你这个前提就是错的，没有规定客户端证书和服务端证书要用同一个 ca 签发。不同也是可以的，而且通常情况都应该是不同的，相同反而才有问题

@jiuhuicinv 现在 chrome 已经开始在访问 http 网站时提醒不安全了（是直接弹窗提醒，你点击确认之后才能继续浏览那种）。保不齐到时候真的会访问 http 直接给你来个红色页面，把 http 网站打成像诈骗网站一样的级别

@a33291 $upstream_uri 是回上层的原始 URI ，也就是实际发给后端的 URI ，至于是否规范那就看你 nginx 配置了。nginx upstream 模块和 openresty 都没有这个变量，是我这个模块追加的，这个模块还包括一大堆其他变量（部分变量要配合补丁才能生效，我用 NGX_HTTP_EXT 宏注释了，没打补丁的话用不了这些模块），你可以单独抽出来做成一个独立模块。

这个靠配置是无法实现的，如果你要准确的上游 uri 的话，其他很多上游变量都需要单独导出。我主要是为了给我自己开发的上游日志模块做变量支撑才实现的： https://github.com/HanadaLee/ngx_http_upstream_log_module

参考： https://github.com/HanadaLee/ngx_http_extra_variables_module

配置上没看出啥问题，你是怎么测试出~/info 失败的（另外建议改成~^/info ，会更精确点）

proxy_pass 的值有变量的话 nginx 的处理逻辑是不一样的。如果有接变量的话，nginx 不会再帮你附加原始请求 uri 进去，所以你异常那个就变成固定使用/ws/回上层了。如果你一定要用变量，可以考虑这样写
proxy_pass http://$api_host:8877$request_uri;
另外不建议无脑给 Connection 头写死设置 Upgrade ，可以参考 nginx 官方第二种写法，用 map 来指定
https://nginx.org/en/docs/http/websocket.html

L2 节点一般不直接面向客户端服务的，你直接请求会被拒绝访问

@RangerWolf 是，不过相比 le 和 zerolssl 要麻烦一些，要先在谷歌云控制台申请 api 。申请完之后用起来就没啥差了，不过注意申请证书的机器要在海外，国内到谷歌肯定是不行的

我一般用 google 的 ca

继续投诉他们啊，他们自己架构实现问题，就靠一个头部约定来识别来路流量，本身是他们自己实现方案问题。最起码得让他退多收的钱

location / {

default_type text/html;
proxy_pass $scheme://$host;

if ($host !~* a.com$) {
return 404;
}

}

@FanError 要传 sni ，proxy_ssl_server_name 和 proxy_ssl_name

@keepeye 但是不支持轻量

@Steps 阿里云 cdn 回源直接 502，我都是找一台海外机反代了再让阿里云 cdn 回源的……