[X] My Assistant

你不妨亲自试试 itdog 的测速访问有多密集。这能被当做 DDOS 来防御，还是 IP 黑洞级别的防御，我觉得 Cloudflare 在防护策略上不至于会犯这么低级的错误。我在 censys search 反查了这三个 IP ，很明显不是 EH 独享的，一般来说只有一个网站受攻击， CDN 服务商不会选择将整个 IP 的流量屏蔽。并且就算受到应用层的 DDOS 攻击，我认为一般也应该开启应用层的防火墙，而不是就这么把中国大陆主要运营商的流量都空路由了。
所以，我认为不是 Cloudflare 的锅。

居然还能当免费ddos工具？震惊

自从AI大火之后，MANGA和DOUJIN类本就被版权炮的悲惨境遇简直雪上加霜，更新频率和质量都感觉不如以前 (IMG:[invalid] style_emoticons/default/sad.gif)

https://e-hentai.org/g/2584516/183ae205c5/
这画廊是被限流了吗，怎么以前一万好几的浏览量，现在就只有两千了

如果一个画廊在画廊链中，那么只会显示当前链的数据。如果你点击的画廊是画廊链中的最新版本那么就不会显示
以前的统计数据，因为这是个全新的画廊。

※说句题外话，画廊链里的父画廊跟被expunge的画廊一样，不会产生GP收益也不会计算被replace之后的排行榜点数。
但是他们已有的排行榜点数依然有效，这也是经常会在排行榜里看到被划掉的画廊的原因。

This post has been edited by Acetominaphene: Jun 20 2023, 11:27

Magnificent Shocking Rapier of Slaughter

請問我在"武器強化"上增強閃電法術傷害加成在我使用普通攻擊的時候會有收益嗎?

簡單來說會打得更痛嗎?

目前敵人的HP太多了,短時間不知道怎麼提升傷害了。

Magnificent Shocking Rapier of Slaughter

請問我在"武器強化"上增強閃電法術傷害加成在我使用普通攻擊的時候會有收益嗎?

簡單來說會打得更痛嗎?

目前敵人的HP太多了,短時間不知道怎麼提升傷害了。

EDB 是法術獎勵，需要施放該屬性的法術才有用
所以沒用

戰士要打的痛，要麼麻煩點放 IMP ，要麼追求殺戮動力（但划不來）
善用 skill 也能加速，不過也是操作繁瑣

在日本的麦当劳的汉堡包价格，去年110日元(5.5人民币)，现在提高到240日元(12人民币)
吉士汉堡从140日元(7人民币)涨到280日元(14人民币)
在很短一年内反复涨价，价格是超过一倍
这不是利用乌克兰战争和新冠肺炎来趁机涨价吗？

This post has been edited by Unko Man: Jun 20 2023, 13:02

你不妨亲自试试 itdog 的测速访问有多密集。这能被当做 DDOS 来防御，还是 IP 黑洞级别的防御，我觉得 Cloudflare 在防护策略上不至于会犯这么低级的错误。我在 censys search 反查了这三个 IP ，很明显不是 EH 独享的，一般来说只有一个网站受攻击， CDN 服务商不会选择将整个 IP 的流量屏蔽。并且就算受到应用层的 DDOS 攻击，我认为一般也应该开启应用层的防火墙，而不是就这么把中国大陆主要运营商的流量都空路由了。
所以，我认为不是 Cloudflare 的锅。

fiiz 正解。

而是那个测速网站列出用来测速的所有 ISP 运营商
都会被连累当成是意图对 被测速网站发动攻击 一起被 CloudFlare 阻断 。

群里也有人提到，CloudFlare 不会因为几个大陆 IP 的所谓“非正常请求”就会连坐把大陆的所有 ASN 封禁。
这种超大范围的误伤行为是 CDN 厂商的大忌。

另外 CloudFlare 买了大量的中国电信的带宽用于抗 DDoS。
如果是大流量 DDoS 流量 CloudFlare 是会硬扛的，更别说那测速网站的那一丢丢量。

况且 EH 每天的来自大陆的访问量就非常大，比那个测速网站的量多了不知道多少个数量级，连接失败的肯定也不是少数。

按照这个说法，CloudFlare 早就该把 EH 的流量对大陆直接黑洞了，不可能会在 EH 上了 CloudFlare N年后才封锁。

(通过阻断攻击者用的IP段保护网站， 一些家用路由器的 防黑客攻击自动IP黑名单 功能也是类似的)。

