@JCZ2MkKb5S8ZX9pq #11
嗯，更具体的我就不太了解了，我试了一下中英文字体的混合并回退的情况，会展示出两种字体。
不清楚你是否是想要看到具体的每一个字所回退的情况，这样的功能似乎确实没有。

@JCZ2MkKb5S8ZX9pq #8
应该可以查看的吧，你看下 Computed 标签里的 Rendered Fonts

https://i.loli.net/2020/06/13/lyYn3q2JxGWIsdc.png

@JCZ2MkKb5S8ZX9pq #6
是的，谁叫腾讯云先给了骚操作呢。
1 、按道理来说，改 header 可以解决。
2 、按道理来说，COS 是对象存储，应该不担心文件和项目重名的问题
3 、这就很难处理了

其实我本来是想说让你在腾讯云 COS 后台配置重定向规则的，但是我试了一下，好像只支持前缀匹配，感觉也配不出想要的效果。

@JCZ2MkKb5S8ZX9pq #5
语言和字体关联还是蛮合理的，不过从你这几个问题来看，腾讯云的 COS 静态网页相关功能，还真是很多小坑啊

同楼上疑问，建议打开 Chrome 的控制台，先检查一下 Network 标签内的每一个请求是否一致。

1 、这个情况是不是腾讯云造成的？（就不同服务端对这类情况处理不同）
答：是腾讯云造成的，nginx 使用的 301 跳转方法更合理一些。

2 、如果相对路径有没有办法对应这个问题？
答：没有，这实际上是腾讯云的处理导致页面的目录结构被错误理解了。

3 、我能想到的方法是在 index.html 里判断一下当前路径，不行加个跳转。有没有更好的方法？
答：我暂时能想到的也只有这个方法了。


接下来说一下具体为什么会出现这个情况，首先来看 nginx 的实现。


当你访问 abc.com/proj/ 的时候，nginx 知道你想要访问的是 proj 这个『子目录』，
于是 nginx 会去 proj 目录，按照配置好的 index 文件名（一般是 index.html ）去寻找相应的文件。
当找到了 proj/index.html 后，会将它作为 proj 这个『子目录』的『主页』返回给浏览器。

当你访问 abc.com/proj 的时候（不带斜杠），nginx 会有点迷惑，你会不会是想找一个叫 proj 的『文件』呢？
于是 nginx 会先去看一下是否存在一个叫做 proj 的『文件』，看了看好像并没有这个『文件』；
那么善解人意的 nginx 就会想到，你肯定是想访问 /proj/ 这个 『子目录』；
于是 nginx 返回了一个 301 重定向，将你带去 abc.com/proj/ 访问（带斜杠）。
再接下来，就是上面的流程了。

// nginx 的这个功能，可以通过 absolute_redirect 参数来进行开关。


腾讯云的 COS 的实现问题在于，当你访问 abc.com/proj 的时候（不带斜杠），善解人意的腾讯云，也猜到了你其实是想访问 /proj/ 这个 『子目录』，但是它做了一个愚蠢的决定，那就是直接将 proj/index.html 的内容返回给你。

这让死脑筋的浏览器犯了迷糊，既然我访问 abc.com/proj 时得到了一个页面，那看来这个页面应该是属于 proj 这个『文件』的，那么当前页面所在的『目录』应该就是 abc.com/ 了。

相关文档：
https://cloud.tencent.com/document/product/436/32670#.E7.B4.A2.E5.BC.95.E6.96.87.E6.A1.A3

想要解决这个问题，就需要在访问 abc.com/proj 的时候，有个明确的重定向机制（也就是 nginx 做的 301 ），这样浏览器能够明确的区分出当前页面所在的目录。

写到这里，我想到一个方法不知道是否可行，可以试试创建一个 proj 『文件』，在里面写上手动重定向的代码，但是我不确定腾讯云的 COS 是否能正确的处理 MIME 信息。（可能需要使用自定义 Headers 功能自定义一下）

说真的，这些图片直接存起来可能成本更低

@JCZ2MkKb5S8ZX9pq 由聚餐想到的一个距离算法问题
https://www.v2ex.com/t/528263


@LevineChen
分享一个小程序 "中间见"
https://www.v2ex.com/t/528379


ifanr
不知道约会聚餐在哪儿碰面？用这个小程序，我们「中间见」
https://www.ifanr.com/minapp/1169015

@Raul7
有没有试试我在 11 楼提到的 traefik

根据相应的代码，提一个简单的思路。

在 WordPress 后台修改伪静态规则，将页面地址修改为：
http://www.cbaigui.com/?biepale=1

同时在 nginx 内匹配带有 ?page= 的请求，全部 deny


这样可以在短时间内解决掉大部分只会复制粘贴代码的小白。

修正一下，爬虫教程的地址是：
https://zhuanlan.zhihu.com/p/147190049


目前文章已被删除，Google 快照上还可以看到记录：
http://webcache.googleusercontent.com/search?q=cache:3gzxhkXTcnkJ:https://zhuanlan.zhihu.com/p/147190049&hl=zh-CN&gl=jp&strip=1&vwsrc=0

大概翻了一下，爬虫教程的地址是：
https://www.zhihu.com/people/1425827033

目前已删除，在快照里还可以看到记录。

根据这个爬虫教程的代码，加上大部分爬虫小白其实不会改代码的事实。
我觉得站长应该可以通过设定简单的 nginx 策略来解决问题。
另：在微博上看到站长的抱怨，感觉应该只是数据库负载太高，Web Server 应该还活着。


部分代码：
https://i.loli.net/2020/06/11/uyMcamsXoSUYCjD.png

另：
我本来还是对 haproxy 抱有希望的，翻了下发现，他们好像并不打算支持 UDP
https://github.com/haproxy/haproxy/issues/62