海外用户说独立站打不开、加载慢？从DNS、线路到CDN的网络层排障

做出海独立站，最让人抓狂的一类问题是：海外客户来反馈“你的网站打不开”或者“慢得转圈”，你自己在国内或办公室一打开，好好的，啥事没有。

这类问题让无数人栽跟头，因为它压根不在你天天优化的那一层——它不是图片太大、不是代码太重，而是用户和你服务器之间那条看不见的网络链路出了岔子。

保哥这篇专门讲这种“别人打不开、你却正常”的网络层故障怎么系统排障：先建立一套从用户本地、到DNS、到跨境线路、到源站、再到CDN的分层心智，再一层一层教你怎么用ping、traceroute、dig这些朴素工具定位故障到底卡在哪一跳，怎么分清“真打不开”和“慢到用户以为打不开”，最后给一套可复用的排障流程和主动监控方案。一句话：页面优化解决的是“加载得快不快”，网络层排障解决的是“到底连不连得上”，后者是前者的地基，地基塌了，页面做得再漂亮也没人看得到。

海外用户说打不开、你自己却好好的，问题到底出在哪一层？

先讲个保哥几乎每隔一阵就会接到的求助。一个做外贸独立站的老板很着急，说有客户反馈网站打不开，眼看着询盘在掉，但他自己在办公室、在家里反复试，网站秒开，一点毛病没有。他第一反应是网站被黑了，或者程序出bug了，折腾了好几天代码，问题纹丝不动。

保哥让他先停手，问了几个问题：打不开的客户在哪个国家？什么时候打不开？是彻底连不上还是慢？答案出来，方向立刻就清楚了——是中东某个国家的客户、集中在当地晚上、表现为转圈半天最后超时。这根本不是代码问题，是用户到服务器那条跨境网络链路出了岔子。他在国内秒开，恰恰因为他走的不是那条出问题的路。

这就是出海独立站最容易让人栽跟头的一类故障：“别人打不开、你却正常”。它之所以难，是因为它不在你天天盯着优化的那一层。我们平时讲网站性能，讲的都是图片压缩、代码精简、缓存命中这些“页面层”的事——可这些解决的是“加载得快不快”的问题，前提是用户已经连上了你的服务器。而网络层故障要命就要命在：用户压根连不上，或者连接质量差到没法用，页面层的优化做得再好，用户也根本到不了那一步。

要排查这类问题，第一件事不是动手，是先在脑子里建一套分层的心智模型。一个海外用户打开你的网站，请求要穿过好几个环节，任何一环出问题都会表现为“打不开”或“慢”。保哥习惯把它拆成五层：

第一层，用户本地网络。用户自己的宽带、手机信号、路由器、当地运营商，这一层出问题你基本管不了，但要能识别出来，免得错把对方的网络问题当成你的。第二层，DNS解析。用户的浏览器得先把你的域名翻译成IP地址才能连，这一步解析失败、解析慢、解析到错误的IP，网站就打不开。第三层，跨境传输线路。用户的请求要跨越国境、经过一连串中间节点才能到你的服务器，这条路堵了、断了、绕远了，就慢或不通。

第四层，源站与防火墙。请求终于到了你这边，但你的服务器可能宕机了、资源耗尽了，或者防火墙、安全组、限流规则把这个用户的IP给拦了。第五层，CDN边缘节点。如果你用了CDN，用户实际访问的是离他最近的CDN节点，这个节点覆盖不到、回源失败、缓存出错，同样会出问题。

这五层就是后面排障的地图。排障的本质，就是从这张地图上一层层定位，把故障锁死在某一层，而不是大海捞针。有一点要先说清楚：这篇讲的网络可达性诊断，和保哥之前写的出海多店铺网络分段与IP隔离不是一回事——那篇讲的是为运营安全主动做IP隔离防关联，这篇讲的是用户访问不通时怎么被动排障，一个是攻、一个是守，别搞混。下面一层层拆。

怎么判断是“真打不开”还是“慢到用户以为打不开”？

动手查具体某一层之前，得先把现象分个类。因为“打不开”这三个字，用户嘴里说出来可能是两种完全不同的故障，排查方向也不一样。一种是真的连不上——连接超时、域名解析不了、直接报错；另一种是能连上，但慢得让人崩溃，转圈几十秒，用户没耐心等，关掉页面，回头跟你说“打不开”。这两种得先分开。

