V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
Foxkeh
0.01D
V2EX  ›  宽带症候群

阿里云虚假宣传,武汉本地地域实际出口为杭州

  •  
  •   Foxkeh · 1 天前 · 2687 次点击

    起因是在服务器上做网络延迟测试的时候发现外省的延迟比湖北的还低,不然还一直被蒙在鼓里。。

    根据选购说明里面说的是

    “用户和资源部署地域的距离越近,网络时延越低,访问速度越快。建议您基于业务场景对时延的要求选择地域。”

    https://help.aliyun.com/zh/simple-application-server/product-overview/regions-and-network-connectivity

    实际上我用 itdog 拨测时发现三网出口都是浙江杭州,三网 ping 延迟都超过 30ms ,但是浙江杭州宁波温州都在 20ms 以下,心里就有不好的预感了。

    工单反馈后,售后工程师回电表示没有跟武汉本地做 BGP 连结,承认是杭州出口。武汉本地是方便有的企业单位政策要求服务器必须在武汉。

    感觉好恶心。7 月份的时候影响我的购买决策,早知是这个样我还不如直接买上海节点少绕路。

    大伙评评理,这个气人不?我该怎么维权?

    第 1 条附言  ·  1 天前
    漏说了重要的一点:亲测从武汉本地访问,也是绕路杭州。并不是说武汉市本地就是直连路由了
    41 条回复    2025-12-05 23:13:48 +08:00
    Yserver
        1
    Yserver  
       1 天前
    这还好吧 本地地域出口是别的地方我记得在哪里看过
    pingdog
        2
    pingdog  
       1 天前 via Android
    维不了,合同条款豁免了,当然你一定要讨说法:按闹分配
    busier
        3
    busier  
       1 天前 via iPhone
    “ 武汉本地是方便有的企业单位政策要求服务器必须在武汉。”

    真的假的,数据出境的层层加码地方版本么?
    BlueSkyXN
        4
    BlueSkyXN  
       1 天前
    物理位置武汉 不等于 网络出口武汉
    BlueSkyXN
        5
    BlueSkyXN  
       1 天前   ❤️ 2
    @BlueSkyXN
    其实阿里已经明确标了“本地地域”,只不过没有过多的说明,而且没标的也有问题
    但是对于每一个区的有接入点确实有文档

    https://help.aliyun.com/zh/oss/user-guide/regions-and-endpoints

    比如
    武汉本地 oss-cn-wuhan-lr.aliyuncs.com
    福州本地 oss-cn-fuzhou.aliyuncs.com
    这两个网络都在杭州
    南京本地的倒是在南京 oss-cn-nanjing.aliyuncs.com
    没标的内蒙古实际上入口在北京 oss-cn-wulanchabu.aliyuncs.comoss-cn-huhehaote.aliyuncs.com
    没标的张家口实际上入口也是北京 oss-cn-zhangjiakou.aliyuncs.com

    有点抽象,没验证还真不知道
    Foxkeh
        6
    Foxkeh  
    OP
       1 天前
    @busier 工单售后工程师打电话说的,大概是这么个意思
    lcy630409
        7
    lcy630409  
       1 天前
    啊 你本地 ping 多少延迟呢
    我的阿里云 ip 归属地是杭州 但是实际在武汉 延迟 3ms
    yyzh
        8
    yyzh  
       1 天前
    习惯就好.例如阿里的河源你就当价格便宜点的深圳就是.
    lcy630409
        9
    lcy630409  
       1 天前
    你给个同网段 ip 我试一下
    Foxkeh
        10
    Foxkeh  
    OP
       1 天前
    @lcy630409

    武汉电信和武汉联通 PING 账号里的三个本地地域服务器都是都是 30ms+,使用 OpenTrace 均显示绕杭州
    Foxkeh
        11
    Foxkeh  
    OP
       1 天前
    @lcy630409

    试试
    8.148.72.1
    8.148.73.1
    pigspy
        12
    pigspy  
       1 天前
    啊这?我们正在调研阿里云的公网出口能力呢,结果居然有的地方是虚标吗?
    hqt1021
        13
    hqt1021  
       1 天前 via Android
    服务器在武汉,但是出口绕杭州
    xyz3210
        14
    xyz3210  
       1 天前
    这网络对我没用!对于海外用户,只要是中国的 ip 不使用科学的话都是垃圾
    opengps
        15
    opengps  
       1 天前
    有个最不好说明白的问题,就是网络上的远近跟实际物理远近并不一致。论骨干网络确实是杭州距离各个地方“都近”
    mytsing520
        16
    mytsing520  
    PRO
       1 天前
    很正常。。

    武汉目前不允许做 BGP 接入,所以,网络在其他地方
    但要满足有些客户数据在本地的要求

    其他公有云某些地域也是如此,北上广这种地方地价太贵了,托管到隔壁省份,走本地出口这样
    mytsing520
        17
    mytsing520  
    PRO
       1 天前
    更正,看了一下路由追踪情况

    应为 IP 地址和机器都在武汉,但走的是杭州的接入,而武汉不允许做 BGP
    Devifish
        18
    Devifish  
       1 天前
    阿里的 IPv6 的出口好像都会绕到上海
    dsx826
        19
    dsx826  
       1 天前 via Android
    投诉湖北政府,快建立 wuhan ix
    docx
        20
    docx  
       1 天前 via iPhone
    这种设计的意义是什么,难道就为了数据存在特定城市?
    mytsing520
        21
    mytsing520  
    PRO
       19 小时 30 分钟前   ❤️ 1
    @docx
    湖北至少有一个非常大的客户足够让阿里云在湖北建立机房,可能是地方规定要求数据保存在本地,并且当地未来有足以覆盖部署成本的可能性
    在这基础上,部署在武汉则是因为,武汉可以满足建设这个机房的所有要求

    之前他们在南京、福州部署本地地域也是类似的原因,但很显然,这两个地区部署后,并没有使阿里云能够覆盖部署的成本
    dode
        22
    dode  
       18 小时 59 分钟前
    惨,武汉都没有 BGP
    MelodYi
        23
    MelodYi  
       18 小时 44 分钟前
    好像挺常见的。华为云上海 region 实际上在苏州。
    lcy630409
        24
    lcy630409  
       18 小时 41 分钟前
    @Foxkeh
    没问题的 我这是武汉电信,可以看到这就是在武汉,不过这个 ip 的归属地是
    IP Geolocation
    City Hangzhou
    State Zhejiang ,这个应该是把 ip 换地方 ip 归属 还没更新而已

    lcy630409
        25
    lcy630409  
       18 小时 37 分钟前
    物理位置就在这
    Goooooos
        26
    Goooooos  
       18 小时 15 分钟前
    OP 还是要搞清楚才来喷
    crc8
        27
    crc8  
       18 小时 5 分钟前
    @BlueSkyXN 华为云的内蒙古也是北京。
    whobuki
        28
    whobuki  
       18 小时 0 分钟前
    看着在杭州应该是 ip 数据库的问题,这机器肯定是在武汉本地的,武汉电信访问这个可用区 ping 一直是个位数。
    这东西恶心在三网只优化了电信,移动访问要从上海绕路,能跑出直连上海阿里云两倍的延迟
    Foxkeh
        29
    Foxkeh  
    OP
       17 小时 52 分钟前
    @lcy630409

    你这个结果这么厉害么, 我从家里(武汉电信)和公司(武汉联通)PING 到节点,都是 30ms+

    下面是刚从武汉联通跑 OpenTrace

    ![wW0jwVtuI5EuzqT5ydGgCIf1iQazOyml.webp]( https://cdn.nodeimage.com/i/wW0jwVtuI5EuzqT5ydGgCIf1iQazOyml.webp)

    ![oCyuL9NR8EaDei2M9dkKrojL4d4tSPEt.webp]( https://cdn.nodeimage.com/i/oCyuL9NR8EaDei2M9dkKrojL4d4tSPEt.webp)

    使用 itdog 拨测的结果, 武汉三网测试节点到服务器也都是 30ms+, 浙江测试节点反而更低一些
    https://cdn.nodeimage.com/i/L9IX6th3o19kXO5FzaXx6lSLtnoJqYDa.webp



    @Goooooos

    不至于,没有数据支撑的话也不会发上来,毕竟 V2 发了贴没法删
    lcy630409
        30
    lcy630409  
       17 小时 43 分钟前
    他服务器确实是在武汉,实在不行 协商退款?
    百度的武汉地域 会绕到南京跑一圈回来
    腾讯没有武汉
    如果你想要武汉机器 只能找找其他云 或者 机房了
    crc8
        31
    crc8  
       17 小时 31 分钟前
    @lcy630409 这就有点科幻了,有没有可能是云服务器线路都要去杭州,而本地网络直接访问?
    hubaq
        32
    hubaq  
       14 小时 34 分钟前
    看了一下,武汉电信入走了杭州,回程走武汉电信,其他二家貌似绕道杭州
    hubaq
        33
    hubaq  
       14 小时 30 分钟前
    @mytsing520 问了,就是你猜的,大客户要求
    MindMindMax
        34
    MindMindMax  
       13 小时 28 分钟前
    确实是电信路由到了杭州地区,在杭州和嘉兴之间的某数据中心。
    MindMindMax
        35
    MindMindMax  
       13 小时 24 分钟前
    @lcy630409 不对的,看延迟明显不对。嘉兴路由到段内 8.148.72.1 仅个位数毫秒。。。
    mytsing520
        36
    mytsing520  
    PRO
       12 小时 52 分钟前
    @hubaq
    这都不用猜,爱奇艺和海尔也是这样,他们在北京和青岛各自有个专属的可用区
    cheshirex
        37
    cheshirex  
       12 小时 13 分钟前
    可以联系官方给你迁移到上海或者杭州去。
    crc8
        38
    crc8  
       12 小时 9 分钟前
    @cheshirex 我估计 OP 是想迁移到武汉。
    Foxkeh
        39
    Foxkeh  
    OP
       11 小时 48 分钟前
    @cheshirex 我再工单联系看看


    @crc8 嗨,别说了,7 月份从杭州迁到武汉的以为会更近些.
    crc8
        40
    crc8  
       11 小时 4 分钟前
    @Foxkeh 哈哈哈,肉身移汉,魂在西湖。
    bclerdx
        41
    bclerdx  
       4 小时 47 分钟前
    @hqt1021 你是说物理服务器在武汉本地,但该服务理服器的网络出口在杭州?
    关于   ·   帮助文档   ·   自助推广系统   ·   博客   ·   API   ·   FAQ   ·   Solana   ·   891 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 25ms · UTC 20:01 · PVG 04:01 · LAX 12:01 · JFK 15:01
    ♥ Do have faith in what you're doing.