[{"data":1,"prerenderedAt":203},["ShallowReactive",2],{"blog:vpn-protocols-explained":3},{"zh-CN":4,"en":109},{"blocks":5,"faq":93},[6,9,11,13,15,19,21,23,25,28,30,34,36,39,41,44,46,49,51,53,55,57,60,62,64,66,69,71,73,75,77,80,82,84,86,89,91],{"type":7,"html":8},"p","翻墙协议是客户端和服务器之间约定好的一套传输规则——数据怎么打包、怎么确认收到、丢包了怎么重传，都由协议规定。先说结论：绝大多数人不需要手动选，客户端默认给出的那一项，已经是团队在速度、兼容性和稳定性之间权衡过的结果。",{"type":7,"html":10},"会真正关心这件事的，通常是两类人：网络环境本身特别受限，默认设置总连不稳；或者纯粹喜欢折腾配置，想搞清楚背后的原理。这篇讲清楚协议实际决定了什么，看完基本能判断自己属不属于需要关心的那一小部分人。",{"type":7,"html":12},"有一点先分清楚：协议不是加密，也不是节点，三者经常被混着讨论。协议管的是数据怎么打包和传输，节点管的是数据从哪台服务器出去，加密管的是内容会不会被看懂——这篇只讲第一个。",{"type":7,"html":14},"会问出这个问题的人，通常是看多了各类测评文章，发现不同工具都在强调自己「支持某某协议」，于是开始怀疑自己是不是也该弄明白这几个字母分别是什么。先把这个疑虑打消：知道这几个名字不会让连接变得更快，不知道也完全不影响正常使用。",{"type":16,"id":17,"html":18},"h2","bp-what","协议到底是什么",{"type":7,"html":20},"协议是客户端和服务器之间约定好的传输规则，数据怎么打包、怎么确认收到、丢包了怎么重传，都写在这套规则里。可以把它想象成两个人说话用的语言：聊的内容是一件事，用哪种语言组织这句话，是另一件事。",{"type":7,"html":22},"举个例子，同样是寄快递，选普通快递还是加急快递，包裹里的东西不会变，但打包方式、路上经过几个中转站、出问题以后怎么补寄，规则完全不同。协议之间的差异大致是这个量级的事情，发生在完全看不到的底层，不影响你要传的「内容」本身是什么。",{"type":7,"html":24},"「翻墙协议」这个说法本身没什么特殊成分，就是翻墙工具用的传输协议，跟「协议」这个词在其他网络场景里的意思是一回事，不存在额外的黑话。",{"type":16,"id":26,"html":27},"bp-differences","协议之间到底差在哪",{"type":7,"html":29},"不同协议之间的差异，可以归纳成三个方面，普通人只需要知道方向，不需要记住具体名字。",{"type":31,"id":32,"html":33},"h3","sub-1","速度与兼容性",{"type":7,"html":35},"有的协议为了追求效率，把结构做得很轻，传输速度快，但对复杂网络环境的适应性偏弱；有的协议反过来，牺牲一点效率，换取在各种受限网络下都尽量连得上。打个比方，轻量结构的协议像轻装出行，跑得快，但遇到复杂路况时应变能力有限；结构更完整的协议像带了整套工具出门，遇到障碍能绕得过去，只是背的东西多一些，速度上略吃亏。两者是一种权衡，不存在「哪个绝对更好」，只有「哪个更适合当前这条线路」。",{"type":31,"id":37,"html":38},"sub-2","切换网络时的表现",{"type":7,"html":40},"手机从 Wi-Fi 切到移动数据，或者从一个热点切到另一个，连接都需要重新建立。不同协议在这个环节的表现不一样：有的能快速恢复，几乎感觉不到中断；有的需要完整重连一次，中间会空白几秒钟。这也是通勤路上从地铁信号切到地面信号时，有的人几乎没感觉、有的人要等几秒才刷新出页面的原因之一——当然，信号本身强不强、基站切换快不快，同样会叠加进这几秒钟里，协议只是其中一个变量，不是唯一变量。",{"type":31,"id":42,"html":43},"sub-3","对网络设备的可见度",{"type":7,"html":45},"部分网络设备不去识别具体是哪个协议，而是看流量本身的样子——如果一段流量的模式很像加密隧道，不管协议叫什么名字，都可能被单独挑出来处理。这层判断和「协议好不好」没什么关系，纯粹是当地网络设备的策略松紧决定的：同一个协议，在家庭网络里毫无障碍，换到管得严的网络环境下可能就被限制，这不是协议本身的缺陷，是所处环境的规则不同。公司或校园网把 VPN 拦了里提到的流量识别，说的正是这一层，跟协议的名字关系不大，跟流量呈现出的特征关系更大。",{"type":16,"id":47,"html":48},"bp-troubleshoot","卡顿的时候，换协议有用吗",{"type":7,"html":50},"遇到卡顿，换协议不是第一个该试的动作。前面提过，协议影响的是效率和稳定性这类相对细微的差异，真正决定网速快慢的，通常是节点离目标网站够不够近、线路当下拥不拥堵——这两项的影响，比协议之间的差异大得多。",{"type":7,"html":52},"合理的排查顺序是先换节点：同一个协议换个地区试试，如果问题消失，说明是节点或线路的事；换了节点还是一样卡，才轮到怀疑协议或者更底层的网络限制。多数客户端不把协议选项摆在显眼位置，也是因为这个原因——它不是用户日常需要动的那个变量。",{"type":7,"html":54},"极少数情况下，换节点没用，换个连接方式却立刻恢复正常，这时候才能确定问题出在协议这一层，通常发生在网络限制比较特殊的环境里，不是日常场景的典型表现。",{"type":56},"downloads",{"type":16,"id":58,"html":59},"bp-practice","在实际使用中你会在哪见到这个词",{"type":7,"html":61},"多数人第一次注意到「协议」这个词，是在某个客户端的设置菜单里翻到一个下拉框，里面列着几个选项，默认选中一项，写着「自动」或者「推荐」。这个默认选项通常就是团队权衡过速度、兼容性和稳定性之后给出的结果，不是随手定的。",{"type":7,"html":63},"另一个常见场景是换了网络环境以后突然连不上，部分客户端会提示「尝试切换连接方式」，这背后其实就是在换协议，只是产品把它包装成了一个动作，用户不需要认识术语本身就能用。",{"type":7,"html":65},"还有一种场景是看测评文章或者别人的推荐帖，里面提到某个工具「支持多种协议，可以自己选」，把这个当成加分项来介绍。这个功能确实存在，对喜欢折腾的人是加分项，但不代表不支持手动选的工具就更差——多一个选项和用不用得上是两件事，日常体验主要看默认那一项调得好不好，不是选项列表有多长。",{"type":16,"id":67,"html":68},"bp-limits","协议不能决定什么",{"type":7,"html":70},"协议不是加密——加密管的是内容会不会被看懂，这是完全独立的一层，VPN 加密入门专门讲了这部分，跟协议是两件不同的事，不要混在一起判断。",{"type":7,"html":72},"协议也不是代理——代理是转发流量的中间服务器，请求先到代理再由它转发出去，\u003Ca href=\"\u002Fblog\u002Fwhat-is-a-proxy\u002F\">代理和 VPN 的区别在哪\u003C\u002Fa>专门讲了这一层，跟协议要解决的问题完全不是一回事。",{"type":7,"html":74},"协议也不是节点——节点决定数据从哪台服务器出去、出去以后显示在哪个地区，换节点是换地理位置，换协议是换传输方式，两者经常一起被调整，但解决的是不同的问题，\u003Ca href=\"\u002Fblog\u002Fvpn-server-location-explained\u002F\">服务器选哪个地区最合适\u003C\u002Fa>专门讲节点这一层。",{"type":7,"html":76},"协议也不能保证网速上限——线路本身拥堵、节点距离远，协议再怎么优化都补不回这部分损失。协议影响的是效率和稳定性，不是带宽这个天花板本身。",{"type":16,"id":78,"html":79},"bp-decide","普通用户到底要不要手动选",{"type":7,"html":81},"回到开头的问题：关心不关心，答案对多数人是不需要。客户端默认给的选项，已经是团队在速度、兼容性、稳定性之间权衡过的结果，自己瞎选不一定比默认的更好，搞不好反而更差。",{"type":7,"html":83},"举个具体点的例子：如果在单位网络里 VPN 总是断断续续，换到家里的网络就很稳，那大概率不是协议的问题，是网络环境本身的限制，回头看协议这一层能做的有限；如果纯粹是喜欢在设置里点来点去看看有什么变化，那随便试，不会把账号或者设备弄坏，顶多切回默认。",{"type":7,"html":85},"值得花时间了解这一层的，通常是网络环境确实很受限、默认设置总是连不稳的那一小部分人，想知道客户端里那几个选项分别适合什么场景；剩下的大多数人，把这一层交给软件自己判断，是更划算的选择。",{"type":16,"id":87,"html":88},"bp-final","总结",{"type":7,"html":90},"协议决定的是数据怎么打包和传输，具体表现在速度与兼容性的权衡、切换网络时恢复的快慢，以及被网络设备识别的难度上——它不是加密，不是代理，不是节点，也不是网速的天花板。普通用户绝大多数场景不需要手动选。",{"type":7,"html":92},"快橙把这一层完全交给客户端自己处理，你只需要点连接，不需要在一堆缩写里挑一个。\u003Ca href=\"\u002Ffeatures\u002F\">功能介绍\u003C\u002Fa>有更完整的说明，注册后每天有免费试用时长，先连上用一次比看十段解释都直接。",[94,97,100,103,106],{"q":95,"a":96},"快橙用的是哪个协议？","我们没有公开具体的协议名称。一键连接是产品设计的重点，这层选择交给客户端自己处理，你不需要知道背后跑的是什么，也能正常连接和使用。",{"q":98,"a":99},"协议会不会决定网速上限？","不会。协议影响的是连接效率和稳定性，线路本身拥不拥堵、节点离得远不远，对网速的影响通常更大。换协议解决不了线路拥堵这类问题。",{"q":101,"a":102},"为什么有些工具会自动切换协议？","多数客户端会在网络环境变化时，自动挑一个当前能用、效果较好的选项。这个判断交给软件实时做，比用户手动切换更快，也更不容易选错。",{"q":104,"a":105},"公司或学校网络会不会因为协议被拦？","有可能，但拦截通常针对的是流量呈现出的样子，不是协议的名字——不管用哪个协议，只要流量模式像是加密隧道，都可能被单独处理，这属于网络设备识别流量特征的范畴。",{"q":107,"a":108},"普通用户到底需不需要手动选协议？","绝大多数场景不需要，客户端默认给出的选项已经是权衡过的结果。只有网络环境特别受限，或者本身就喜欢折腾配置，才值得花时间去看这一层。",{"blocks":110,"faq":187},[111,113,115,117,119,121,123,125,127,129,131,134,136,139,141,144,146,148,150,152,154,155,157,159,161,163,165,167,169,171,173,175,177,179,181,183,185],{"type":7,"html":112},"A protocol is the set of rules a client and a server agree on for moving data: how it gets packaged, how receipt gets confirmed, how a lost piece gets resent. The short answer up front: almost nobody needs to pick one by hand. Whatever a client selects by default is already a balance the team worked out between speed, compatibility and stability.",{"type":7,"html":114},"The people who genuinely need to care fall into two groups: a network so restrictive that the default setting never holds steady, or someone who simply enjoys tinkering with configuration for its own sake. This article covers what a protocol actually decides, and by the end you should know which group, if either, you belong to.",{"type":7,"html":116},"One thing worth separating out first: a protocol is not encryption, and it is not a node. The three get lumped together constantly. A protocol governs how data is packaged and moved. A node governs which server the data leaves from. Encryption governs whether the content can be read. This article covers only the first one.",{"type":7,"html":118},"Anyone asking this question has usually read one too many comparison articles that all boast about "supporting protocol X", and started wondering whether they are missing something by not knowing what those letters mean. The worry can be put to rest early: knowing the names will not make a connection faster, and not knowing them changes nothing about normal use.",{"type":16,"id":17,"html":120},"What a protocol actually is",{"type":7,"html":122},"A protocol is the transport rule a client and server agree on ahead of time: how data gets packaged, how receipt gets confirmed, how a dropped piece gets resent. Think of it as the language two people use to talk to each other. What they are actually saying is one thing. Which language carries the sentence is a separate one.",{"type":7,"html":124},"Here is an analogy. Standard shipping and express shipping carry the same parcel, but the packaging, the number of stops along the way, and how a lost parcel gets reshipped are all handled differently. The differences between protocols sit at roughly that scale, buried in a layer you never see, and none of it changes what the "content" you are sending actually is.",{"type":7,"html":126},"There is nothing special about the phrase itself. It is simply the transport protocol a circumvention tool happens to use, the same meaning "protocol" carries in any other networking context, with no extra jargon attached.",{"type":16,"id":26,"html":128},"Where protocols actually differ",{"type":7,"html":130},"The differences between protocols boil down to three things. Knowing the general shape is enough; the specific names are not something you need to memorise.",{"type":31,"id":132,"html":133},"speed-versus-compatibility","Speed versus compatibility",{"type":7,"html":135},"Some protocols keep their structure light to chase efficiency, which makes them fast but less adaptable to a hostile network. Others trade away some of that efficiency to stay connectable across a wider range of restrictive networks. Think of the lightweight one as travelling with a small bag: quick, but limited when the road gets complicated. The heavier one travels with a full toolkit: slower to move, but able to work around obstacles the light traveller cannot. Neither is "better" in the abstract. Only "better suited to this particular route" makes sense as a comparison.",{"type":31,"id":137,"html":138},"behaviour-when-the-network-switches","Behaviour when the network switches",{"type":7,"html":140},"Moving a phone from Wi-Fi to mobile data, or from one hotspot to another, forces the connection to rebuild. Protocols differ in how that moment feels: some recover almost instantly, with the interruption barely noticeable; others need a full reconnect, leaving a few seconds of dead air. This is part of why the same app can feel different across devices the moment the network changes underneath it — though signal strength and how fast the tower handoff happens get folded into those same few seconds, so the protocol is one variable among several, not the only one.",{"type":31,"id":142,"html":143},"how-visible-it-is-to-network-equipment","How visible it is to network equipment",{"type":7,"html":145},"Some network equipment does not bother identifying which protocol is running. It looks at what the traffic itself looks like. If a stream's pattern resembles an encrypted tunnel, it can get singled out regardless of what the protocol is actually called. This has nothing to do with whether a protocol is "good", and everything to do with how strict the local network's policy happens to be: the same protocol sails through a home network without friction and gets flagged the moment it hits a tightly managed one. That is not a flaw in the protocol. It is a difference in the environment it is running through. When a work or campus network blocks a VPN covers this kind of traffic recognition in more detail — it comes down to what the traffic looks like, far more than what the protocol is named.",{"type":16,"id":47,"html":147},"Does switching protocols fix lag?",{"type":7,"html":149},"Switching protocols should not be the first thing you try when a connection lags. As covered above, a protocol affects efficiency and stability, which are comparatively minor differences. What actually decides how fast a connection feels is usually how close the node sits to the destination and how congested the route is right now, and both of those matter far more than any gap between protocols.",{"type":7,"html":151},"The sensible order is to change the node first. Try a different region on the same protocol; if the problem disappears, it was the node or the route. Only if switching nodes changes nothing does it make sense to suspect the protocol, or a deeper network restriction. Most clients keep the protocol option out of the way for exactly this reason: it is not the variable you should reach for day to day.",{"type":7,"html":153},"In the rare case where changing the node does nothing but switching connection modes fixes it instantly, that is when the protocol is confirmed as the actual cause. This tends to show up only in unusually restrictive network environments, not as a typical everyday scenario.",{"type":56},{"type":16,"id":58,"html":156},"Where you actually run into the word",{"type":7,"html":158},"Most people first notice the word "protocol" inside some client's settings menu, tucked into a dropdown with a handful of options and one pre-selected, usually labelled "Automatic" or "Recommended". That default is normally the result the team already weighed across speed, compatibility and stability. It was not picked at random.",{"type":7,"html":160},"Another common moment is a sudden disconnection after switching networks, where some clients prompt something like "try a different connection mode". Behind that prompt is a protocol switch, just packaged as a single action so nobody needs to recognise the underlying term to use it.",{"type":7,"html":162},"A third moment comes from reading a comparison article or a recommendation thread that lists "supports multiple protocols, switchable by hand" as a selling point. That feature is real, and it is a genuine plus for anyone who likes to tinker. But a client without a manual switch is not automatically worse for lacking it — having the option and actually needing it are two different things. Day-to-day experience mostly comes down to how well the default is tuned, not how long the options list is.",{"type":16,"id":67,"html":164},"What a protocol cannot decide",{"type":7,"html":166},"A protocol is not encryption. Encryption governs whether content can be read, which is an entirely separate layer. VPN encryption, the basics covers that ground on its own; do not judge the two as if they were the same thing.",{"type":7,"html":168},"A protocol is not a proxy, either. A proxy is a middle server that forwards traffic on your behalf. \u003Ca href=\"\u002Fen\u002Fblog\u002Fwhat-is-a-proxy\u002F\">What a proxy actually is, and how it differs from a VPN\u003C\u002Fa> covers that layer, which solves a completely different problem from anything a protocol handles.",{"type":7,"html":170},"A protocol is not a node. A node decides which server your data leaves from, and which region it appears to come from afterward. Changing the node changes your apparent geography; changing the protocol changes how the data travels. The two often get adjusted together, but they solve different problems. \u003Ca href=\"\u002Fen\u002Fblog\u002Fvpn-server-location-explained\u002F\">Choosing a server location\u003C\u002Fa> covers the node side specifically.",{"type":7,"html":172},"Nor does a protocol guarantee a speed ceiling. A congested route or a distant node will not be fixed by any amount of protocol tuning. A protocol affects efficiency and stability, not the bandwidth ceiling itself.",{"type":16,"id":78,"html":174},"So should a regular user pick one by hand?",{"type":7,"html":176},"Back to the opening question: for almost everyone, the answer is no. The client's default is already a balance the team worked out between speed, compatibility and stability. Picking one yourself is not guaranteed to beat it, and it can easily end up worse.",{"type":7,"html":178},"Here is a concrete way to tell which camp you are in. If a VPN keeps dropping on your office network but stays rock-solid at home, that is almost certainly the network environment, not the protocol, and there is little a protocol change can do about it. If you just enjoy clicking through settings to see what happens, go ahead and experiment. It will not damage your account or your device; worst case, you switch back to the default.",{"type":7,"html":180},"The people worth spending time on this layer are a small group: those on a genuinely restrictive network where the default never holds steady, and who want to know what each listed option is actually good for. Everyone else comes out ahead by leaving this decision to the software.",{"type":16,"id":87,"html":182},"In summary",{"type":7,"html":184},"A protocol decides how data gets packaged and transported. In practice that shows up as a trade-off between speed and compatibility, how quickly a connection recovers when the network switches, and how easily network equipment can spot it. It is not encryption, not a proxy, not a node, and not your speed ceiling. Almost nobody needs to pick one by hand.",{"type":7,"html":186},"FastOrange leaves this entire layer to the client. You just tap connect, with no row of abbreviations to choose from. \u003Ca href=\"\u002Fen\u002Ffeatures\u002F\">See what it does\u003C\u002Fa> for the fuller picture. Every registered account gets free trial time daily, and connecting once tells you more than reading ten explanations of it.",[188,191,194,197,200],{"q":189,"a":190},"Which protocol does FastOrange use?","We do not publish a specific protocol name. One-tap connection is the point of the product, so this layer is handled by the client itself. You do not need to know what runs underneath to connect and use it normally.",{"q":192,"a":193},"Does the protocol set a ceiling on my speed?","No. A protocol affects connection efficiency and stability. Whether the route is congested and how far the node sits usually matter far more for speed. Switching protocols will not fix a congested route.",{"q":195,"a":196},"Why do some apps switch protocols automatically?","Most clients pick whichever option works best for the current network the moment conditions change. Letting the software decide in real time is faster and less error-prone than switching by hand.",{"q":198,"a":199},"Can a work or school network block me over the protocol?","Possibly, but the block usually targets what the traffic looks like, not the protocol's name. Any protocol whose traffic pattern resembles an encrypted tunnel can get singled out. That is network equipment recognising a traffic pattern, not the protocol itself.",{"q":201,"a":202},"Do regular users really never need to pick a protocol by hand?","Almost never. The client's default is already a balance the team worked out for you. It is only worth digging into this layer if your network is genuinely restrictive or you simply enjoy tinkering with settings.",1790199274181]