如果你的 192.168.0.100:10010 能识别 192.168.0.100:10010/book 这个路径，可以试试修改 nginx 的 proxy_pass 配置
proxy_pass http://192.168.0.100:10010 ; --> proxy_pass http://192.168.0.100:10010/book ;
如果你后端真正的服务识别不了 /book 这个路径，你可以在 nginx 额外加 server 配置 book.abc.com proxy_pass 到 192.168.0.100:10010

我看你的 /book 还加了 proxy_set_header ，这样会让你后端真正的服务接收到 {host: abc.com} ，不知道这符不符合你的期望

我启用硬解后体验了两天，然后关闭了硬解，配置太差性能跟不上，客户端解的时候播放更流畅。
如果有不支持的编码，那就放弃这个编码的资源。

Cantook

你图上的是正式的网站吧？正式的网站打开怎么会请求 127.0.0.1:16005 这个本机地址？检查一下代码吧，是不是这个资源本身要在服务端请求的

APPEND 的贴图一股子超级小 x 的味儿

最起码，灵吉菩萨肯定有故事可以写，影神图里的灵吉和剧情里的灵吉表现不一样

@Harharhar 这两个 IP 最早出现在腾讯云漏洞扫描服务的地址池里，但是不知道为什么最近文档更新了，漏洞扫描的文档显示了一批新的 IP ，可能是有人找客服质疑了吧
你发的这个 wedata 文档在腾讯云上也有产品介绍，我也看不懂它的使用场景，好像是集合多个数据源，供其他应用调用？
https://cloud.tencent.com/document/product/1267/94885

@body007 #17 这种请求应该不是从微信服务器发出的，是从发送方或者接受方的客户端发出的，是为了显示链接卡片

@lx0758 不是，是机房的物理机

@billccn 忘了说，从客户端到 nginx 之间是 https 的。所以我一直在纠结这个 code 是怎么被第三方获取的，如果不是第三方，那就是浏览器了呗

@CaptainD 这可能是没充上电，耳机会认为自己只是“没有被放在耳朵里，放在了一边没用”；
清理一下充电仓里面的灰尘和耳机的尾巴就好了

@ETiV 你这个比楼主的可信度高多了

最开始我的用法是 foo.app 在 nginx 做 auth 验证拦截，引入 vouch 让 nginx 拥有可以和 OIDC 对接的能力，logto 作为 provider 。

后来发现 logto cloud 有了 protected 还想试试，但是要再去访问 foo.protected.app ，有些时候不想访问别人的域名，而且也不支持 oss 版本，现在已经没这个念想了 emmm

不过 logto 真是一个很好用的项目

怎么跟我理解的好像不太一样呢，WOL 依靠 mac 地址，发的包里要带 mac 地址信息，所以我是让内网服务器坐的，执行 WOL 的发包命令，电脑本身设置开启 WOL ，这样在关机的时候网卡还是亮着的，能收到 WOL 包。