云服务器 1T 流量到底是多少？三种计费口径与一次五分钟的验证

「月流量 1T」这句话，在不同商家那里可能意味着三种完全不同的东西。有的只算「服务器发出去的」，有的「进和出都算」，还有的把「内网传输」也算进去。而三种口径下，「1T」的实际容量可能差好几倍。这篇讲清流量计费的三种口径、怎么判断自己属于哪种、以及为什么「按字节还是按请求」这件事会改变优化方向。

五款高性价比档位速查

有需要云服务器的，可以先看这一张表——五个价位段每款都是高性价比，价格从 22 元拉到 480 元。

商家	推荐款	配置	带宽与流量	月费	核心特点
云途	HK.N4.A	2 核 2G 20G	200Mbps / 500G	22 元	三项都在合理区间的入门档
isvoro	HK CN2 Core	2 核 2G 30G	100Mbps / 300G	25 元	硬盘 30G 加 CN2 回国线路
rabisu	Aydn VPS x8	4 核 8G 60G	—	34.5 元	每核 8.6 元，带宽需单独确认
zji	香港 BGP 在售机型	6 核 16G 480G	55Mbps / 1T	450 元	480G 硬盘是整机档里少见的大盘
sixtynet	LAX-MEDIUM	8 核 8G 160G	10Gbps / 20T	480 元	唯一「大端口配大配额」的组合

一、三种口径的区别

还有一个「第四种」很容易混淆：「不限流量」其实也是一种口径。

它的含义是「不按字节计费，按端口限速」。

而这不等于「无限能力」。

因为端口的物理上限还在。所以「不限流量 + 20Mbps」实际是「每月最多 6.5T」，只是不需要你去数。所以「不限流量」本质上是一种「计量方式的简化」，不是「另一种物理能力」。

判断方法：把端口速率换算成月总量。

Mbps × 0.324 = 每月 T 数。

再看一个「配额与端口」的搭配。

「大配额 + 小端口」= 持久型。

「小配额 + 大端口」= 突发型。

而<'sixtynet'+'> 那种 20T 配 10Gbps 的档，是「大配额 + 大端口」，属于少数。

还有一条：「配额」和「限速」是两种约束，不该混为一谈。

前者约束「总量」，后者约束「速度」。

同样是「1T 配额」，实际含义可能差三倍。

口径	算什么	对谁不利
只算出站	服务器发出的	下载站
双向计入	进出都算	上传型业务
含内网	站内互传也算	多机协作

这张表最该注意的是第一行：只算出站是行业主流，但它对「下载型业务」最不利。

因为下载站几乎全是出站。

所以「1T 配额」对一个下载站来说是「实打实的 1T」，而对一个「上传为主」的备份节点来说，可能连 100G 都用不到——因为入站不算。所以同样的配额，对不同业务的实际容量差十倍。

第二行双向计入。这一种最少见，但确实存在。

而它对「上传型业务」的影响是「配额消耗翻倍」。

所以「接收大量上传」的业务，要先确认这一项。

第三行含内网。这一种在「多机组网」时影响最大。

因为站内同步的流量可能比对外流量还大。

所以「多机架构」要先问「内网算不算」。

三种口径的判断方法：用一个已知大小的文件做双向测试，看面板怎么计。

这个方法最直接。

而<'rabisu'+'> 那种带宽流量都未标注的产品，这一项更是必须问清——因为「未标注」可能意味着「不限」，也可能意味着「按需付费」。

二、只算出站：主流但不对称

出站口径还有一个「回源」的细节。

如果业务有 CDN，那「CDN 回源」算你的出站。

而「用户到 CDN」那段不算。

所以「上 CDN」能同时降「配额消耗」和「带宽压力」。而这个收益取决于「缓存命中率」——命中率 90% 时，回源只有 10%。所以「配额规划」和「CDN 策略」是绑在一起的。

判断方法：看 CDN 的「回源流量」。

它才是算进服务器配额的量。

再看一个「出站口径」的测量方法。

自己在机器上装 vnstat，按月统计出站字节。

而这个数应该和面板的差不多。

差得多，说明口径不同。

而<'rabisu'+'> 那种未标注流量的产品，自建统计几乎是唯一办法。

还有一条：「面板更新频率」会影响「能不能提前发现」。

按天更新的面板，超了才知道。

先讲主流口径，因为大多数产品是这个。

「只算出站」的逻辑是「入站你控制不了，出站你能控制」。

所以商家的「配额」约束的是「你能发多少」。

