第二，协议扩展性较差。这一条从实现原理上也能理解，GSLB是通过分析和改写服务器与客户端之间的应用协议交互信息实现重定向功能的，可能还要叠加一些权限判断、防盗链之类的定制功能。也就是说，应用层负载均衡需要对应用有一定的了解。所以对于新增加的应用协议，需要进行开发升级。而对那些不支持重定向的应用，还需要在GSLB/SLB上开发新的重定向接口，如果开展IDC业务，需要了解数据中心标准。
第三，安全性问题。在这种方式下，每次重定向都会通过与客户端之间的应用协议交互完成，所以在客户端可以通过协议分析了解到整个服务器架构，这会导致一定的安全隐患。
CDN服务基于IP路由的GSLB方式，好处在于使用者其实并没有购买或者开发一个GSLB设备，而是依靠公网上原有的路由设备来实现同样的功能，不需要对公网IP设备进行任何特殊配置，同时能够利用IGP的路由计算方式实现真正的就近服务和快速冗余备份。但如果仔细分析就会发现这种方式在多个POP点之间实现的负载均衡是一种概率上的均衡，而不是真正的均衡。
CDN服务如果路由器基于链路状态进行选路，那么上联端口大的那个负载均衡器被选到的概率就会大很多。如果某个热点事件是带有地域性的，用户都集中在同一个路由器上，那么这次热点事件的突发访问很可能就都被调度到同一个POP去。解决这种概率不均的方式是在部署POP点或SLB的时候就充分预测路由均衡性，尽量选择路由对称的位置。
基于IP路由方式的GSLB另外一个突出的局限性在于无法实现会话保持。因为IP网是基于包交换的网络，也就是说，路由器有责任为每个数据包选择一条它认为最好的路径。但是在用户访问Web页面时，会产生多个TCP连接，CDN服务这些连接被封装成多个数据包进行传送。路由器会把每个数据包都看成是独立的，并不关心它们属于哪个TCP连接。
但是从应用层的要求考虑，应该把从一个终端发送的所有数据包传送到同一个本地均衡器上（同时本地均衡器应该保证同一个用户的同一个连接的数据包交付给同一台具体的服务器），这样才能保证用户业务使用的连续性。CDN服务理想情况下，所有路径的路由开销保持不变，这样路由器就会为同一个连接的每个数据包选择相同路径。但现实中很少会出现这种情况。
任何一个链路的故障，或者过度拥塞，都有可能导致路由开销的变化。最终结果就是，路由器在转发数据包时，可能突然从一条链路转移到另外一条链路上，这不仅会中断当前的连接，而且会中断会话保持，丢失所有的用户信息，比如购物车信息等，用户的体验会非常差。
