软路由阿里云官网打开特别慢可能是什么问题? - V2EX
V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
naoh1000
V2EX    宽带症候群

软路由阿里云官网打开特别慢可能是什么问题?

  •  
  •   naoh1000 2020-10-11 00:35:46 +08:00 4591 次点击
    这是一个创建于 1833 天前的主题,其中的信息可能已经有所发展或是发生改变。

    别的网站都没问题,就阿里云官网打开特别慢,五分钟才能加载出来一个网页,感觉比上个世纪网速还慢,看连接速度只有 2KB/S,研究了半年还没解决。软路由魔法上网软件装了一直没开,所有设备都是一样的情况,用 4G 就能正常打开。请问可能是什么问题?

    第 1 条附言 nbsp;  2020-10-12 09:27:26 +08:00
    另外我的路由器在进行大量传输时(例如连续一小时通过 clash 向 Google Drive 上传数据(跑满 300M 宽带)会间歇断网(每 40~50 分钟热点消失一分钟)不知道和这个问题是否有关。
    20 条回复    2020-10-25 20:06:45 +08:00
    mason961125
        1
    mason961125  
       2020-10-11 00:37:05 +08:00
    检查 iptables,有没有开 SNAT,path mtu discovery 开了没。
    Tianao
        2
    Tianao  
       2020-10-11 02:03:19 +08:00 via iPhone
    建议首先检查 DNS……
    brMu
        3
    brMu  
       2020-10-11 07:09:05 +08:00 via Android
    我也遇到下类似的问题,好像每次卡在 dns 解析上,但改了 dns 也不管用,不知道什么鬼,好像就是阿里的 cdn 域名问题
    yingfengi
        4
    yingfengi  
       2020-10-11 10:13:49 +08:00 via Android
    看看 DNS 。。
    和 NAT 有毛关系,不做 NAT 你怎么上网
    Tink
        5
    Tink  
    PRO
       2020-10-11 10:39:14 +08:00 via Android
    alicdn
    tifan
        6
    tifan  
       2020-10-11 11:49:05 +08:00
    检查接口上的 MTU,并适当设置 adjust mss

    Cisco IOS 等价物:

    ```
    interface TenGigabitEthernet0/3/0
    ip tcp adjust-mss 1374
    ```

    修改 1374 为对你合适的值(扣掉 encapsulation overhead ) 计算器: https://baturin.org/tools/encapcalc/
    aru
        7
    aru  
       2020-10-11 13:02:41 +08:00
    可能被解析到国外节点了。执行下面命令,如果延时超过 100 就不对了
    ping g.alicdn.com
    masker
        8
    masker  
       2020-10-11 14:01:46 +08:00 via Android
    sfe 设置一下 DNS
    naoh1000
        9
    naoh1000  
    OP
       2020-10-11 17:56:24 +08:00
    @aru 跑到日本了
    ping g.alicdn.com

    Pinging g.alicdn.com.danuoyi.alicdn.com [47.246.4.254] with 32 bytes of data:
    Request timed out.
    Reply from 47.246.4.254: bytes=32 time=293ms TTL=47
    Reply from 47.246.4.254: bytes=32 time=296ms TTL=47
    Reply from 47.246.4.254: bytes=32 time=292ms TTL=47

    Ping statistics for 47.246.4.254:
    Packets: Sent = 4, Received = 3, Lost = 1 (25% loss),
    Approximate round trip times in milli-seconds:
    Minimum = 292ms, Maximum = 296ms, Average = 293ms


    @masker
    @yingfengi
    @brMu
    @Tianao
    @Tink
    感谢回复,因为平常访问的绝大多数网站都是国外网站所以路由器和电脑设置的 DNS 都是 Google 的 8.8.8.8 和 dns.google,不知道和这个是否有关?
    tifan
        10
    tifan  
       2020-10-11 20:30:37 +08:00
    @naoh1000 这样听起来是个典型的 mtu 问题。按 #6 排查
    naoh1000
        11
    naoh1000  
    OP
       2020-10-11 23:01:42 +08:00
    @tifan 感谢您的回复,我家网络是 500Mbps 光纤->联通送的光猫->路由->软路由,每个设备 MTU 设置好像都是 1500 。
    您的回答前端程序员有点表示看不懂。查了一些资料,有一些疑问:
    1. 使用您提供的计算器,请问应该怎么选择?(应该把需要用上的 Ethernet, IPv4, IPv6, TCP, UDP 都选上吗?)
    2. 我按照 Netgear KB 中的一篇文章 https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router 测出我的最大不被切割包大小是 1472,+28 就是 1500,这样好像默认的 1500 就没有问题。
    3. 请问应该修改每一个网络设施的 MTU 还是修改软路由的就可以?软路由应该修改 WAN 还是 LAN 接口的 MTU 呢?
    tifan
        12
    tifan  
       2020-10-11 23:43:32 +08:00
    @naoh1000 注意如果你设置了翻墙隧道,那么这个隧道本身的 MTU 会降低(因为隧道 encapsulate 的 overhead )

    可以试试 ping 到随便一个什么走了你的隧道的 IP 就可以了。

    MTU 设置正确后,如果路由器 NAT 时没有修改 MSS 那么应该额外设置一条防火墙策略修改 MSS,使其降低到目标值。

    你描述的故障一般是机器 pmtu discovery 出了问题或者屏蔽了 icmp 之类的导致的,但是根治还是修改 MSS 。

    如果你是 openwrt,尝试用 mtu_fix <https://openwrt.org/docs/guide-user/firewall/firewall_configuration> 或配合 iptables "clamp-mss-to-pmtu" 选项。

    如果你是 RouterOS -- https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Mangle#Change_MSS
    aru
        13
    aru  
       2020-10-12 06:55:30 +08:00
    @naoh1000
    国内的网站要用国内的 dns 进行解析。你这个问题和 mtu 什么的没关系,就是由于使用了国外的 dns,阿里云被解析到日本的节点了,所以连接缓慢。
    naoh1000
        14
    naoh1000  
    OP
       2020-10-12 09:17:36 +08:00
    @tifan 感谢您的回复,请问可以回答一下我在#11 提出的疑问吗?

    @aru 我所有设备的 DNS 都是 8.8.8.8 为什么解析到日本呢?解析到日本也不至于 2KB/S 吧
    hadoop
        15
    hadoop  
       2020-10-12 09:54:06 +08:00
    @naoh1000 你在国内,所有 dns 都是 8.8.8.8 就不对啊,阿里云这个只是表象,肯定还有很多国内其他网站也慢。根据 ip 来分流吧
    jitdor
        16
    jitdor  
       2020-10-12 13:29:04 +08:00
    因为 DNS 返回离节点较远的 CDN 服务器啊
    tifan
        17
    tifan  
       2020-10-14 16:50:49 +08:00
    @naoh1000

    > 1. 使用您提供的计算器,请问应该怎么选择?(应该把需要用上的 Ethernet, IPv4, IPv6, TCP, UDP 都选上吗?)

    你如果使用了山寨隧道协议,请读源代码进行计算。简单的说,需要 1500 - 8 <PPP, 若使用了 PPP> - 20 <TCP> - (20 <TCP> | 8 <UDP>) - [tunnel overhead]

    如果算不出来,可以用 ping 的方法测试,注意目标是经过隧道的地址

    > 2. 我按照 Netgear KB 中的一篇文章 https://kb.netgear.com/19863/Ping-Test-to-determine-Optimal-MTU-Size-on-Router 测出我的最大不被切割包大小是 1472,+28 就是 1500,这样好像默认的 1500 就没有问题。

    这只是对于你的原生流量来说的,你的隧道协议本身也有开销

    > 3. 请问应该修改每一个网络设施的 MTU 还是修改软路由的就可以?软路由应该修改 WAN 还是 LAN 接口的 MTU 呢?

    请在路由器的防火墙功能里修改 TCP MSS (#12 ),或者是修改你的隧道接口的 MTU,不是 WAN 也不是 LAN 。

    如果实在不会修改,修改电脑里的 MTU 降低(不建议)。
    naoh1000
        18
    naoh1000  
    OP
       2020-10-14 17:27:57 +08:00
    @tifan 我目前没有使用路由器翻墙,用的是 Proxifier+Clash 翻墙,请问需要修改路由器 MTU 吗?我的路由器系统是 OpenWRT,在您提供的文章中找不到修改隧道接口 MTU 的方法,只找到一个 bool 值的 fix 。
    chelly233
        19
    chelly233  
       2020-10-14 20:19:02 +08:00
    1,阿里云访问缓慢是 DNS 的原因,国外的 DNS 在国内并不好用

    可以考虑使用国内公共 DNS 或者运营商 DNS

    2,clash 极其吃性能,断网可能是过热,可以考虑换其他的魔法软件
    opengps
        20
    opengps  
       2020-10-25 20:06:45 +08:00 via Android
    最近调试对象存储的域名大小,用百度 dns 访问阿里相关东西几乎是灾难,总得刷新几次才勉强可用
    关于     帮助文档     自助推广系统     博客     API     FAQ     Solana     2671 人在线   最高记录 6679       Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 24ms UTC 01:13 PVG 09:13 LAX 18:13 JFK 21:13
    Do have faith in what you're doing.
    ubao msn snddm index pchome yahoo rakuten mypaper meadowduck bidyahoo youbao zxmzxm asda bnvcg cvbfg dfscv mmhjk xxddc yybgb zznbn ccubao uaitu acv GXCV ET GDG YH FG BCVB FJFH CBRE CBC GDG ET54 WRWR RWER WREW WRWER RWER SDG EW SF DSFSF fbbs ubao fhd dfg ewr dg df ewwr ewwr et ruyut utut dfg fgd gdfgt etg dfgt dfgd ert4 gd fgg wr 235 wer3 we vsdf sdf gdf ert xcv sdf rwer hfd dfg cvb rwf afb dfh jgh bmn lgh rty gfds cxv xcv xcs vdas fdf fgd cv sdf tert sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf sdf shasha9178 shasha9178 shasha9178 shasha9178 shasha9178 liflif2 liflif2 liflif2 liflif2 liflif2 liblib3 liblib3 liblib3 liblib3 liblib3 zhazha444 zhazha444 zhazha444 zhazha444 zhazha444 dende5 dende denden denden2 denden21 fenfen9 fenf619 fen619 fenfe9 fe619 sdf sdf sdf sdf sdf zhazh90 zhazh0 zhaa50 zha90 zh590 zho zhoz zhozh zhozho zhozho2 lislis lls95 lili95 lils5 liss9 sdf0ty987 sdft876 sdft9876 sdf09876 sd0t9876 sdf0ty98 sdf0976 sdf0ty986 sdf0ty96 sdf0t76 sdf0876 df0ty98 sf0t876 sd0ty76 sdy76 sdf76 sdf0t76 sdf0ty9 sdf0ty98 sdf0ty987 sdf0ty98 sdf6676 sdf876 sd876 sd876 sdf6 sdf6 sdf9876 sdf0t sdf06 sdf0ty9776 sdf0ty9776 sdf0ty76 sdf8876 sdf0t sd6 sdf06 s688876 sd688 sdf86