怎么分？让用户描述或截图看到的具体表现。如果是浏览器报“无法访问此网站”“找不到服务器IP地址”“连接已超时”，那是真的连不上，属于可达性问题，往DNS、线路、源站这几层查。如果是页面能出来一部分、或者一直在转圈最后才出来、或者首页打得开但点进去就卡，那更多是性能问题，往线路质量、源站响应、CDN命中这些方向查。两类的工具和思路有重叠，但侧重不同。

分完这两大类，再按几个维度给现象贴标签，这一步极其关键，能帮你大幅缩小范围：

按地区。是所有海外用户都这样，还是只有某个特定国家、地区？如果是全球普遍，问题大概率在你源站或DNS这种全局环节；如果只有某一个地区，那十有八九是那个地区的DNS解析、或者通往那个地区的某条跨境线路出了问题。按时段。是全天候持续，还是集中在某几个小时？有明显时段规律的，前面说过，多半是高峰期的线路拥塞。

按设备和网络。是所有设备都这样，还是只有手机、或只有某个浏览器？是宽带、流量都不行，还是只有某种网络环境出问题？这能帮你区分是普遍的服务端问题，还是和特定客户端环境相关。按错误信息。有没有具体的错误码或提示？反复出现同一个错误码（比如某种连接被拒绝、某种网关错误），往往直接指向某一层的具体故障。

保哥反复强调先做现象分类，是因为见过太多人跳过这步直接瞎改。一句模糊的“打不开”，可能是DNS、可能是线路、可能是防火墙，方向天差地别。把现象按可达性还是性能、按地区时段设备错误码分门别类贴好标签，你其实已经完成了排障里最重要的一半——剩下的，就是拿着工具去对应的那一层验证。这一步花十分钟问清楚，能省下后面几天的乱撞。

DNS这一层怎么查？

按访问的先后顺序，DNS是用户连上你网站要过的第一道关，也是特别容易出问题、又特别容易被忽略的一层。用户浏览器拿到你的域名，第一件事是去问DNS：这个域名对应的IP是多少？这个翻译过程一旦出岔子，后面全免谈，网站直接打不开。AWS — What is DNS?（亚马逊云对DNS递归解析全过程的权威讲解）把这个从浏览器一路问到权威服务器、再把IP返回来的递归解析全过程讲得很清楚，建议先把机制搞明白，查起来才有方向。

DNS这一层常见的故障有这么几类。第一，解析直接失败。域名压根解析不出IP，可能是你的域名NS记录配置错了、解析服务商出故障了、或者域名忘了续费过期了——别笑，域名过期导致全球打不开是真实高频事故。第二，解析到了错误的IP。比如你换了服务器，但DNS记录还指着旧IP，或者改了记录但TTL设得太长，全球各地的缓存还没刷新，部分用户还在访问旧地址。

第三，不同地区解析结果不一致。如果你用了GeoDNS（按用户地理位置返回不同IP，让用户就近访问），配置一旦出错，某个地区的用户可能被解析到一个根本不该给他的、或者已经下线的IP。第四，DNS污染或被劫持。在某些网络环境下，DNS解析可能被中间环节篡改，返回错误的IP，这种你很难根治，但要能识别出来。

查DNS的工具很朴素也很好用。命令行上，dig 和 nslookup 是基本盘，dig yourdomain.com 就能看到你的域名当前解析到什么IP、用的哪台DNS服务器、TTL是多少。但本地dig只能反映你这一个网络环境的解析结果，要查海外的，得靠在线的全球DNS检测工具——输入域名，它会列出全球几十个地区分别解析到的IP，一眼就能看出是不是某些地区解析异常、或者新改的记录在哪些地区还没生效。

排查DNS的标准动作是：先用全球检测工具看各地解析到的IP是否一致、是否都是你期望的正确IP；如果有地区不对，结合你最近有没有改过解析、TTL多长来判断是配置错误还是缓存未刷新；如果怀疑是GeoDNS策略问题，逐个地区核对返回的IP对不对。DNS问题往往是“全局性打不开”或“某地区集体打不开”的元凶，排障时值得优先排除，因为它查起来快、影响面又大。

从用户到你服务器这条线路怎么诊断？

DNS排除了，IP是对的，但用户还是连不上或者很慢，那问题大概率在第三层——从用户到你服务器之间那条跨境传输线路上。这是出海独立站故障的重灾区，也是最能体现“别人打不开你却正常”的一层，因为你和海外用户走的根本不是同一条路。诊断这条线路，靠两件经典工具：ping和traceroute。

