目前Surge的前置代理仅支持单个代理服务器，例如：
[Proxy]
ProxyA = ss, 1.1.1.1, 1234, encrypt-method=aes-256-gcm, password=4321, underlying-proxy = ProxyB
ProxyB = ss, 1.1.1.1, 12345, encrypt-method=aes-256-gcm, password=54321
在这种只能设置单一服务器前置代理的情况下，如果ProxyB出现了连通性的问题便只能通过修改配置文件来解决，或者手动在写配置文件时写入多个ProxyA(1)、Proxy(2)...分别underlying-proxy不同的服务器，这样做不仅效率低，配置文件的可维护性也差，具体表现为：
以我目前自己维护的一套配置文件为例，我是习惯将订阅转换为NodeList，然后新建不同国家的策略组（External Group），通过policy-regex-filter进行过滤。在这种情况下[Proxy]字段下除了我个人搭建的ProxyA外没有其他的服务器信息。我没有尝试过是否可以直接underlying-proxy策略组中policy-path的节点，但即使可以也会陷入上述ProxyA(1)、ProxyA(2)...的问题之中。其次，第三方服务器提供商的节点名称和数量也会因为一些原因而发生变化，这样甚至可能直接导致用户之前设置的underlying-proxy和第三方服务器提供商节点名称不一样的情况进而导致错误。
综上，我希望未来Surge的配置可以达到以下效果：
[Proxy]
ProxyA = ss, 1.1.1.1, 1234, encrypt-method=aes-256-gcm, password=4321, underlying-proxy = ProxyChain
[Proxy Group]
Proxy = select, ProxyA, US, JP, HK
US = select , policy-path = xxx.list, policy-regex-filter = "US"
JP = select , policy-path = xxx.list, policy-regex-filter = "JP"
HK = select , policy-path = xxx.list, policy-regex-filter = "HK"
ProxyChain = select, US, JP, HK
这样不必为了机场节点的增加（减少）、命名方式的改变而手动修改配置文件，当一部分节点出现连通性的问题时，可以在软件内手动切换至别的节点，而不必修改配置文件。至于延迟测试，为了避免一些潜在的问题，可以限定只允许underlying-proxy的策略组以及其内置的策略组均为select类型。
希望开发者能考虑我的以上建议，当然我也期待效率更高更优雅的解决方案。