没错，正因如此，封禁的应该是攻击方的 IP，严重的封锁 IP 段。
而现在的情况是在大陆的所有 ASN 都被封锁了，一个测速网站不可能让 CloudFlare 做到这些。

你管 10Gbps 叫 DDoS？ (IMG:[invalid] style_emoticons/default/blink.gif) 50Gbps 到 100Gbps 左右的 DDoS 打到 skk.moe 上那是家常便饭、每周至少能遇到一两次；各种 CC 攻击更是数不胜数，上周才有人给我送了 1400 万请求到 Cloudflare 上：

吃了 10Gbps 的 D 不清退你，并不是说 50Gbps 不清退你、100Gbps 不清退你。而且轮段也是随时随地都会来的，哪怕你不做任何敏感业务，也是会挨打的 (IMG:[invalid] style_emoticons/default/tongue.gif)

我想起了以前的这条消息。
“50Gbps 到 100Gbps 左右的 DDoS”打到狐狸的网站的 CloudFlare 上也是家常便饭。
连他的网站都没事，那么凭什么一个测速网站就有这个能力呢？这不合理不是吗。

实际上这根本就不是 CloudFlare 的问题，的确就是 GFW 把这几个 IP 彻底墙掉了。

This post has been edited by VVFGV: Jun 20 2023, 13:18

....

我點回去看到的重點是這個
https://forums.e-hentai.org/index.php?s=&am...t&p=6250164

https://forums.e-hentai.org/index.php?showtopic=263742

異世界最後一次拍賣還有5個小時裝備報名截止，

想賣趕快拿出來歐

我多存了半年的 C 了
(IMG:[invalid] style_emoticons/default/rolleyes.gif)

水楼前面的 517页， 我有 tracert 测试。 如果是触发 GFW 的 网站 或 IP ，全部都是出不了国际网关就完蛋的。

但是 e-hentai.org 的 3个IP还是能到达 CloudFlare 。

你可以试一下各种必定触发 GFW 的 IP比如 Google 的IP ，
各个被墙的 网站域名， 都是出不了国际网关的。

既然GFW 没有触发 ， 那么只能是网站这边的问题了，
波萝没说要封大陆IP ，那就只有 CloudFlare 的问题了。

This post has been edited by peter723pan: Jun 20 2023, 13:56

水楼前面的 517页， 我有 tracert 测试。 如果是触发 GFW 的 网站 或 IP ，全部都是出不了国际网关就完蛋的。

但是 e-hentai.org 的 3个IP还是能到达 CloudFlare 。

你可以试一下各种必定触发 GFW 的 IP比如 Google 的IP ，
各个被墙的 网站域名， 都是出不了国际网关的。

既然GFW 没有触发 ， 那么只能是网站这边的问题了，
波萝没说要封大陆IP ，那就只有 CloudFlare 的问题了。

那篇回复我昨晚就已经拜读了，只是当时我看你是疑问句，因此我没有反驳。
那我连着那篇回复说明一下，指出到底有什么问题。

首先，traceroute 的本质是路由追踪，你无法通过单点去确认服务是否正常，因为这会受到中间设备的影响。
正常应该使用多点测试，否则单点有问题也可能是你 ISP 的问题。

问题就出在你的第四个验证步骤：

hosts文件指定正确IP , flushdns 后 ， 没有任何回避GFW检查的那些封包魔改，老实直连
(现在e-hentai.org的域名应该是在GFW列表里的，没魔改的封包一定触发GFW)

我分别用电信和移动的机器重新进行了你的操作四，在我这边是完全正常的。

移动：

CODE