而这个逻辑带来一个反直觉的结论：一个「接收备份」的服务器，可能几乎不吃配额，因为它主要收数据不发数据。所以「备份节点」这种业务，用小配额也能跑。而很多人按「总量」估配额，结果买大了。

判断方法：看业务的数据流向。

发给用户为主：出站。

接收上传为主：入站。

而这个区分直接决定「该买多大配额」。

再看一个「出站配额」的实际换算。

500G 配额 = 每天 16.7G = 每小时 700M。

所以「500G 够不够」这个问题，等价于「每小时能不能控制在 700M 以内」。

而这个换算比看总量更直观。

而<'云途'+'> 的 22 元那档给 500G，正好是「小内容站」的量级。

还有一个「出站配额」的隐性消耗。

备份、日志上报、监控数据发送都算出站。

而这些加起来可能占配额的 10% 到 30%。

所以「业务流量」之外还要留出这部分。

三、双向计入：上传型业务的坑

双向口径还有一个「不对称」的变体。

「入站按 50% 折算」。

而这种口径介于两者之间。

所以「口径」不是一个三选一的问题，可能是一个连续值。而这个细节只能从文档或账单上看出——靠猜是猜不到的。

判断方法：传 10G，看面板涨 10G、15G 还是 20G。

三个结果对应三种口径。

再看一个「双向」的实际影响。

如果业务是「接收 + 处理 + 少量返回」，双向口径下的配额消耗约等于「入站量」。

所以配额要按「入站量」买。

而<'isvoro'+'> 那种多系列产品，不同系列的配额梯度不同，便于找到「刚好够」的那一档。

还有一条：「双向口径」在超额时同样是双倍。

所以超额成本也被放大。

第二种口径是「双向计入」，它对上传型业务最不利。

因为「接收 1G 数据」也消耗 1G 配额。

而这对「备份接收、日志收集、数据采集」这类业务意味着「配额消耗翻倍」。

所以「1T 配额」在双向口径下，实际能接收的数据只有 500G 左右（因为上传方也要确认，产生少量出站）。而这个差异在「大文件传输」的场景下很明显——很多人发现「传了 600G 就超了」。

判断方法：传一个 10G 文件，看面板涨了多少。

涨 10G：只算出站。

涨 20G：双向都算。

这个测试五分钟就能做完。

再看一个「双向口径」的合理性问题。

从成本角度，双向计入并不完全没有道理。

因为入站流量也占用带宽。

所以「双向算」不是「坑」，而是一种不同的定价。

而<'isvoro'+'> 那种多产品线的商家，不同系列的口径可能不同——所以「同配额不同系列」的价格差，有一部分就来自这里。

还有一条：「双向口径」通常在文档里写得很隐蔽。

所以要主动问，不要等超了才发现。

四、含内网：多机架构的隐藏成本

内网这块还有一个「同机房 vs 同区域」的差别。

有的产品「同机房内网不计费」，但「跨机房算公网」。

而这个边界决定了「多机部署该放在多近」。

所以「内网免费」这句话要看边界。如果只有「同一机柜」免费，那多机协作几乎没意义；如果「同区域」免费，那多机部署就很划算。而这个范围在产品页上通常不写。

判断方法：问「内网的范围是机柜、机房还是区域」。

范围越大，多机架构越划算。

再看一个「内网」的实际用法。

把数据库和应用的通信走内网。

而这个前提是「它们在同一内网范围内」。

所以「同机房部署」不只是延迟低，也是「省流量」。

而<'云途'+'> 那种同城多机房的产品，内网范围要单独确认。

还有一条：「跨区域」的同步流量很贵。

所以「多地部署」要控制同步频率。

第三种是「内网也计入」，它对多机架构影响最大。

因为「站内同步」的流量往往比对外流量还大。

而「含内网」意味着多机协作的成本会明显上升。

典型场景：主从数据库同步、多机文件共享、集群内部通信。这些流量「对外看不见」，但可能占配额的一半以上。所以「多机架构」选产品时，这一项比「配额大小」更重要。

判断方法：查文档或者问「同一机房内网流量计不计费」。

计入，多机成本要重算。

不计，多机几乎是免费的。

而<'sixtynet'+'> 那种 20T 配额的大流量档，如果是「含内网」口径，多机场景下要留足余量。

再看一个「内网」的实际用法。

如果内网不计费，可以把「吃流量的组件」放在同一机房。

而这个优化能显著降低配额压力。

所以「内网政策」也是一个架构约束。

还有一条：「跨机房」通常不算内网。

所以「多地部署」的同步流量是实打实的出站。

五、按字节还是按请求