先用ping看通不通、延迟多大、丢不丢包。ping yourdomain.com 会持续向你的服务器发小数据包并计时，你能看到三个关键信息：能不能收到回复（通不通）、往返一次要多少毫秒（延迟RTT）、发出去的包有多少没回来（丢包率）。

跨境访问，延迟天然比国内高（隔着大洋，物理距离摆在那），这正常；但如果延迟高得离谱（比如几百上千毫秒）、或者丢包率明显（比如丢了百分之十几），那这条线路质量就有问题了，慢和不稳定就是它造成的。要注意ping不通不一定是服务器挂了，很多服务器禁了ICMP，这点后面FAQ里细说。

再用traceroute看请求到底卡在哪一跳。ping只告诉你两端通不通，traceroute则把中间经过的每一个路由节点（每一跳）都列出来，并显示到每一跳的延迟。Wikipedia — Traceroute（逐跳测量到目标主机的路径与往返延迟的网络诊断工具词条）解释得很准：它逐跳报告沿途每个节点的往返时间，让你看清数据包到底走了哪条路、在哪一跳开始变慢或中断。

这是定位线路问题的利器——如果你发现前几跳都很快，到某一跳（通常是跨境的那个节点）延迟突然飙升或者直接超时不通了，那故障点就锁定在那里了。

比traceroute更好用的是 mtr，它相当于ping和traceroute的结合体，会持续地对每一跳采样，实时显示每一跳的丢包率和延迟波动。排查间歇性、波动性的线路问题时，mtr比跑一次traceroute信息量大得多——你能清楚看到是哪一跳在持续丢包，而不是只看一个瞬时快照。诊断跨境线路，保哥首选mtr。

这里有个出海特有的关键认知：跨境线路的拥塞往往有时段性。连接国内外的国际出口带宽是有限的共享资源，到了当地上网高峰，流量挤爆这几条链路，延迟和丢包就恶化，过了高峰又恢复。所以诊断线路一定要在用户反馈出问题的那个时段去测，并和正常时段对比——同一条线路，高峰和平峰跑出来的mtr可能天差地别。只在白天测、测出来正常就以为没事，是这一层最常见的误判。

线路问题定位到了，怎么解决？纯优化服务器是没用的，病根在路上。常见解法是让用户别走这条烂路——上一个在用户所在地有优质节点的CDN让他就近访问、把内容缓存到离用户更近的边缘、或者用专门的跨境优化线路。

线路这条链路的响应耗时，本质也体现在TTFB（首字节时间）里，保哥在TTFB与多层缓存对核心网页指标的影响那篇里拆过TTFB由哪些环节构成，web.dev — Time to First Byte (TTFB)（官方拆解TTFB＝重定向＋DNS解析＋连接与TLS＋请求＋首字节到达的总和）也把TTFB明确拆成了重定向、DNS、连接与TLS、请求这几段——线路慢，慢的就是这中间的连接和传输部分。

是不是源站或主机自己的问题？

线路也查了没大问题，那把目光收回到自己这头——第四层，源站和防火墙。请求确实到了你的服务器，但服务器这边可能没正常把它接住。这一层的故障，有的是服务器真出事了，有的更隐蔽：服务器活得好好的，却主动把海外用户拒之门外。

先看服务器本身的硬故障。最直接的是宕机或服务挂了——服务器关机、Web服务（nginx、Apache）崩溃没拉起来，那当然全员打不开，这种一般你自己也访问不了，好排查。更常见也更隐蔽的是资源耗尽：CPU跑满、内存吃光、磁盘写满、数据库连接数打满、带宽被占满。这种情况下网站时好时坏、慢得没规律，高并发时尤其明显。排查要去看服务器的资源监控——负载、内存、带宽、连接数这些指标在出问题的时段是不是异常飙高。

然后是这一层最容易坑人的部分：服务器活得好好的，却把海外用户的IP给拦了。这种“误杀”有好几个来源。一是服务器防火墙或云厂商的安全组规则，可能只放行了某些IP段，或者把某些海外IP段给封了。二是各种限流和防护机制——为了防攻击、防爬虫设的速率限制（rate limit）、连接数限制，规则定得太激进，会把正常的海外用户当成异常流量误伤。三是WAF（Web应用防火墙）或安全插件做了地理封锁，或者基于反向DNS、IP信誉库的判断，把某些地区、某些运营商的真实用户拦在门外。