root@chinamobile-sz:~# traceroute e-hentai.org
traceroute to e-hentai.org (104.20.135.21), 30 hops max, 60 byte packets
*(1-4跳为了避免信息泄露因此隐藏)
5  211.136.244.21 (211.136.244.21)  3.624 ms 120.197.29.113 (120.197.29.113)  4.518 ms *
6  111.24.5.29 (111.24.5.29)  9.696 ms * 111.24.5.217 (111.24.5.217)  3.892 ms
7  111.24.3.237 (111.24.3.237)  37.478 ms 111.24.3.25 (111.24.3.25)  34.921 ms 111.24.3.237 (111.24.3.237)  36.377 ms
8  221.183.89.41 (221.183.89.41)  33.996 ms 221.183.89.37 (221.183.89.37)  31.572 ms  32.701 ms
9  221.183.89.70 (221.183.89.70)  33.093 ms * 221.183.89.34 (221.183.89.34)  37.061 ms
10  221.183.89.181 (221.183.89.181)  37.202 ms 221.183.89.177 (221.183.89.177)  37.341 ms  37.256 ms
11  223.120.12.177 (223.120.12.177)  220.691 ms 223.120.14.145 (223.120.14.145)  218.850 ms 223.120.12.177 (223.120.12.177)  220.392 ms
12  223.120.6.70 (223.120.6.70)  220.482 ms  218.083 ms  218.455 ms
13  * 223.119.66.102 (223.119.66.102)  219.107 ms *
14  172.69.132.4 (172.69.132.4)  219.822 ms  217.380 ms 162.158.184.3 (162.158.184.3)  209.907 ms
15  * * *
16  * * *

电信：

CODE

vvfgv@MBP Downloads % sudo traceroute e-hentai.org
traceroute to e-hentai.org (104.20.135.21), 64 hops max, 52 byte packets
*(1-4跳为了避免信息泄露因此隐藏)
5  202.97.94.142 (202.97.94.142)  7.015 ms *
    202.97.90.206 (202.97.90.206)  4.638 ms
6  202.97.94.98 (202.97.94.98)  7.659 ms
    202.97.12.1 (202.97.12.1)  7.520 ms
    202.97.12.21 (202.97.12.21)  7.509 ms
7  202.97.25.134 (202.97.25.134)  172.695 ms
    202.97.43.242 (202.97.43.242)  169.862 ms
    202.97.25.134 (202.97.25.134)  169.487 ms
8  202.97.92.210 (202.97.92.210)  229.591 ms
    202.97.66.238 (202.97.66.238)  221.239 ms
    202.97.66.234 (202.97.66.234)  239.872 ms
9  218.30.54.46 (218.30.54.46)  225.782 ms  219.746 ms  218.164 ms
10  172.70.36.3 (172.70.36.3)  228.250 ms * *
11  * * *
12  * * *

我的两台机器就都顺利的到达了 CloudFlare 的 ASN 下。

可以试出，如果和GFW有关的话，像封IP一样没出国际网关就被阻断了。

那么你这点就不成立，因为你没有进行多点测试，这个问题也可能是你家网络的个例。
GFW 的封锁并没有你想的这么单纯，你要知道对于谷歌这类知名网站，GFW 的封锁策略是不一样的。

在 [zh.wikipedia.org] 维基百科 中，GFW 针对 IP 地址或传输层端口封锁就已经有足够明确的说明。

对拦截行为观察发现，在早期技术实现中，会使用访问控制列表（ACL）技术来封锁特定的IP地址，由此延伸可以封�
��传输层协议（TCP或UDP）的特定目的端口的网络流量[13]。不过由于大量的ACL匹配会导致网络性能不佳。现在主要是
采用了效率更高的路由扩散技术封锁特定IP地址，也就是通过将需要拦截的IP地址配置为空路由、黑洞设备或特别�
�置的自治域网络上，然后通过动态路由协议将相应配置路由扩散到公众互联网网络中，从将条件匹配拦截行为转�
�路由器的常规转发行为，从而提高拦截效率。多见于自主拥有大量IP地址段的需要审查的企业中，例如Facebook，Goog
le，Telegram，Twitter等。

谷歌之类被封锁导致出现类似 null route 的行为就是《路由扩散技术》。
因为谷歌拥有大量IP段需要审查，因此使用该技术可以更高效的进行封锁，因此基本上整个段都会 null 掉。
你可以自行验证，比如你拿到谷歌的一个必定被墙的 IP：142.250.207.99。
那你可以去 traceroute 142.250.207.1，照样也是 null route。

而针对 EH 的 CloudFlare IP 的封锁是针对单个 IP 所使用的 ACL 技术。
这也是 GFW 针对单个 IP 的封锁时使用的策略。
具体表现就是在大陆进行 traceroute 或者 mtr 能到达目标 IP 的上一跳，而无法到达目标 IP。
验证：EH 的 IP 是 104.20.135.21，那你去 traceroute 104.20.135.22，那它就一定是通的。

其实我比较建议你随便开一台机跑个比较危险的 fq 协议，第二天被墙了你就知道单 IP 被墙是什么特征了。