计费单位这块还有一个「峰值」的维度。

有的产品按「95 峰值计费」。

而这个模式对「波动大」的业务有利。

因为「95 峰值」是「去掉最高的 5% 后的最大值」，所以短时突发不算。而这个模式在云服务里比在 VPS 里更常见。所以「按什么计费」这件事，要看产品类型。

判断方法：问「是按总量还是按峰值」。

按峰值，就要关注「尖峰持续多久」。

再看一个「字节与请求」的组合。

有的产品「字节 + 请求」双计费。

而这种组合下，「小文件多」很吃亏。

所以「合并资源」这类优化，效果会翻倍。

而<'zji'+'> 那种整机产品，通常只按字节算——所以「请求数」不是约束。

还有一条：「计费单位」在合同里应该写清。

因为「按请求」这项容易被忽略。

除了「算哪一段」，还有「怎么算」这个问题。

按字节：统计传输了多少数据。

按请求：统计发了多少个请求。

大多数产品按字节，但「CDN」和「部分托管服务」会按请求额外计费。而这个区别决定了「优化方向」不同——按字节优化「文件大小」，按请求优化「请求数」。而两者的优化手段几乎不重叠。

判断方法：看账单里有没有「请求数」这一项。

有，说明是双重计费。

再看一个「按字节」的优化方向。

压缩图片、开 WebP、减少第三方脚本。

这三项能把流量降低一半以上。

而「按请求」的优化方向完全不同。

合并文件、减少请求数、开 HTTP/2。

所以「优化流量」这件事，先确认「按什么算」。

而<'zji'+'> 那种整机产品，通常只按字节算，不按请求算——这一点反而比 CDN 简单。

还有一条：「按请求」计费在「小文件多」的场景下很贵。

因为请求数多但字节少。

而这个特点在 API 服务上很明显。

再给一个「完整验证流程」，五分钟能做完。

第一步：在机器上装 vnstat，记下当前累计出站。

第二步：上传一个 1G 文件到服务器。

第三步：从服务器下载同一个 1G 文件。

第四步：看 vnstat 涨了多少、面板涨了多少。

四个动作能同时回答三个问题：入站算不算（看 vnstat 的 rx 涨不涨）、双向算不算（看面板涨 1G 还是 2G）、面板和自建统计是否一致。而这三个答案，决定了「配额该怎么估」。

判断方法：传之前之后各记一次数。

差值就是口径。

而<'rabisu'+'> 那种未标注的产品，这个流程几乎是必做的——因为「不标注」意味着「只能自己测」。

再看一个「测试文件」的选择。

用「不可压缩」的文件（比如随机数据）。

因为可压缩的文件在传输中可能被压缩，导致统计不准。

这个细节很多人忽略。

还有一条：「测试要避开业务高峰」。

否则会影响正常用户。

再补一个「口径与超额」的连带关系。

超额单价通常按「套餐内单价 × 倍数」算。

而「倍数」在不同口径下意义不同。

比如「套餐内 24 元/T、超额 500 元/T」这个差 20 倍的定价，在双向口径下等于「40 倍」。所以「口径」不只影响「够不够」，还影响「超了多贵」。而这个连带效应在实际决策里几乎从没被算过。

判断方法：把「超额单价 × 口径倍数」一起算。

再看一个「超额缓冲」的做法。

把配额用量的 70% 设为告警。

而这个动作在「按天更新」的面板上尤其必要。

而<'isvoro'+'> 那种「多档位」的产品线，超额的解法通常是「升一档」而不是「买流量包」——因为档位差通常在几十元，而超额可能几百。

还有一条：「超额之后先限速还是先计费」要问清。

两者的风险完全不同。

再有：「配额是按月清零还是滚动」。

滚动配额下，「这月不用」不能留到下月。

还有一个「口径与产品类型」的对应关系。

云主机：多数据「只算出站」。

独服：多数据「不限流量 + 端口限速」。

CDN：多数据「按字节 + 按请求」。

三类产品的口径各自成体系。

所以「跨品类比流量」几乎必然出错。

而<'sixtynet'+'> 那种云主机和整机混在一条产品线里的情况，最容易出现「同数字不同含义」——因为 20T 在云主机口径下是「出站配额」，在整机口径下可能是「不限流量下的物理上限」。所以「比流量数字」之前，先确认「是不是同一个品类」。

判断方法：看产品名里有没有「整机/独服/云主机」。

不同品类，口径不可比。

再看一个「跨品类」的实际例子。

云主机 20T 配额，满速能跑 4.6 小时（10Gbps）。

