用于修复港澳台地区访问错误的方法
为什么我触发了那么多“不良信息”然后不能发？额外补充：上面的方案也可以解决其他国家/地区的用户访问不正常的问题。
至于大陆内部访问不正常的问题，晚点我再研究吧（笑）。
我是台灣中華電信用戶, 不過我這邊好像沒經過cloudflare節點,
不確定其他ISP會不會經過, 上一篇文章有一位香港用戶有經過cloudflare節點,
我遇到百合會連線障礙, 我都是直接重新換ip就解決了,
有些ip分到的節點, 連外比較慢. eils 发表于 2021-1-4 00:26
我是台灣中華電信用戶, 不過我這邊好像沒經過cloudflare節點,
不確定其他ISP會不會經過, 上一篇文章有一位 ...
你nslookup一下，如果发现解析出来信息有yunjiasu-cdn.net或者cloudflare字样，那就是CloudFlare DNS查詢有yunjiasu-cdn, 可是路由好像都是HINET的?
我也不太確定
名稱: bbs.yamibo.com.cname.yunjiasu-cdn.net
Addresses:162.159.212.144
162.159.213.144
Aliases:bbs.yamibo.com
// 在上限 30 個躍點上追蹤 162.159.213.144 的路由
1 2 ms 4 ms 3 msh254.s98.ts.hinet.net [*.*.*.*]
2 7 ms 2 ms 3 msTPN2-3501.hinet.net
3 4 ms 4 ms 3 ms220-128-9-54.HINET-IP.hinet.net
4 6 ms 3 ms 3 mstpdt-3011.hinet.net
5 4 ms 4 ms 3 msr4210-s2.hinet.net
6 5 ms 5 ms 3 ms210-242-214-45.HINET-IP.hinet.net
7 5 ms 3 ms 3 ms162.159.213.144
// 在上限 30 個躍點上追蹤 162.159.212.144 的路由
1 5 ms 4 ms 2 msh254.s98.ts.hinet.net [*.*.*.*]
2 3 ms 3 ms 3 msTPN2-3502.hinet.net
3 4 ms 3 ms 3 ms220-128-10-54.HINET-IP.hinet.net
4 4 ms 7 ms 3 mstpdt-3012.hinet.net
5 2 ms 3 ms 3 msr4210-s2.hinet.net
6 6 ms 3 ms 4 ms210-242-214-45.HINET-IP.hinet.net
7 4 ms 3 ms 3 ms162.159.212.144 eils 发表于 2021-1-4 01:48
DNS查詢有yunjiasu-cdn, 可是路由好像都是HINET的?
我也不太確定
这不是完整的路由追踪，这部分显示的是你到你的ISP，而不是你的ISP怎么到CloudFlare。
另外我补充一下：百度云加速和CloudFlare共用节点，因此就出现了yunjiasu-cdn这种奇妙的CF节点。
eils 发表于 2021-1-4 01:48
DNS查詢有yunjiasu-cdn, 可是路由好像都是HINET的?
我也不太確定
不要回复刚刚那层楼，那层楼我错了。
这确实是走到了CF节点，你看不到后面的路由是因为那部分路由是CF负责走的，这涉及到我tm都快全还给老师的网络知识，简而言之：你追踪不到的。 恩, 感謝教學,
另外想請教一下, 有辦法追蹤後半部分的路由嗎?
還有有時候重撥一個ip就不會連不上了, 這部分該如何分析和理解? eils 发表于 2021-1-4 01:55
恩, 感謝教學,
另外想請教一下, 有辦法追蹤後半部分的路由嗎?
還有有時候重撥一個ip就不會連不上了, 這部 ...
简单来说：不能。
因为路由追踪是ICMP协议，位于OSI模型的第三层（网络层），它无法追踪第七层（应用层）的路由。
而CloudFlare这类CDN本质上是一种工作在第七层的“反向代理”，因此它是无法得知后面的路由是怎么走的（它只能在IP层面上追踪路由，但是DNS解析返回来的IP就是CF CDN的IP）。
因此，实际上这里还得补充：之前那个帖子中，用ping这个方法来判断连通性根本不科学（完全错误）——因为ping的不是源服务器，而是CloudFlare CDN的节点，因此其实什么都测不出来。
static/image/hrline/line8.png
第二个问题，很好，尝试把DNS换成8.8.8.8（主）和8.8.4.4（备）。
在台湾地区经常会出现DNS乱解析的问题，尝试把DNS换成谷歌（8888 8844）或者CloudFlare（1.1.1.1 1.0.0.1）即可。
感謝回答
OSI呀...,我都忘的差不多了,
不過反向代理這塊我確實不熟.
我目前DNS是用 1.1.1.1 和 8.8.8.8 eils 发表于 2021-1-4 02:08
感謝回答
OSI呀...,我都忘的差不多了,
不過反向代理這塊我確實不熟.
反向代理其实可以类比成客服中心。
举个例子：你打电话给中华电信的客服，总机会告诉你“请等待，正在转接”。
在这个时候，那个“总机”就是个反向代理，它负责把请求转到后方的服务器。
而且OSI最近大改了——新的网络技术教材已经把5-7层统称为应用层了（笑）。
此外就是，建议使用支持ECS（EDNS-Client-Subnet，该协议会在DNS请求包中附加请求域名解析的用户IP地址。这样，DNS服务器就可以根据该地址返回用户更容易访问的服务器IP地址）技术的DNS（推荐谷歌），这样解析更精准。
樱花散 发表于 2021-1-4 02:14
反向代理其实可以类比成客服中心。
举个例子：你打电话给中华电信的客服，总机会告诉你“请等待，正在转 ...
感謝回答
不過牆內用google的DNS會不會被擋住呀?
題外話, 其實我有點好奇百合會貼圖區很多文章都是原圖尺寸(接近1mb或是超過),
感覺這樣對伺服器的負載和流量會造成不小的負擔吧? eils 发表于 2021-1-4 02:27
感謝回答
不過牆內用google的DNS會不會被擋住呀?
某个巨大的网络流量整形设备并不会挡住8.8.8.8
但它会检查这些通往大陆之外的DNS流量中是否有关键字，如果有就伪造/阻断。
Google的DoH（DNS over HTTPS）服务在大陆不可用，因为某个巨大的网络流量整形设备把谷歌IP段拉黑了（确切来说，访问谷歌的IP段时，如果端口是80 443就会被立即阻断，所以严格来说是“把谷歌IP段的80 443之类的端口拉黑了”）。
但Google的DoT（DNS over TLS）没有问题，因为DoT使用的是853端口。
static/image/hrline/line8.png
至于服务器负载……我不知道，我又不知道他们服务器什么配置。
图多的话，压力主要集中在带宽上，当然还有CPU和内存，最后是硬盘（不追求质量的话，硬盘其实并不贵）。
先保存一下，下半年去英国说不定用得上 d768034464 发表于 2021-1-7 02:37
先保存一下，下半年去英国说不定用得上
这是解决服务器问题的，保存也没用啊（x 原来简单的网站爆炸背后隐藏了那么多的原理呀（误）
本电脑痴提个可能很不切实际的方案
搞个墙外镜像会不会好点？
反正bbs也不需要什么时效性，比如每隔五分钟就把这五分钟发生的事丢给那小水管让她五分钟去操作这样？ sja16 发表于 2021-1-7 20:00
原来简单的网站爆炸背后隐藏了那么多的原理呀（误）
本电脑痴提个可能很不切实际的方案
搞个墙外镜像会不 ...
你无法“镜像”任何动态内容。
动态网页内容指的是：服务器在自己这里处理后，再返回给客户端“执行结果”的东西——例如php网页文件。
因此，论坛本身是无法镜像的。你还是得用上面提到的“反向代理”方案，而这就是各种CDN服务的原理：“带有缓存功能的反向代理”。
最简单的方法就是挂个梯、、、子翻回来{:4_342:}
（我忍无可忍的时候就是这么干的 对，挂个v○○，又便宜，又快速，又安全。只不过有时候会被误识别成异常ip sja16 发表于 2021-1-7 20:00
原来简单的网站爆炸背后隐藏了那么多的原理呀（误）
本电脑痴提个可能很不切实际的方案
搞个墙外镜像会不 ...
那样还不如买aws。要让镜像站保证一定的时效性，还不出现各种奇怪的错误，并且比aws之类的云计算服务的反代便宜，感觉不太现实
跑Pro。xy还是要不少算力的。我在无线路由上面挂的，就我一个人用，看4k的视频我那4核的无线路由 CPU就快满载了。256M的内存有时候还会满掉，然后整个家里的网络挂掉
图片倒是有办法弄，耗带宽的还是图片吧。主站用反代可以弄
只要肯花钱，肯定是有办法的。以前Google中国有个专线可以直连Google美国，记得微软也有
页:
[1]