保哥专门写过一篇nginx限流与反向DNS误拦的排查，讲的就是这类“好心办坏事”——你设的安全规则本意是挡坏人，结果把海外真实客户也挡了。

排查这类误拦，思路是：调出服务器的访问日志和防护日志，找出问题地区用户的请求被记成了什么——是被限流规则拒了（看到429、503），还是被WAF拦了，还是压根没到应用层就被防火墙在网络层丢弃了。把“被拦”和“没连上”区分开，是这一层排障的核心：日志里有这个IP的访问记录、但返回了拒绝码，说明请求到了被你拦了；日志里压根没有这个IP，那要么是防火墙在更底层丢了包，要么是请求根本没到你这层（回到线路问题）。

源站这层排障，养成查日志的习惯比什么都重要。很多“玄学打不开”，在访问日志和错误日志里其实写得明明白白——哪个IP、什么时间、请求了什么、被哪条规则用什么状态码拒了。日志是排障最诚实的证人，凭感觉猜十遍，不如认真读一遍日志。

CDN用了反而更慢或打不开，怎么回事？

很多人觉得上了CDN就万事大吉、海外访问自动变快，这是个美丽的误会。CDN用对了确实是出海加速的利器，用不对，反而会变成新的故障源。第五层，专门讲CDN自己可能出的问题。先说清CDN的基本逻辑：它在全球各地部署了很多边缘节点，把你的内容缓存到这些节点上，用户访问时被导向离他最近的节点，从而就近拿到内容、避开漫长的跨境回源。这套机制成立的前提，是“离用户近的节点”真的存在、并且真能服务他。前提不成立，CDN就帮倒忙。

第一类问题，节点覆盖不匹配。这是出海最常踩的坑。每家CDN的节点分布各有侧重，有的在欧美密、在新兴市场稀。如果你的主要客户在拉美、中东、非洲、或东南亚某些国家，而你选的CDN恰好在那些地方节点很少甚至没有，用户就会被导到一个很远的节点，绕一大圈，反而比不用CDN直连还慢。选CDN千万别只看它吹总节点数有几千个，要看它在你真实客户所在地到底有没有、有多少节点。

第二类问题，回源慢或回源失败。当用户请求的内容在边缘节点上没有缓存（缓存未命中），节点就得回你的源站去取，这个过程叫回源。

如果你的源站离CDN节点远、或者源站本身慢，首次访问、或者缓存失效后的访问就会很慢；要是源站宕了、或者CDN到源站这段链路断了，回源直接失败，那就是彻底打不开。所以CDN环境下排障，缓存命中率和回源是否正常是两个必看指标——命中率低，说明大量请求在回源，体验好不了；回源报错，那是硬故障。保哥在CDN缓存配置与边缘路由对SEO的影响那篇里详细讲过缓存命中和边缘路由该怎么配，这里不展开，但排障时这两个指标必须盯。

第三类，地理路由配错或节点故障。CDN靠一套调度逻辑把用户分配到合适的节点，这套逻辑万一配错，可能把用户导向错误的、很远的节点。还有就是CDN的某个具体节点临时出故障，而你的部分用户恰好就走这个节点，于是只有他们出问题，别的地区都正常——这种局部故障特别难自查，往往得靠CDN服务商的状态页或工单确认。

CDN这层的排障思路总结起来：先确认你的CDN在目标客户地区有没有足够节点（覆盖问题）；再看缓存命中率和回源状态（回源问题）；怀疑调度或节点故障时，查CDN控制台的节点状态、联系服务商核实。如果发现某家CDN在你的核心市场就是覆盖差、怎么调都不行，别死磕，换一家在当地节点更密的，或者对不同区域用不同的加速方案——CDN不是越大牌越好，是越贴合你客户分布越好。

一套可复用的海外可达性排障流程是什么？

前面把五层拆完了，现在把它们串成一套可以照着走的流程。排障最怕的就是没章法、东一榔头西一棒子，有了固定流程，再乱的故障也能有条不紊地定位。保哥常用的海外可达性排障，分五步走。

第一步，收集现象，建立画像。别一上来就动手。先问清楚：哪个地区？什么时段？什么网络和设备？是连不上还是慢？有没有错误码？能不能复现？这一步前面反复强调过，它直接决定后面往哪查。信息越具体，定位越快。

