转发服务和服务器经常被放在一起比较，因为它们都跟网络连接有关。但两者承担的角色完全不同：一个负责把请求送出去，一个负责处理请求并返回结果。搞混了会买错，买错了钱花了问题还在，退也退不掉，只能重新再买一次。
一个管路径，一个管内容，两边的定位从根上就不一样。
把一次访问拆开看就清楚了。请求先从你这里出发，经过若干跳到达目标；目标那边有个程序在处理，把结果送回来。转发服务负责的是前面那段路，服务器负责的是后面那件事。
先分清要解决的是路的问题，还是事的问题。
两者可以同时用吗？
可以，而且很常见。服务器负责跑业务，转发服务负责让访问从指定的地方出发。两者不冲突，只是部署的时候要注意转发规则别把服务器自己的出入流量也接管了。
判断需求属于哪一类，问一句就够了：我要的是让请求换个起点，还是让请求有个接收方。答案清楚，选型就不会跑偏。这一句话问下来，很多纠结当场就没了。
转发服务解决什么
转发服务解决的是来源问题。请求从它那里出去，对端看到的就是它的IP地址。这类服务不存数据、不跑程序，只做中转，所以评估的时候看的是地址质量、线路稳定性和并发能力，不看存储和算力，也别拿服务器的指标去比它。
服务器解决什么
服务器解决的是承载问题。网站、程序、数据都放在上面，评估看的是配置、带宽、可用性。它的出入流量怎么走是另一件事，别把两件事混成一个采购决策，混在一起谈，销售也乐得含糊。
常见混淆有哪些
最常见的是把转发服务当成能跑程序的地方，买回来发现什么都部署不了。反过来，把服务器当成能改来源的工具，配了半天发现对端看到的还是机房那段IP地址，两头的期待都落空，钱和时间一起搭进去。
怎么组合更省
业务量不大的时候，一台服务器加一组转发线路，比两头都买高配更划算。业务量上来之后，再按实际瓶颈加，别提前把配置堆满，堆满之后闲置的部分一样在计费。
路和事分开买，才好算账。
采购前问清哪几句
问转发服务要问并发和IP归属，问服务器要问配置和带宽。两边都问一句交付方式，看看是给账号还是给参数。问完这四句，基本能判断对方是不是在卖你想要的东西。
顺序建议
先定业务形态，再定要买哪一类，最后才比价格。顺序反过来，容易先被低价吸引，买回来才发现方向不对。