服务器带宽被占用，防盗链和限速哪个先做

带宽被占满的表现很好认：流量图一路平顶、用户反馈图片加载慢、账单比上个月翻了几倍。而看到这个现象就去开防盗链，是很多人第一反应，结果配完一圈发现带宽还是满的，因为吃流量的根本不是外站盗链，而是自己的程序在跑批量任务，或者是某个接口被高频调用。

防盗链和限速解决的是完全不同的问题。防盗链管的是「别人能不能引用你的资源」，限速管的是「流量消耗速度有没有上限」。前者是身份识别，后者是速率控制，混着用就会出现「配了防盗链但带宽依然爆」的情况。

所以判断的第一步不是选手段，而是先确定流量到底流向了谁。

下面按这个顺序讲：先说清三种吃带宽的原因怎么区分，再讲防盗链和限速各自管什么、怎么配，然后讲两种手段的先后顺序，最后说清带宽套餐该怎么选才不至于每个月都超额。

上面这些落到实际，终究要挑一台机器来跑——这几家都是云服务器里比较有代表性的，4 家可选，价格从 22 元拉到 43 元

分维度统计流量要先有准确的用量数据，所以方案得把带宽和流量分开计。sixtynet那几档把端口速率和流量额度分别标出来，看两个约束哪个先到顶很直接。

先分清三种吃带宽的原因

统计数据的时候要注意时间窗口，一天的日志可能正好赶上推广或者攻击，得出来的结论会失真，至少要取一周的数据，并且把异常的那几天单独标出来，看平时的基线是什么样。判断方法是先画七天的曲线再决定用哪几天做分析。

还有一点是流量的方向要分开看，很多人只盯着出向流量，忽略入向也可能是瓶颈，比如用户上传大量文件或者在做往内拉取的大任务，入向同样会占满线路。判断方法是分别看出向和入向的曲线。

第一种是外站盗链，别人在自家网站上直接引用你这台服务器上的图片、视频或者下载文件，访问量发生在别人那里，流量却从你的机器出去，这类流量的特征是有大量请求带着外来页面的来源标识，而且请求集中在少数几个大文件上。判断方法是按来源页面分组统计流量，看有没有陌生域名占了显著比例。

第二种是本站在被高频访问，可能是内容被推荐了、可能是在做推广、也可能是被采集或攻击，这类流量的特征是请求来自大量不同来源，但抓的都是你站点上的正常资源，从行为上看着像正常用户。判断方法是看来源地址的分散程度，分散就说明是真实访问而不是单点占用。

第三种是自己的程序在跑流量，比如备份任务把数据传到异地、日志同步、批量下载第三方资源、或者某个定时任务在拉取大文件，这类流量的特征是来源就是本机、时间高度规律、且每次的量和往常接近。判断方法是看服务端发出的连接，找出是哪个进程在往外传。

还有一种混合情况是多个原因叠加，比如既被盗链又在被采集，这时候看总量只会看到一个平顶，必须分维度拆开才能定位。判断方法是同时按来源页面、来源地址、进程三个维度分别统计一次。

区分的关键是「流量流向了谁」，盗链是流向外站访客、正常访问是流向本站访客、程序流量是流向某个固定的对端，三者的流向完全不同，看流向比看总量有效。判断方法是在监控里看目的地址的分布。

如果监控只能看总量，那就从日志入手，访问日志能给出请求的资源、来源页面、来源地址，把这三个字段分组统计，通常十分钟就能看出主因是哪一种。判断方法是先导一天日志做分组，不要凭印象猜。

防盗链管的是什么

配置防盗链时还有一类请求要特别放行：资源检查工具和部分安全扫描服务会带着异常的来源标识访问，如果被拦下来，反而会让你误以为是站点故障。判断方法是在日志里找这类请求的特征并加进白名单。

防盗链的本质是判断请求是不是从自己的页面发起的，常见做法是检查请求头里的来源页面字段，如果来源为空或者不是自己站点的域名，就拒绝或者返回替代内容。判断方法是看这个字段能不能被伪造，能伪造就说明它只挡得住君子。