第二步，分层定位，逐层排除。按用户访问的顺序，从外往里一层层验证：先看是不是用户本地网络问题（多地区交叉验证，只有他一个人不行那可能是他自己的网）；再查DNS（全球解析检测）；再查线路（从目标地区跑ping/mtr）；再查源站（看资源监控和访问日志）；最后查CDN（看覆盖、命中率、回源）。每一层用对应的工具验证，能排除就排除，把范围一步步收窄，直到锁定故障在哪一层。

第三步，备好工具箱。这套流程要顺手，工具得齐：命令行的ping、traceroute/mtr、dig/nslookup、curl；在线的全球DNS检测、全球拨测/连通性测试工具；目标地区的海外测试节点（云服务器或拨测服务）；你自己服务器的资源监控面板和访问/错误日志。这些工具大多免费或很便宜，平时就配齐、用熟，故障来了才不至于现抓瞎。

第四步，定位后对症修复。不同层的故障解法完全不同：DNS配错就改解析、等TTL刷新；线路拥塞就上CDN、缓存边缘、换优化线路；源站资源耗尽就扩容、优化；防火墙误杀就调整规则、放行被误伤的IP段；CDN覆盖差就换或调。关键是修完一定要从目标地区复测验证，确认真的好了，别自己这头改完就以为完事。

第五步，也是最容易被跳过、却最该做的一步——建立主动监控。排障是被动救火，监控才是主动防火。用全球拨测类的监控服务，让它从世界各地定时访问你的站点，监测连通性和响应时间，一有异常立刻告警。这样下次还没等用户投诉，你就已经知道哪个地区、什么时候开始出问题了。从“等用户骂”到“提前发现”，这一步的价值，怎么强调都不过分。

海外可达性排障最容易踩的5个坑是什么？

最后照例上一份保哥的踩坑清单。这五个坑，是做出海运维的人几乎都踩过的，对照着看，能帮你少走很多弯路。

坑一：只用自己的网络环境下结论。这是头号大坑。你在国内、在办公室访问正常，完全不能代表海外用户正常——你们走的根本不是一条网络路径。海外可达性问题必须从海外那头测，用全球拨测工具、海外节点、或让真实当地用户帮测。拿自己这一个样本就说“没问题”，是这类故障最常见的误判源头。

坑二：把“慢”当成“服务器性能不行”，盲目升级硬件。很多人一遇到海外用户说慢，第一反应是服务器配置低了，咬牙升级，结果钱花了问题还在——因为病根在跨境线路或CDN覆盖上，不在你服务器的CPU内存。升级硬件前，先用mtr确认到底是线路慢还是源站慢，别把药开错了地方。

坑三：忽略时段规律。跨境线路高峰拥塞是出海特有的现象，白天测正常、晚上才出问题的故障太常见了。排查时一定要在用户反馈的那个时段、按对方的本地时间去复测，并和正常时段对比。只在自己方便的时间测一次就下结论，很可能完美错过故障窗口。

坑四：迷信CDN，以为装上就万事大吉。CDN用对了是加速器，用错了是故障源。节点不覆盖你的客户区、回源链路慢、缓存命中率低，都会让CDN帮倒忙。选CDN要看它在你真实客户所在地的覆盖密度，上线后要持续盯命中率和回源，而不是装上就再也不管。

坑五：没有主动监控，全靠用户投诉。这是最隐蔽、代价也最大的坑。海外可达性问题你自己日常感知不到，等用户来投诉，订单早就在流失了，而且绝大多数遇到打不开的用户根本不会反馈，直接走人。不做主动监控，你对海外的真实可用性就是两眼一抹黑。配一套全球拨测监控，成本很低，却能让你从被动挨打变成提前预警，是这五个坑里最该立刻补上的一个。

常见问题解答

海外用户说打不开，我自己访问正常，第一步该做什么？

第一步不是急着改配置，而是收集足够具体的现象信息，否则你连往哪查都不知道。要问清楚几件事：是哪个国家或地区的用户？大概什么时段出问题，是全天还是集中在某几个小时？用的什么网络（家庭宽带、手机流量、公司网络）、什么设备和浏览器？看到的是彻底打不开（连接超时、域名解析失败）还是能打开但慢得要命、转圈半天？最好让对方截个图或者拍个屏。这些信息直接决定了排查方向——如果只有某一个地区出问题，多半是DNS地域解析或跨境线路；如果集中在晚高峰，大概率是国际出口拥塞；如果某个错误码反复出现，可能是源站防火墙或CDN在拦。保哥的经验是，现象收集得越细，后面定位越快，最忌讳的就是拿着一句“打不开”就开始瞎猜、乱改配置，越改越乱。

