Generally a proxy is a long-running system service, and it builds and evolves knowledge of what outbound paths and upstream proxies are available and usable. This proxy launches when the device connects, and shuts down when it quits, so any knowledge it can acquire is likely to be stale.

The approach I took was to try everything at once -- initiate connections on every combination of network interface, proxy name and resolved IP address, and use whichever wins the race. Thereafter it starts with the last thing that worked, and only scatterguns after a timeout. Interestingly this makes regular desktop browsing more responsive too, but it's pretty abusive to the network infrastructure and is only safe for idempotent GETs.

The other interesting feature was handling Proxy Auto Config (PAC) files. These are chunks of javascript that take a desired host name and return the name/address of the proxy that should handle the request. I'd never come across one in the wild, but they're very common in corporate networks where there's free rein inside the firewall, but all external access is via proxies. The system facilities on OS X are sufficient that the task can be handled by calling CFNetworkExecuteProxyAutoConfigurationURL. Windows on the other hand can almost do the job. The WinHTTP library can handle a PAC specified with a network URL, but not with a local file. So when we see that the PAC is a local file we fabricate an HTTP URL referencing a port we're handling, and any request on that port returns the content of the PAC file.