这个判断方式有一个天然的弱点：来源页面字段完全由客户端控制，随便写一个就能绕过，所以防盗链挡不住有技术能力的盗链方，但能挡住占绝大多数的简单复制粘贴行为。判断方法是拿一个能改请求头的工具试一下，看规则是否被绕过。

更可靠的做法是给资源加签名，每次请求必须带一个有时效的签名参数，签名由服务端生成，没有签名就无法访问，这种方式无法伪造但需要改业务代码，成本比判断来源字段高得多。判断方法是看资源访问是否都走应用层生成链接。

还有一种折中做法是设置资源地址的有效期，链接生成后一段时间内可用，过期失效，这样即使被复制出去也只能短时间使用，适合付费内容或者临时下载。判断方法是看业务能否接受链接过期带来的体验损失。

防盗链只对「资源被外部引用」这一种情况有效，它管不到本站被高频访问，因为那种情况下请求本来就来自真实用户，来源标识完全合法，规则会全部放行。判断方法是看配了防盗链之后带宽有没有下降，没降就说明原因不在这。

配防盗链时还有一个细节要注意：要放行搜索服务和自家的小程序、App，这些请求的来源标识往往为空或者是特殊值，一刀切会误伤，导致收录下降或者客户端功能异常。判断方法是先列一份白名单再上线。

限速管的是什么

限速的实现位置也影响效果，配在反向代理层最快最省资源，配在应用层能拿到更多上下文但会消耗服务器处理能力，配在网络设备上最彻底但改起来最麻烦。判断方法是按现有架构选最靠前的一层。

还要注意限速和连接数限制的区别，限速管的是速率、连接数限制管的是同时有多少个请求，两者解决的问题不同，请求很小但很频繁的场景需要的是连接数限制而不是限速。判断方法是看单个请求的大小和频率。

限速的本质是给流量消耗设一个上限，超过就延迟或者拒绝，它不关心请求是谁发的，只关心速度有多快。判断方法是看它能不能区分来源，不能区分就说明它是全局的速率控制。

限速分为两种粒度，一种是全局限速，整个服务器或者整个站点共用一个额度，简单但粗暴，正常用户也会被压；另一种是按来源限速，每个来源地址或者每个会话单独计额度，更精细但要维护状态。判断方法是看配置项里有没有「per IP」这类选项。

限速对盗链是有效的，因为盗链方通常并发很高，一旦被压到很低的速率，它拿资源就不划算了，但它不是治本，因为盗链方可以换来源继续来，只要总量不大就不会被限到。判断方法是看限速日志里被压的请求占比。

限速对本站高频访问更有效，因为这时候需要保护的是服务器本身的处理能力和带宽，限速能保证单个来源不会吃掉全部资源，让其他用户还能正常访问。判断方法是看限速后是否还有用户反馈打不开。

限速对程序流量也有用，如果自己的备份任务把带宽吃满，给它单独限速就能避免影响用户访问，但更好的做法是把任务挪到低峰时段。判断方法是看任务是否必须在白天跑。

限速的风险在误伤，配得太紧会让正常用户看到加载缓慢甚至失败，尤其是视频、大文件下载这类业务，单个用户本来就要占很多带宽。判断方法是先设一个宽松值，观察一周再收紧。

两种手段的先后顺序

实施时最好一次只改一项，改完观察一天再改下一项，这样每项的效果都能单独验证，同时改多项的话，效果出来了也说不清是哪一项起的作用。判断方法是记录每次变更的时间和对应的指标变化。

第一步永远是定位原因，不定位就动手等于押注，押注对了浪费时间，押注错了掩盖问题。判断方法是按前面三种原因各统计一次，用数据定主因。

如果主因是盗链，先上防盗链，因为这是身份问题，识别对了就一劳永逸，而且不消耗正常用户的体验。判断方法是配完后观察外站引用的流量是否消失。