所以你的论证无法证明这是 CloudFlare 的问题，而这是完全符合 GFW 的封锁特征的。

This post has been edited by VVFGV: Jun 20 2023, 14:50

什么完全正常， 你会关注到 被SNI 检查的 e-hentai.org 直连失败，用的又是Linux ，
那么就是用了 w-md5 w-ack 之类骗过GFW检查的 数据包修改工具了。

我开工具也是 tracert e-hentai.org 正常出国际网关的呀。 你关工具测， 像 Google IP这类标准的 封IP 典型。
就是过不了国际网关的。

真正像Google一样被 封杀IP ，你开工具也一样是出不了国际网关。
你 trace 个 Google 的真实 IP 看看。
[mxtoolbox.com] https://mxtoolbox.com/SuperTool.aspx?action...mp;run=toolpage

This post has been edited by peter723pan: Jun 20 2023, 15:16

问题就出在你的第四个验证步骤：
我分别用电信和移动的机器重新进行了你的操作四，在我这边是完全正常的。

会不会是roll到的ip不一样导致的
我用517页的172.67.0.127也是tracert卡前一条，ping不通
但是用你用的104.20.135.21 tracert可以跑通，也能ping通，直连

CODE

curl https://104.20.135.21 -H "Host: e-hentai.org"

不带sni甚至有概率能访问到

This post has been edited by ccnan23: Jun 20 2023, 15:15

暂时可以通过自定义hosts e-hentai.org 178.162.139.18 恢复对表站的直连（可更换为 http://ehwiki.org/wiki/IPs 中 api.e-hentai.org 对应的任意IP）

From NiceBowl [t.me] https://t.me/ehviewer/2305080 .

This post has been edited by strongarm: Jun 20 2023, 15:48

什么完全正常， 你会关注到 被SNI 检查的 e-hentai.org 直连失败，用的又是Linux ，
那么就是用了 w-md5 w-ack 之类骗过GFW检查的 数据包修改工具了。

我开工具也是 tracert e-hentai.org 正常出国际网关的呀。 你关工具测， 像 Google IP这类标准的 封IP 模板。
就是过不了国际网关的。

真正像Google一样被 封杀IP ，你开工具也一样是出不了国际网关。
你 trace 个 Google 的真实 IP 看看。
[mxtoolbox.com] https://mxtoolbox.com/SuperTool.aspx?action...mp;run=toolpage

我不是很想拆你台，所以我才跟你一样用了 ICMP，没有用 tcping 去测试。
但你这回复甚至暴露了你连 ICMP 的报文到底包含了什么都不知道。

ICMP 报文通常不包含 SNI 信息的。ICMP 协议是用于传输控制消息的，主要用于网络诊断和错误报告。
它并不直接涉及传输层协议（如 TCP 和 UDP），也不在其报文中包含应用层协议的信息。

ICMP 报文主要是包含了与网络通信和控制有关的信息。
如果需要在网络中传输与应用层相关的信息，通常会使用应用层协议（如 HTTP）来完成，而不是使用 ICMP。

所以你的测试方法本身就是错误的，这跟系统无关，ICMP 的报文就是不包含 SNI。

会不会是roll到的ip不一样导致的
我用517页的172.67.0.127也是tracert卡前一条，ping不通
但是用你用的104.20.135.21 tracert可以跑通，也能ping通，直连

CODE

curl https://104.20.135.21 -H "Host: e-hentai.org"

不带sni甚至有概率能访问到

这个只能说也是个例，可能是 ISP 有劫持之类的。
你可以使用站长工具去全国 ping 一下，大陆基本上都是不通的。
但样本量大了就无法排除出现特殊情况。
EH 在 CloudFlare 中有 3 个 IP：
104.20.135.21
104.20.134.21
172.67.0.127
我随便拿了一个来测而已。

[ping.chinaz.com] https://ping.chinaz.com/104.20.135.21

This post has been edited by VVFGV: Jun 20 2023, 15:41

编辑掉：按楼下新来的意见，把可用IP地址的回帖删除了。

我不是很想拆你台，所以我才跟你一样用了 ICMP，没有用 tcping 去测试。
但你这回复甚至暴露了你连 ICMP 的报文到底包含了什么都不知道。

ICMP 报文通常不包含 SNI 信息的。ICMP 协议是用于传输控制消息的，主要用于网络诊断和错误报告。
它并不直接涉及传输层协议（如 TCP 和 UDP），也不在其报文中包含应用层协议的信息。