我人在国内，怎么测海外用户访问我网站的真实情况？

核心办法是借用分布在海外的测试节点，别只用自己这一个网络环境下结论，那毫无代表性。最方便的是各类在线的全球拨测工具，它们在世界各地都有节点，输入域名就能看到从美国、欧洲、东南亚、中东等地区访问你站点的连通性、延迟、加载时间，有的还能跑全球DNS检测，一眼看出各地解析到的IP是否一致、正确。需要更深入，可以在目标地区开一台按量付费的云服务器，直接从当地访问、跑ping和traceroute，拿到最接近真实用户的数据。再不然，让海外客户或当地朋友帮你测一轮、截图反馈，也很实在。关键心态是：你在国内测一切正常，完全不能证明海外用户也正常，跨境链路上的问题，必须从海外那头测才看得见。

ping不通是不是就说明我的服务器挂了？

不一定，ping不通的原因有好几种，不能直接等同于服务器宕机。第一种确实是服务器或源站挂了、网络断了，最直接。但第二种很常见：服务器好好的，只是防火墙主动屏蔽了ICMP协议（ping用的就是它），很多服务器出于安全默认不响应ping，这时ping不通，但HTTP访问完全正常。第三种是中间某段网络（尤其跨境链路）丢包严重或被阻断，ICMP包到不了。所以ping不通时，别急着下“服务器挂了”的结论，要交叉验证：用浏览器或curl试试HTTP通不通、用traceroute看卡在哪一跳、从多个地区分别ping看是普遍不通还是只有某地不通。几个信号合在一起，才能判断到底是源站、线路的问题，还是单纯ICMP被禁的假象。

上了CDN，为什么海外访问反而更慢、甚至打不开了？

CDN不是装上就一定快，用不好反而添乱。常见原因有几类。一是节点覆盖不匹配：你选的CDN在主要客户所在地（比如拉美、中东、非洲、东南亚某些国家）节点稀疏甚至没有，用户被导到很远的节点，绕一大圈，比不用CDN还慢。二是回源出问题：请求的内容节点上没缓存（未命中），要回源站取，源站离得远或本身慢，首次访问就很慢；回源失败就是打不开。三是地理路由配错，把用户导向了错误节点。四是某个节点临时故障，恰好你的用户走的就是它。排查思路：先确认CDN在目标客户地区有没有、有多少节点；再看缓存命中率和回源是否正常；必要时换一家在目标市场节点更密的。选CDN一定要看它在你真实客户所在地的覆盖，而不是看总节点数有多唬人。

晚上海外用户反馈慢、白天又正常，是什么原因？

这种有明显时段规律的卡顿，十有八九是跨境线路在高峰期拥塞，不是你服务器的问题。原理不难懂：连接国内外的国际出口带宽是有限的共享资源，到了当地上网高峰（按对方本地时间算），大量流量挤在这几条国际链路上，像晚高峰的高速公路，带宽占满，延迟飙升、丢包增加，网站自然就慢了；白天人少路通畅，就恢复正常。判断方法：在出问题和正常的时段，分别从目标地区跑traceroute或mtr，对比延迟和丢包是不是在某一跳（通常是跨境那几跳）高峰时明显恶化。确认是线路拥塞，纯优化服务器治不好，得从链路想办法——上一个当地节点充足的CDN让用户就近访问、把静态资源缓存到边缘减少跨境回源。这类问题最容易被误判成“服务器性能不行”，结果升级一圈也没用，因为病根在路上不在家里。

要不要花钱做网站的全球可用性监控？还是等用户反馈就行？

强烈建议做主动监控，别等用户反馈。道理很简单：等用户来投诉，意味着问题已经发生、订单已经在流失，而且会主动反馈的是极少数，大量遇到打不开的人会直接默默关掉页面去找别家，你永远不知道损失了多少。海外可达性问题又恰恰是你日常根本感知不到的——你在本地一切正常，问题发生在你看不见的远端，没有监控你就是个瞎子。做法是用全球拨测类监控服务，让它从世界各地定时访问你的站点，监测连通性、响应时间、关键页面是否正常，一旦某地异常或某指标超阈值，立刻邮件或消息通知你。这类服务有免费基础档，对中小站点够用，投入很低。配起来，你就能在用户大面积受影响之前，第一时间知道哪个地区、什么时候开始出问题，从被动救火变成主动发现，性价比非常高。

权威参考资料