如果主因是本站被高频访问，防盗链完全无效，应该上按来源限速，同时检查是不是被采集，因为高频访问里可能混着采集流量。判断方法是看来源的请求节奏是否符合正常用户模式。

如果主因是自己的程序，两个手段都只是缓解，真正的解法是调整任务时间或者改传输方式，比如改成增量同步、压缩后再传、或者走内网。判断方法是看任务能否挪到低峰、数据能否压缩。

实际部署通常是组合，先用防盗链挡掉外站引用，再用按来源限速给每个用户设上限，这样两层配合能覆盖大部分情况，剩下的靠任务调度解决。判断方法是看两层配完后带宽是否回落到合理区间。

还有一个动作应该在两种手段之前做：把大文件挪到独立的分发渠道，比如把视频和安装包放到对象存储或者分发网络上，服务器只保留页面和接口，这样带宽压力会小一个量级。判断方法是看大文件在总流量里的占比。

月度流量额度定高了浪费，定低了月底被限速。云途那条产品线从百兆到两Gbps分了好几档，能按实际用量逐档试。

带宽套餐怎么选才不超额

还有一个技巧是把监控粒度调细，按分钟统计的峰值往往比按小时统计的高出一截，而计费通常按某个固定粒度取最高值，弄清楚这个粒度能避免因为短时尖峰被计到更高的档位。判断方法是问清计费取值的统计粒度。

选套餐的依据不是看最大值，而是看峰值的出现频率，如果峰值每天只出现一两次、每次几分钟，用一个较小的基础带宽加弹性计费更划算，如果峰值长期贴着上限，那就说明确实需要更大的固定带宽。判断方法是统计一个月内超过某个阈值的时长。

很多方案是带宽和流量双限制的，这时候要先弄清哪个先到顶，带宽决定瞬时速度、流量决定月度总量，两个约束里更严的那个才是真正的瓶颈。判断方法是分别测算两个维度的用量，看哪个先接近上限。

超额后的处理方式差别很大，有的方案是限速、有的按量计费、有的是直接停服，限速的最温和但影响体验、计费的会产生意外账单、停服的最危险。判断方法是签约前问清超额后的具体动作。

还有一种思路是把带宽需求和业务节奏对齐，如果业务有明显的淡旺季，可以在旺季前临时升级带宽，旺季结束再降回来，多数方案支持按月调整，这样比全年买大带宽省钱。判断方法是看方案是否支持按月变更。

流量统计的口径也要问清，是单向算还是双向算、是否包含内网传输、是否包含被攻击时的流量，这三项不同会导致实际可用量差出一倍。判断方法是让对方书面说明计费口径。

最后一个现实建议是留出余量，按实际峰值的 1.3 倍配置，因为业务会增长、推广会带来突发、攻击也难以预料，贴着上限配的方案每个月都要为超额付费。判断方法是按历史最高月乘系数估。

几个常见的误判

误判一是以为配了防盗链就万事大吉，实际上防盗链只挡得住最简单的引用，改个请求头就能绕，而且它完全不管本站被高频访问的情况。判断方法是配完后看带宽是否真的降下来。

误判二是把限速当成万能药，全局限速会让正常用户一起变慢，而且它不区分请求的性质，一个备份任务就能把额度吃光。判断方法是看限速后是否有正常用户的投诉。

误判三是看到带宽爆了就去升级套餐，这只是在用钱掩盖问题，如果流量是盗链或者采集造成的，升级之后对方会跟着吃满新的额度。判断方法是先定位原因再谈升级。

误判四是忽略了大文件的占比，往往一个视频或者一个安装包就占了七成流量，把这类文件挪走比配任何防护规则都有效。判断方法是按文件大小排序看流量构成。

误判五是只看平均值不看峰值，平均带宽用了三成听着很宽裕，但峰值时段可能已经顶到了上限，用户感受到的是那几十分钟的卡顿。判断方法是看峰值的持续时间。