ICMP 报文主要是包含了与网络通信和控制有关的信息。
如果需要在网络中传输与应用层相关的信息，通常会使用应用层协议（如 HTTP）来完成，而不是使用 ICMP。

你不是说 一定是 GFW 封杀IP 嘛。

Google 的 IP 就是公认被 GFW 封杀IP 的， 你 trace 个结果看看呀。出不出得了国际网关。

This post has been edited by peter723pan: Jun 22 2023, 13:36

你不是说 一定是 GFW 封杀IP 嘛。

Google 的 IP 就是公认被 GFW 封杀IP 的， 你 trace 个结果看看呀。出不出得了国际网关。

你没有认真看我的回复，我再重新发一遍，请认真看完。

GFW 的封锁并没有你想的这么单纯，你要知道对于谷歌这类知名网站，GFW 的封锁策略是不一样的。

在 [zh.wikipedia.org] 维基百科 中，GFW 针对 IP 地址或传输层端口封锁就已经有足够明确的说明。
谷歌之类被封锁导致出现类似 null route 的行为就是《路由扩散技术》。
因为谷歌拥有大量IP段需要审查，因此使用该技术可以更高效的进行封锁，因此基本上整个段都会 null 掉。
你可以自行验证，比如你拿到谷歌的一个必定被墙的 IP：142.250.207.99。
那你可以去 traceroute 142.250.207.1，照样也是 null route。

而针对 EH 的 CloudFlare IP 的封锁是针对单个 IP 所使用的 ACL 技术。
这也是 GFW 针对单个 IP 的封锁时使用的策略。
具体表现就是在大陆进行 traceroute 或者 mtr 能到达目标 IP 的上一跳，而无法到达目标 IP。
验证：EH 的 IP 是 104.20.135.21，那你去 traceroute 104.20.135.22，那它就一定是通的。

封锁方法不一样，不要把 GFW 想的那么单纯，GFW 针对不同的情况有不同的封锁方法。

哦对，说明一下，null rotue（空路由）的特征就是像你 traceroute 谷歌的 IP 一样。
路由只到了城域网，没到国际出口就 null 了。

This post has been edited by VVFGV: Jun 20 2023, 15:32

你没有认真看我的回复，我再重新发一遍，请认真看完。
封锁方法不一样，不要把 GFW 想的那么单纯，GFW 针对不同的情况有不同的封锁方法。

哦对，说明一下，null rotue（空路由）的特征就是像你 traceroute 谷歌的 IP 一样。
路由只到了城域网，没到国际出口就 null 了。

谁都行， 在大陆 ， 不使用代理和VPN， 用 Google 的真实IP trace 一下，
一定是出不了国际网关的。这种和 Google 一样的情况 ， 才是真正被 GFW 封杀IP 。

编辑掉：按楼下新来的意见，把可用IP地址的回帖删除了。




This post has been edited by peter723pan: Jun 22 2023, 13:19

但是，这个本来用作 api 的 IP 虽然可以让你看画廊 ，但是论坛地址会被强制跳回画廊。

这个方法对论坛地址无用，上论坛还是得用代理。

论坛的源站地址是 94.100.18.243 。

EHWiki 的历史里存留的: https://ehwiki.org/index.php?title=IPs&...amp;oldid=53608 。

谁都行， 在大陆 ， 不使用代理和VPN， 用 Google 的真实IP trace 一下，
一定是出不了国际网关的。这种和 Google 一样的情况 ， 才是真正被 GFW 封杀IP 。

都说了，谷歌之类被封锁导致出现类似 null route 的行为就是《路由扩散技术》。
人家谷歌 ASN 下一堆 IP，要是跟 EH 一样用单 IP 封锁的 ACL 规则，那 GFW 的效率会很低。
而没有大量 IP 的网站，使用 ACL 对 IP 封锁的效率自然更高。
本身封锁方式都不一样，拿谷歌跟 EH 比本身就不合适。

如果你还是看不懂我前面的回复，或者硬要钻牛角尖，那我也没有必要继续回复你了，你说对就是对。
因为这样只会变成单纯的吵架，没有任何交流的价值。

This post has been edited by VVFGV: Jun 20 2023, 15:56

两位别吵了。再过一周如果IP还是被封锁，不就证明是GFW所为而不是Cloudflare嘛。等等罢。

This post has been edited by strongarm: Jun 20 2023, 15:57