在地址栏敲下一个网址到页面显示，这一趟看似一气呵成，实际背后藏着一连串的握手——走代理IP时这套流程还会翻倍。数清楚它们，你就知道网页加载的「等待时间」都花在哪了。
这篇以一次普通网页访问为例，把每层握手挨个点出来。
第一层：TCP 握手，先建路
浏览器要访问目标站，第一步是和它建立 TCP 连接，完成标准的三次握手。这一步确认双方在线、协商好起点，为后续所有动作铺好路。
走代理IP时，这一步在「浏览器到转发层」和「转发层到目标站」两段各发生一次。两段都完成，TCP 层面的路才算通。
很多打不开网页的排查，第一步就是确认 TCP 握手有没有完成：完成了说明路是通的，问题多半在更高层；没完成，则要顺着代理IP链路一段段找哪里断了。
第二层：TLS 握手，再加密
现在的网页几乎都是加密访问。TCP 连接建好后，浏览器和目标站还要完成一次加密握手，协商用什么算法、交换密钥材料，之后的内容才加密传输。
TLS 握手的报文往来比 TCP 多几轮，耗时也更长，通常还需要额外的往返。它同样发生在两段连接上——代理IP转发层往往要分别和两端完成加密协商，这也是加密访问走代理更慢的原因之一。
第三层：请求与响应，不再握手
加密通道就绪后，浏览器发出 HTTP 请求，目标站返回内容，这些不再属于握手——它们是建立在前面两层握手成果之上的正式数据交换。
所以一次访问至少经历：TCP 握手（两段 × 三次）、TLS 握手（两段 × 多轮）。如果页面里还加载着其他域名的资源，每个新域名往往还要重复一遍这套流程。
把次数加起来，一个普通页面如果引用了几十个域名资源，浏览器实际完成的握手可能是几十次。握手次数一多，单次再快也会累积成可感知的等待，这也是页面优化常把减少域名数量作为重点的原因，代理IP链路访问时减少域名还能顺带减少建连次数。
把这些层数记在心里还有个实际用途：网页打不开时，能顺着握手层数判断断点。TCP 握手都没完成，是网络层问题；TCP 通了但 TLS 握手卡住，多半是加密协商环节；两层都通却还是白屏，问题才轮到应用层。一层层握手都是天然的路标，代理IP链路里这些路标会成对出现。
理解这个结构，优化方向就清晰了：减少需要重新握手的次数（连接复用）、缩短握手本身的耗时（选择 RTT 更小的链路），比盲目加带宽更能改善加载体验。
顺带解释一个常见现象：网页多开几个标签时，如果每个标签都各自建连，每个连接都要走一遍上面这套握手，总等待时间自然叠加。连接复用机制就是为省掉这些重复握手而生的。
一次访问两套握手起步：先 TCP 建路、再 TLS 加密，代理IP链路里每套还要乘二。把等待时间拆到这几层上，慢在哪一层就一目了然。