出口带宽监控上只用了三成，但全公司都在喊网慢，重启一下代理能好十分钟，然后原样回到那个状态。这个现象在办公网出网代理上实在太常见，常见到很多人第一反应就是"带宽不够了，找运营商加"。其实你把那张带宽图拉出来放大看，曲线平得能当尺子用，压根没跑满。慢的不是带宽，是连接和 DNS：代理上的连接表堆满了、本地端口用完了、域名解析在排队，这三件事里任何一件发生，用户侧的表现都是"网页打不开"或者"白屏半天"，而带宽图上一片平静。说白了，出口带宽决定的是"同一时刻能搬运多少字节"，并发连接数和缓存盘的随机 IOPS 决定的才是"一个请求要排多久的队"。买机器的时候把这两个搞反了，最后就会买成那种带宽很宽、但打开网页很慢的配置。
先把这个故障现场完整地还原一遍，因为它几乎是所有误判的起点。周一早上九点半，工位上陆续有人开始反馈"网页打不开""刷新半天没反应""图片一张都出不来"。运维打开监控面板：出口带宽峰值才到采购值的三成，CPU 使用率不到两成，内存还剩一半，负载也没有异常。于是第一反应是"运营商那边抖了吧"，或者"是不是有人在下东西"。重启代理进程，十分钟内一切正常，然后慢慢又卡回去。
这个"重启能好十分钟"的信号本身就说明问题。如果真是带宽不够，重启代理不可能缓解，因为带宽的占用者是那些请求本身，重启完请求照样回来。重启能缓解的只有一类东西：被耗尽的内核资源。连接表清空了，TIME_WAIT 状态的套接字释放了，本地端口池还回来了，文件描述符重新从零开始计数，Squid 内部的各种队列和锁也一起归零。十分钟后这些资源重新填满，症状原样复现。所以重启不是"修好了"，重启只是把计数器按回起点。
顺着这条线索往下看，你会发现办公网的访问模型和很多人脑子里的模型不太一样。一个人开一个门户页面，浏览器会对页面里的每个域名并发发起若干条连接，一个页面牵扯二三十个域名是常事，加上广告、统计、字体、CDN 分片，浏览器瞬间维持的连接数能到几百条。这几百条连接里，绝大部分在传输的数据量都很小——几十 KB 的 CSS、几百字节的统计上报、一个几 KB 的接口返回。它们占用的带宽微乎其微，但每一条都要占一个文件描述符、占一个本地端口、在内核里占一块缓冲区、在 Squid 里占一份状态。带宽按字节算，连接按条目算，这两条曲线的形状从一开始就不一样。
所以"带宽才用了三成却很慢"不但可能，而且是大概率事件。带宽图是给你看账单和水位的，不是给你看体验的。要看体验，得看新建连接速率、并发连接数、DNS 解析时延分布、以及磁盘的 await。这四个指标里，只有最后两个需要额外配监控，前两个用系统自带命令就能看到。很多团队卡在这个问题上，不是因为技术难度，是因为监控面板上从一开始就没有这几个指标。
再补一句关于场景的。真正需要统一出网代理的，通常是这么几类：办公网或研发网要求统一出口，顺便做访问控制（哪些域名能访问、哪些人能访问哪些）和访问留痕（谁在什么时间访问了什么，日志要能审计）；爬虫或数据采集机群需要一个统一出口，方便做出口轮换和限速，避免把单个源站打挂；多台业务服务器共用固定出口 IP，去对接第三方接口的 IP 白名单。这三类有一个共同点——要的是"可控"和"可追溯"，不是"快"。反过来，如果只是三五个人偶尔翻点资料，上一套代理纯粹是过度设计，一个浏览器插件或者 DNS 层面的策略就能解决，不值得为它养一台机器和一套配置。
很多人做容量估算出错，根源在这里：他脑子里装的是反向代理的模型，手上要建的却是正向代理。"代理"这两个字是同一个，但两者在工程上几乎是两种东西。
正向代理是内部客户端的代表。客户端知道自己要配代理，通常在系统设置里写地址、用 PAC 脚本分发、或者用环境变量。它的访问方向是"内部很多客户端 → 一台代理 → 外部无数个源站"。反向代理正好反过来，是服务端的代表：外部用户根本不知道后面有代理，它代表你的站点接住外部请求，方向是"外部很多用户 → 一台代理 → 内部有限的几个后端"。
方向一变，四件事立刻跟着变。
第一，容量模型的变量不同。反向代理的负载可以近似写成"每秒请求数乘以平均响应时间"，因为后端数量有限、响应时间分布集中、请求的内容种类有限。正向代理没法这么算：源站是互联网上任意域名，响应时间从几毫秒到几十秒都有，请求的内容种类是长尾的。它的主导变量是"并发连接能撑多少条"，而不是"每秒能处理多少个请求"。你用反向代理的 QPS 思维去估正向代理，估出来的数会离谱。
第二，缓存命中的对象完全不同。反向代理命中的是"自己的那几个域名下的资源"，重叠度极高，命中率做到八九成是常态。正向代理命中的是"全公司所有人访问的所有站点"，重叠度取决于人群行为的重合程度。办公网里，公共部分（系统更新、常用门户的首页资源、包管理器的依赖包）重叠度高，长尾部分（每个人各自看的页面）几乎零重叠。这个差异决定了正向代理的命中率天然上不去，也决定了后面那节要说的"加机器没用"。
第三，TLS 的处理方式不一样。反向代理通常在自己身上终结 TLS，能看到明文 HTTP，因此能缓存、能改写、能做压缩。正向代理面对 HTTPS 时，客户端发来的是 CONNECT 方法，代理只在客户端和源站之间搭一条纯字节隧道，之后传什么它不知道，也改不了。这意味着在当前 HTTPS 占绝对多数的互联网上，普通正向代理的缓存能力被大幅削弱——它连内容是啥都不知道，谈何缓存。要让正向代理缓存 HTTPS，得上 SSL 中间人解密（Squid 里的 SSL Bump），代价是要在所有客户端上装一个自签根证书，并且这件事本身涉及员工隐私和数据合规，需要明确的制度和告知，不是技术拍脑袋就能上的。
第四，消耗的资源侧不同。反向代理消耗的是入站能力和后端连接池；正向代理除了入站，还大量消耗公网出口 IP 的端口资源和 DNS 解析能力。一个源站的一条连接要占代理一个本地端口，端口池是有上限的，这是硬约束。这一条直接引到下一节。
把这四件事分开之后，你会发现一个很实际的结论：网上大量关于"代理能撑多少并发""缓存命中率能做到多少"的经验数字，大多来自反向代理场景，直接搬到办公网出网代理上会全面失灵。定规格之前，先用一句话把场景钉死——我这是正向出网代理，客户端要显式配置，源站不可控，HTTPS 走隧道。
这是全文最核心的一条算术。一个客户端请求经过代理时，在代理上不是占一条连接，是占两条：客户端到代理一条，代理到源站一条。代理是连接数的放大器，倍数至少是二。如果算上 HTTPS 隧道、长连接保持、以及失败重试，实际倍数更高。
顺着这个放大器往下推，会遇到三个依次出现、且都不吃 CPU 的硬上限。
第一个是文件描述符。每条连接对应一个 fd，加上 Squid 自己要开的日志文件、缓存文件句柄，总量很快上去。很多系统默认单进程 1024 个 fd，这个数字对一台代理来说低得可笑，几百个用户就能撞上。撞上的表现是日志里出现"文件描述符耗尽"之类的告警，同时新连接直接失败，而 CPU 和带宽都闲着。处置方法很直接：把进程级和系统级的 nofile 上限一起调上去，并且确认 Squid 编译时或配置里允许使用你调的那个值——只调系统不调应用等于没调。
第二个是本地端口范围。代理到源站的每条连接都要从本地端口池里拿一个端口。默认的临时端口范围大致是三万个左右，看着不少，但关键在于：一条连接关掉之后，主动关闭方会进入 TIME_WAIT 状态，要等一段时间（默认通常一分钟量级）才能把端口还回来。于是"每秒最多能新建多少条出站连接"这个数是可以估算的——大致等于端口池大小除以 TIME_WAIT 时长。三万除以六十，量级在每秒几百条。这个上限跟 CPU 核数一点关系都没有，跟内存大小关系也不大，你插再多内存、换再快的 CPU，这个数还是这个数。这就是为什么"机器很闲但新连接建不上"。要缓解，可以扩大端口范围、开启 TIME_WAIT 状态下的端口复用、缩短相关等待参数、给机器多加几个出口 IP（端口池是按 IP 算的，多一个 IP 就多一整池）、或者干脆横向拆成多台代理。
第三个是内核连接跟踪表。如果这台代理机器上还跑了 NAT 或者带状态防火墙（出网机器很常见），每条连接还要在连接跟踪表里占一格。表满了之后内核会直接丢包，表现是随机性的连接超时，而且丢包不计入任何应用层日志，排查起来极其难受。这个表也要跟着连接数一起调，别只盯着 Squid。
除了这三条硬上限，还有一个软性的东西值得单独说：并发连接数直接决定了内存需求。每条连接都要内核收发缓冲区，还要 Squid 内部维护状态结构。并发一万条和并发十万条，对内存的要求不是一个量级。很多团队配机器时按"内存够跑系统就行"来买，结果连接一上来，内存先于 CPU 吃紧。反过来说，当你发现连接数撑不住时，加内存和调 fd 上限，通常比加 CPU 核数有效得多——因为这些瓶颈根本不在计算上。
还有一个容易忽略的点：Squid 的并发模型和 CPU 核数的关系。老一些的部署是单进程事件循环，核多了也用不上，主频和单核性能反而更重要；较新的版本支持多工作进程模式，能把负载分摊到多个核上，但配置上要考虑缓存目录的共享和进程间协调。所以"加核数"这件事对代理的效果，取决于你用多进程模式还是单进程模式，不能默认核越多越好。
定规格的时候，这条链路应该这么走：先估并发连接数，再由并发连接数反推内存、文件描述符、端口范围，最后才看 CPU。把顺序倒过来，就会买成"CPU 很强但连不上"的机器。
缓存盘的账和容量盘的账完全是两本账，这是第二个高频踩坑点。采购时人们习惯问"多大容量"，但缓存目录的负载形态跟"大容量顺序读写"基本不沾边。
想清楚一件事就明白了：缓存里放的是海量小文件。网页上的对象平均大小通常在几十 KB 量级，图片大一些，脚本和接口返回小一些。这些对象被写入时是随机位置的写（哪个 URL 来了写哪个），被读取时也是随机位置的读（命中哪个读哪个）。磁盘面对随机小 IO 时，能提供的 IOPS 才是关键，容量只是"能放多少天"的问题。
机械盘在随机小 IO 下能提供的 IOPS 是几百量级，SATA 固态是几万量级，NVMe 固态能到几十万量级。这是数量级的差异，不是百分比的差异。一台跑在机械盘上的出网代理，在高命中时段可能整块盘的利用率长时间顶在一百、平均等待时间高得离谱，而此时吞吐（MB/s）其实很小——因为瓶颈在寻道次数，不在传输字节数。看监控时如果只看吞吐不看 IOPS 和等待时间，就会得出"磁盘很闲"的错误结论。
这里还有一个反直觉的现象：命中率越高，写反而越碎。因为命中率高的意思是大部分请求直接由缓存应答（这是读），而剩下的未命中请求要把新对象写进缓存（这是随机写）。访问量越大、长尾越长，新对象就越零散，写模式就越随机。再加上缓存满了之后要按替换策略淘汰老对象，删除也是随机位置的元数据操作。所以一块缓存盘在整个生命周期里，绝大部分时间都在做随机小 IO。
再往下是 Squid 自己的设计。缓存目录为什么要分一层、二层子目录？就是为了避免单个目录下文件过多。早期文件系统在一个目录里放几十万个文件时，查找和创建都会退化，分层把文件打散到成百上千个子目录里，每个目录的文件数就降下来了。这个层级数不是随便填的，它跟你的预期对象总数有关，填小了会退化，填大了会多一次目录查找。另外存储引擎的选择也很关键：传统的基于独立文件的存储方式，一个对象一个文件，对象多了 inode 消耗和元数据开销都很重；较新的打包式存储（把大量小对象塞进少数几个大文件里）能显著降低这种开销，对随机写的压力也更友好，代价是运维上不那么直观。
替换算法同样影响盘的负载。最常见的思路是 LRU 一类：空间不够时，优先淘汰最久没被访问的对象。还有按访问频次、按对象大小加权的变体。不同算法决定了哪些对象被反复读写、哪些被快速淘汰，进而决定写放大的程度。对办公网这种长尾访问为主的场景，替换策略的选择影响的是"命中率能稳在多少"，而不是"会不会崩"。
容量到底该怎么定？说句实话——容量是最不需要纠结的一项。缓存盘写满了不会导致故障，只是按替换策略淘汰老对象，命中率下降而已。真正要估的是：预期每秒命中多少次、每次命中平均读多大、每秒有多少新对象要写，然后把这些换算成随机读 IOPS 和随机写 IOPS，再按磁盘能提供的 IOPS 选型。容量按"我想保留多久的对象"倒推即可，通常是磁盘选型完成后剩下的那个便宜变量。另外别忘了还有一块盘的压力常被漏掉：访问日志。日志是顺序写，本身不重，但它的量取决于留痕要求和轮转策略，长期下来也是实打实的容量占用。
这一条是排查时被误判最多的一项，值得单独占一节。
走正向代理时，客户端把完整的 URL 交给代理，解析域名的活是代理干的。客户端自己不解析（除了少数会做预解析的浏览器行为），所以用户在地址栏里敲完回车之后，屏幕上什么反馈都没有的那段时间里，代理可能正卡在解析某个域名上。用户感知到的只有一个字：慢。
而一个页面要解析多少域名？主域名一个，静态资源 CDN 两三个，字体服务一个，统计脚本一两个，广告和推荐再来若干个，第三方登录组件又是一个。二三十个域名是常态，其中相当一部分是每次开页面都要重新问一遍的。如果是首次访问的域名，代理要跑一遍完整的递归查询：问根、问顶级域、问权威服务器，跨好几跳。任何一跳慢了或者超时了，整个解析就慢。
更要命的是解析器超时和重试的默认行为。一次查询超时通常是秒级，重试两轮，一个域名就能卡十几秒。在这十几秒里，链路上一个字节都没有传输。这一点是误判的根源：运维盯着带宽图，看到的是这段时间的流量接近于零，于是得出"网络很闲、带宽够用、慢在别处"或者反过来"是不是链路断了"的结论。很少有人第一反应想到 DNS，因为客户端侧根本看不到解析这一步，浏览器开发者工具里也显示不出来（那是代理内部的事）。
怎么确认是不是 DNS？几条路子：在代理机器上直接对同样的域名做解析，看耗时分布而不是看平均耗时——平均值会把少数十几秒的慢查询掩盖掉，要看的是长尾；看 Squid 内部的 DNS 相关统计和排队情况；在客户端侧对比"首包时间"和"传输时间"，如果首包特别慢但一旦开始传输就飞快，那基本就是解析或握手的问题，不是带宽问题。
处置方向相对清晰。第一，在代理机器本地跑一个带缓存的解析器（比如轻量级的本地缓存服务），让它接管递归，Squid 只跟本机打交道，能把绝大部分重复域名的解析时间压到近乎为零。第二，把 Squid 内置的解析并发和超时参数调到合理值——超时太长会让慢查询拖住整个队列，并发太低会让一堆域名排成一条长队。第三，注意负缓存（解析失败结果的缓存时长）别设太长，否则别人改了 IP 你这边要等很久才生效，会表现为"某些域名莫名其妙长时间打不开"。第四，IPv6 的问题要单独处理：不少环境里 IPv6 通路并不通，但解析器仍会先问 AAAA 记录，等超时再回落，平白增加一段等待，这种情况要么明确关闭不需要的地址族查询，要么保证 IPv6 通路是通的。
最后提醒一句：DNS 服务质量本身也会抖。运营商的递归服务器、公共递归服务、以及你上游 DNS 的可用性，都会直接变成"网页白屏"。所以在定代理机器规格的时候，DNS 这部分不要想当然地认为"反正有个默认配置"，它是这套系统里少数几个能单独把体验拖垮、又不体现在任何资源水位上的环节。
命中率是一个比值：命中的请求数除以总请求数。这个比值由两件事决定——内容本身能不能缓存，以及不同人的请求有多大的重叠度。这两件事都不是机器能改变的。所以当你看到命中率长期偏低，第一反应如果是"机器不行，加一台"，那就等着花钱买失望吧。
先看内容能不能缓存这一侧。源站说了算：响应头里如果明确写了不允许缓存、或者只对私有缓存生效、或者有效期为零，代理就得听话；带了身份Cookie的响应通常也不可缓存；响应头里带了"按什么变化"的声明（比如按客户端编码、按登录态变化），会让同一个 URL 产生多个缓存变体，命中难度陡增。还有一类是条件请求：对象其实还在缓存里，但代理必须回源问一句"变了吗"，源站回一个"没变"——这省了传输字节，但没省连接，也没省那次往返。所以在统计上它看着像命中，对体验的帮助却有限。
再看 HTTPS 这一侧。前面说过，普通正向代理对 HTTPS 走的是隧道，什么都看不到，也就什么都缓存不了。现在互联网上 HTTPS 的占比是压倒性的，这就意味着一台不做解密的正向代理，可缓存的流量占比本来就很低。这不是配置问题，是协议结构决定的。要突破就得上中间人解密，那是另外一整套工程和合规问题。
再看重叠度这一侧。办公网里，一群人看同一个门户首页，重叠度高；一群研发拉同一批依赖包，重叠度高得惊人——这类流量的可缓存性极好，收益也最大，因为它们体积大、重复率高、源站响应头通常友好。而每个人各自看的资讯、各自搜的东西，重叠度近乎为零，加多少缓存都命中不了。所以命中率的第一个杠杆是"你把缓存资源投在哪类流量上"，而不是"你有多少缓存资源"。
那什么时候加机器有用？只有当瓶颈确实在"并发连接数"或者"缓存盘随机 IOPS"的时候，加机器（或者横向拆成多台）才有效，因为这两个是可以通过增加资源直接抬高的天花板。而命中率低对应的处置是另一套：改策略。具体动作包括——为可缓存性好的流量（包管理器、系统更新、静态资源域）单独配置缓存规则，延长其保留时间；为明确不可缓存的流量（带登录态的接口、实时数据）减少无意义的缓存尝试和磁盘写入；把动态和静态分开处理，静态走缓存，动态直连；调整刷新策略，避免频繁回源校验把缓存的收益抵消掉；对大文件的分片请求（视频、安装包）单独评估要不要缓存，因为它们会迅速吃掉盘的空间和 IOPS。
一句话总结这一节：命中率是"内容属性"和"人群行为"的函数，不是"机器规格"的函数。看到命中率低，先看响应头和流量构成，别先看采购单。
把前面几节收拢一下，办公网出网代理的"慢"基本可以归成几类，每一类看什么指标、动什么资源，是完全不同的。搞混的代价就是花钱买了不解决问题的资源。
出口带宽真的打满。特征是所有人的大文件下载和视频都明显变慢，而打开小页面反而还好；带宽曲线长时间贴着天花板；此时的排队是"字节排队"。这种慢才需要扩带宽，而且加 CPU、加内存、换盘都对它毫无帮助。判断标准很简单：带宽利用率是否长期接近上限。
新连接建不上。特征是页面直接打不开、报连接超时或连接被重置，重试偶尔能成功；CPU 和带宽都很闲；连接数、TIME_WAIT 数量、文件描述符使用率顶在高位。这种慢靠加内存、调文件描述符上限、扩大本地端口范围、优化 TIME_WAIT 相关参数、增加出口 IP、横向拆分来缓解。加 CPU 核数基本没用，扩带宽更是完全无效。
首包很慢但传输正常。特征是网页白屏一段，一旦开始出内容就很快。排队发生在传输之前，最常见的是 DNS 解析，其次是握手和代理内部队列。这种慢要靠本地缓存解析器、调超时和并发来解决，加带宽一点用都没有——因为等待期间根本没有流量。还有一种"命中请求也慢"，属于第四类：磁盘等待时间极长、IOPS 打满，要靠换更快的盘、改存储引擎、加大内存缓存来缓解。
把这几种情况摆在一起看，就能得出一个很干脆的结论："网慢"是一个症状，不是一个诊断。在动手加任何资源之前，先花十分钟确认是上述哪一种，能省下一笔相当可观的采购费和一轮无意义的变更。
| 现象 | 先看哪个指标 | 大概率的瓶颈 | 加什么资源有效 | 加什么没用 |
|---|---|---|---|---|
| 出口带宽打满 | 带宽利用率长期接近上限 | 字节排队，水管本身不够粗 | 扩出口带宽、按流量账单调整计费口径 | 加 CPU 核数、加内存、换更快的缓存盘 |
| 新连接建不上 | 并发连接数、TIME_WAIT 数量、文件描述符使用率 | 连接表或本地端口池耗尽，代理是连接放大器 | 加内存、调高文件描述符上限、扩大端口范围、增加出口 IP、横向拆分 | 加 CPU 核数、扩带宽 |
| 首包很慢但传输正常 | 首包时间、代理内部 DNS 排队与解析时延长尾 | 解析排队或握手排队，等待期间零流量 | 本地缓存解析器、调超时与解析并发、清理异常地址族查询 | 扩带宽、换缓存盘 |
| 缓存命中率持续偏低 | 命中率、响应头可缓存性、请求域名重叠度 | 内容本身不可缓存或人群行为无重叠 | 改缓存策略：动静分离、为高重叠流量单独设规则、调整刷新周期 | 加机器、加内存、扩带宽 |
| 部分域名时好时坏 | 按域名拆分的解析时延、上游递归服务可用性 | 上游解析服务抖动或源站本身不稳定 | 换可靠的上游递归、本地缓存、对该域名单独设置超时 | 加内存、加 CPU 核数 |
把前面的结论落到一张采购单上，顺序很重要。很多团队是倒着来的：先定带宽，再看 CPU 和内存，盘随便挑一块大容量的，剩下的参数等出问题再说。这个顺序几乎必然导致"带宽很宽但打开网页很慢"。
合理的顺序是这样走的。
先数客户端，估并发连接数。把要出网的机器和人数数清楚，乘以每个客户端的典型并发连接数（浏览器按域名并发加上长连接保持，量级在几十到几百），再乘以一个峰值系数的余量。这个数是一切后续配置的地基。注意研发网和办公网的数法不同：研发网的并发来自构建任务、包管理器和自动化脚本，峰值可能集中在某个时刻；办公网的并发来自人的操作，峰值集中在上午和午后。
由并发连接数定内存和文件描述符。并发一万条和并发十万条对内存的要求不是一个量级，同时文件描述符上限必须明确高于你的并发目标，还要给日志和缓存文件句柄留富余。这里要一次性把系统级限制、进程级限制、应用自身限制三处都对齐，只改一处等于没改。
接着定端口范围和连接跟踪表。按"端口池大小除以 TIME_WAIT 时长"这个思路，估算每秒新建连接的上限，看是否够用。不够就扩端口范围、开复用、加出口 IP，或者直接横向拆成多台。这个上限是硬算术，加 CPU 解决不了。同时把内核连接跟踪表也调到匹配的数量级，别让它成为隐藏的丢包点。
再定 DNS。这台机器上应该有一个本地的带缓存解析器，而不是让代理直接去问外部递归。同时把超时、并发、负缓存时长这几个参数设成明确的值，而不是留默认。别忘了验证 IPv6 的查询行为，别让不通的地址族平白增加等待。
然后才轮到磁盘。按预期命中量和平均对象大小估算随机读写 IOPS，先选能满足 IOPS 的盘型和存储引擎，再按"想保留多久的对象"倒推容量。缓存目录的层级数按预期对象总数来定。访问日志单独规划容量和轮转策略，别跟缓存盘混在一起。
最后才是带宽。带宽决定的是网卡选型和月流量账单，它应该由实际的峰值吞吐和流量预算来定，而不是反过来主导整台机器的规格。而且带宽口径最好选能按月调整的，因为办公网的流量模型会变，一开始估不准很正常，留好调整空间比一次估准更重要。
还有一个贯穿全程的东西：这台机器的选型重点应该是能自己定操作系统、自己定磁盘类型、自己定磁盘与带宽的配比。出网代理不属于那种"标准化配置随便挑一台就行"的负载，它对磁盘类型和内核参数的可控程度要求高，对带宽的弹性要求也高。像一万网络（朗玥科技旗下，深耕 19 年，成立于 2007 年，总部深圳南山）这类提供 BGP 多线、并且由工程师 1 对 1 协助部署环境的服务，价值就体现在这里：机器规格和配比能按你自己的估算来定，而不是从几个固定套餐里挑一个凑合。具体规格与资费以官网实时信息为准。
访问控制与留痕要在同一轮里一起设计，因为它们是上线的目的之一：域名白名单、分用户的访问策略、日志内容和留存周期，这些决定了 ACL 的复杂度（复杂 ACL 也会消耗 CPU，别忽略）和日志盘的容量。最后再重复一遍边界——这类出网代理的用途应限定在企业办公网出网治理、访问控制、访问留痕、数据采集出口这类合规场景，具体用途需符合当地法律法规与运营商要求。
别从人数直接推台数，先从并发连接数推。把客户端数乘以每客户端的典型并发连接数，再乘一个峰值余量，得到目标并发；然后看单台能撑到多少——这个上限由文件描述符、端口池、内存、以及是否跑多工作进程模式共同决定。人数不多但每人开几十个标签页的场景，并发可能比一个几百台服务器的机房还高。台数的另一个决定因素是高可用和滚动维护：只要业务不允许出网中断，就至少两台，否则一台就够。反过来说，如果你只有十来个人，一台低配机器绰绰有余，甚至不该单独买机器。
要看"出网中断"对你的业务意味着什么。对做数据采集或者对接第三方接口的场景，中断意味着任务失败和重试，通常值得做双机；对普通办公网，断十分钟更多是抱怨，可以接受一台加快速恢复预案。做高可用时，客户端侧的故障切换方式要一并设计——用 PAC 脚本可以做优先级和失败回落，用虚拟 IP 配合健康检查是另一种思路，两者对客户端配置的要求不同。注意双机不等于双份缓存，两台的缓存是独立的，切换过去之后命中率会掉一段时间。
默认不能。普通正向代理处理 HTTPS 用的是 CONNECT 隧道，它只负责把字节从客户端搬到源站，看不到内容，也就无从判断能不能缓存、缓存多久。想缓存就得在代理上做 TLS 中间人解密，由代理重新签发证书，代价是要在所有客户端上信任一个自签根证书，并且这会让员工的加密流量在代理上变成明文。这既是技术工程，也是合规与告知问题，必须有明确制度，不能悄悄上。如果解密这条路走不通，那缓存的收益就集中在少数可缓存的明文流量和包管理器这类场景上，别指望整体命中率能有多高。
会，而且是很典型的那种：所有人的流量都从这一个进程过，它挂了全网上不去。降低风险的办法有几层——进程级有自动拉起和看门狗；机器级有双机；网络级有明确的切换机制和兜底直连策略（允许在代理不可用时放通部分必要访问，具体按本单位的安全要求定）。另外要单独评估"代理假死"的情况：进程还在、端口还通，但连接建不上或者解析不返回，这种状态比直接挂掉更难处理，健康检查要能识别出它，不能只做端口探测。
留存周期先问合规和审计要求，再倒推容量，别反过来。日志是顺序写，对随机 IOPS 不敏感，但量很大——高并发场景下每天几十 GB 并不罕见。要点是轮转和压缩必须配好，压缩后的体积通常能降到很小比例；日志盘要和缓存盘物理分开，避免缓存盘的随机 IO 和日志的顺序写互相干扰；还要定好归档和清理策略，并且把"日志盘写满"当成一个真实会发生的故障来监控——盘满之后 Squid 的行为可能比你想象的激进。如果留痕要求高，建议把日志同步到独立的存储或日志系统，而不是只躺在本地盘上。
这是上线前必须做、且必须验证的一项。默认配置下如果监听地址或访问控制没设好，公网上的扫描器很快就会找到它，然后你的出口 IP 会被拿去发各种请求，后果是带宽被吃、出口 IP 进各种黑名单、甚至惹上麻烦。做法上：只监听内网接口，不要监听公网地址；访问控制列表默认拒绝，只对明确的内部网段放行；对 CONNECT 方法限制目标端口（只放通必要的端口）；在边界防火墙上把代理端口对公网完全关闭。做完之后一定要从外部网络发起一次真实的连接尝试——从公网去连你自己的代理端口，确认确实连不上，别只盯着配置文件看。
共用出口 IP 对接白名单时，这是最常见的运营问题，因为同一个 IP 上的所有人都共享它的声誉——任何一个人的异常行为都会让整个出口被封。缓解手段有几个层次：给对接第三方的流量单独用一个或一组出口 IP，跟普通办公流量分开；对采集类任务做限速和并发控制，别把对方打急；在代理上为不同目标域名配置不同的出口地址，把声誉风险隔离。真的被封了，先确认是被哪一方封的、触发原因是什么（频率、行为特征、还是内容），再决定是换 IP、降速、还是联系对方解封。另外要提前准备可用的备用出口，别等封了才想起来申请。
本文讲的是出网代理在工程上的通用原理，来源是公开的技术共识和可推演的资源模型（连接数与文件描述符、端口池和 TIME_WAIT 的算术关系、随机 IO 与顺序 IO 的差异、正向与反向代理在 TLS 和缓存上的结构性区别）。文中没有任何实机测试数据，也不提供任何来自真实环境的测量数字——包括但不限于并发连接上限、命中率、IOPS、解析时延的具体数值，因为这些值高度依赖你的硬件、内核版本、配置参数和实际流量构成，抄别人的数只会误导自己。所有涉及量级的地方都写成了量级描述，请你在自己的环境里用真实流量自行验证确认。
文中提到的参数名、存储引擎、替换策略等属于通用概念，具体名称、默认值和可配置项随版本变化，请以你使用的版本官方文档为准。涉及一万网络的产品、规格、资费、带宽口径、防御能力等信息，一律以官网实时展示为准，本文不提供任何价格、带宽数字或防御数字的承诺。如需了解适合自建出网代理的服务器方案（可自行选择操作系统、磁盘类型以及磁盘与带宽配比），可进一步咨询确认，具体以签约时最新报价与合同为准。
Copyright © 2013-2020 idc10000.net. All Rights Reserved. 一万网络 科技有限公司 版权所有 深圳市科技有限公司 粤ICP备07026347号
本网站的域名注册业务代理北京新网数码信息技术有限公司的产品