误判六是忘了统计被攻击时的流量，有些方案的计费包含攻击流量，一次攻击就能把月度额度耗完，这个问题在事后看账单时才会发现。判断方法是确认计费是否区分攻击流量。

做带宽看板需要一台能长期跑监控的机器。rabisu那个按月付费的档价格不高，挂监控和日志分析都合适。

怎么建立长期的带宽管理

第一步是把带宽用量做成可视的看板，按来源、按资源、按时间三个维度都能下钻，有了这个之后任何异常都能几分钟内定位，而不用每次从日志重新分析。判断方法是看能不能在一个页面上完成定位。

第二步是给关键指标设阈值告警，比如日流量超过某个值、某个外站引用超过一定比例、单个来源的请求速率异常，这些告警能让你在超额之前就介入。判断方法是确认告警能在超额前触发。

第三步是定期做流量审计，每月看一次流量构成有没有变化，某些原本小的来源变成大头、某些资源突然被大量访问，这些变化往往是问题的早期信号。判断方法是把审计写进例行工作。

第四步是把防护规则做成可回滚的，每次调整都记录改了什么、为什么改、效果如何，这样发现误伤能立刻回滚，而不是重新想一遍。判断方法是确认规则有版本或备份。

第五步是和大文件分发策略一起规划，带宽问题很多时候不是防护问题而是分发问题，把静态资源和大文件逐步外移，长期看比不断加防护更有效。判断方法是评估自建分发和外部分发的成本比。

最后是把带宽成本和业务价值挂钩，如果某个功能带来的收益远低于它消耗的带宽，那就该考虑调整这个功能，而不是不断加大带宽预算。判断方法是按功能维度统计流量和收益。

按业务类型选手段

图片和视频为主的站点，防盗链的收益最大，因为这类资源单个文件大、被引用的可能性高，一个盗链方就能吃掉很大比例，而内容本身又无法通过限速保护，只能靠身份识别。判断方法是看资源类型里视觉类内容的占比。

下载站和软件站要更重视流量上限，因为安装包动辄几百兆，一个用户下载就消耗掉大量额度，这类业务更适合把文件放到专门的分发渠道，服务器只做页面和校验。判断方法是算单个文件的平均大小和下载次数。

接口服务为主的业务，带宽压力通常集中在少数几个返回数据量大的接口上，这时候比限速更有效的是优化接口返回，去掉冗余字段、支持分页、加压缩，能直接减少一半以上的流量。判断方法是按接口统计返回的字节数。

内容站的情况相对温和，页面和图片都不大，带宽压力主要来自访问量的增长而不是单次请求过大，这类业务按来源限速就够，重点是防止某个来源异常高频。判断方法是看单位时间的请求数分布。

还有一种特殊情况是有大量真实用户的直播或者在线播放，这类业务的带宽需求天然很高，任何防护手段都只能减缓不能解决，根本出路是把流媒体交给专业的分发服务。判断方法是算清自建分发的单用户成本。

所以手段的选择要跟着业务类型走，先看清自己的流量构成里占比最大的是什么，再针对那一块做处理，而不是套用别人的防护配置。判断方法是按资源类型分组统计，找出占比最高的前三类。

把整篇收一句

带宽被占用有三种原因：外站盗链、本站被高频访问、自己程序在跑流量，三种原因对应三种手段。

判断方法是先按来源页面、来源地址、进程三个维度各统计一次，看流量到底流向了谁。防盗链只管外站引用，限速管的是速率上限，两个都解决不了程序流量。

处理顺序是：先定位原因，盗链上防盗链、高频访问上按来源限速、程序流量改任务调度，同时把大文件外移到分发渠道。

最后一句：带宽问题先问流向，再问手段，顺序反了就白配。

本文只为提供市场讯息，所有内容及观点仅供参考，不构成投资建议，不代表本站观点和立场。投资者应自行决策与交易，对投资者交易形成的直接或间接损失，作者及本站将不承担任何责任！