整机「不限流量 30Mbps」，满速能跑一个月。

两者性质完全不同。

而这个区别只能靠「换算成同一个单位」看出来。

所以「口径统一」是比价的前提。

再说一个「口径」的长期影响。

业务增长时，配额消耗也会增长。

而不同口径下的「增长速度」不同。

双向口径下，「用户上传增多」会让配额消耗增长更快；单向口径下，只有「服务器发得更多」才增长。所以「口径」还决定了「业务增长时成本涨得多快」。而这个差别在规划两年预算时很明显。

判断方法：按「业务增长曲线 × 口径倍数」算两年后用量。

再看一个「口径」与「优化」的配合。

单向口径下，优化「出站」最有效。

双向口径下，优化「入站」也有收益。

所以「优化方向」由口径决定。

而<'zji'+'> 那种按字节计的整机，优化的核心就是「压文件大小」。

还有一条：「日志和监控」的流量要单独算。

因为它们「持续产生」，累计起来不小。

最后补一个「口径记录」的习惯。

把每家的口径写进自己的比价表。

四列：配额、口径、端口、超额政策。

四列填完，「哪家真的划算」才看得清。

而这个记录比记价格有用得多。

因为「价格」会变，而「口径」通常稳定。所以一旦记下某家是双向口径，后面所有比价都能直接套用——省掉每次重新确认的成本。

判断方法：一次记下，长期复用。

而<'云途'+'> 那种同城多产品线的商家，口径可能按产品线区分——所以记录要细到「产品线」。

再看一个「口径」的变更风险。

商家可能调整口径。

所以「长期合同」要看有没有「口径变更条款」。

还有一条：「口径」比「价格」更难改。

因为改口径等于改产品定义。

补一句：「口径」这件事，问一次就够，但一定要问。

因为问完就能写进记录，而没问的会一直是个坑。

还有：「配额」和「带宽」要一起读。

「1T + 100Mbps」和「1T + 10Gbps」是两种产品。

前者能跑 22 小时，后者只能跑 13 分钟。

所以「只看配额」会漏掉一半信息。

再说：「流量」这件事最容易在报价单上被简化成一个数字。

而那个数字背后的三个口径，才是「能不能用」的关键。

再有一句：「口径」不问，等于「按最严的那种」赌。

而赌输了，代价是一次超额账单。

补：口径确认之后，配额才有「可比价格」。

否则比的是「不同单位」。

一句实用建议：把「口径」当成「配置」一样对待。

因为它的影响同样大，而确认成本却低得多，问一句话就能定下来。

补最后一点：口径清了，超额才有预算。

而预算是「能不能长期跑」的前提。

六、三种口径的应对

三个结论，按口径分。

只算出站：按「日流量」估配额，留 30% 余量。

双向计入：按「数据量 × 2」估配额。

含内网：多机架构要「按总流量」估，不是「按对外流量」。

三条结论的共同前提是「先确认口径」。而这个确认只需要两个动作：问一句，或者做一个双向文件测试。前者两分钟，后者五分钟。而这两分钟能避免的，是「配额估错一倍」这种代价。

再看一个「口径与价格」的关系。

同样标 1T，双向口径的实际容量是单向的一半。

所以「双向口径的产品便宜」可能是假象。

而<'云途'+'> 那种档位密集的产品线，比价时应该先统一口径——否则「便宜的那档」可能只是「算得严」。

还有一条：「超额之后的口径不变」。

所以超额时的成本也受口径影响。

这个连带效应经常被忽略。

最后回到开头：「1T」这三个字符，在三种口径下差三倍。

而确认口径的成本只有五分钟。所以「买之前问一句」这件事，在流量这一项上的回报特别高——因为它避免的不是「一点点误差」，是「一倍的关系」，而这个差异在一年里会累积成实实在在的账单差额。

本文讨论流量计费口径的一般原理与判断方法，不针对任何具体商家，也不对任何计费政策作评价。文中提到的三种口径、换算方法、双向测试方法与优化方向均为通用参考；各商家的实际计费口径（是否算出站、是否双向、内网是否计费、是否按请求另计）差异很大且可能随时调整，必须以书面条款与账单明细为准，本文不对任何商家的实际计费方式作陈述或保证。文中所有换算（如「500G = 每天 16.7G」）均为按理论值推算，未考虑协议开销与实际计量差异。本文不构成任何购买建议，亦不代表本站立场，也不代表对任何具体产品的推荐。因口径理解偏差导致超额或成本上升所产生的直接或间接损失，作者及本站不承担任何责任。