Charles has traditionally (pre version 3.1) primarily acted as an HTTP proxy, with SOCKS proxy functionality available as well. However there are some performance issues that occur when using an HTTP proxy that result in the browser’s behaviour being different when running with or without Charles.

Note that SOCKS proxying is not the default yet in Charles as it has only just been made available.

Browsers limit the number of connections they will have open to a web server, in order to not overload the server. The HTTP/1.1 specification states that a browser should limit itself to 2 connections per server. For HTTP/1.0 different browsers have different limits.

This limit can cause loading problems with websites as only 2 files (pages / images / css / javascript etc) can be downloaded at once. To get around this issue, developers distribute resources across different servers. For instance, http://maps.google.com/ loads map tiles from mt0.google.com through mt3.google.com. That is 4 different server names, so even though these may actually all resolve to the same IP address and the same physical server, the browser treats them as different web sites each allowed 2 connections. This means that it can load 8 map tile images concurrently rather than the usual 2.

When browsers use an HTTP proxy (such as Charles in HTTP proxy mode) they impose various different limits and also limit the total number of connections to the proxy server itself, thus subtley changing the behaviour and performance of websites. This is a bad thing for users of Charles as Charles is intended to have as little effect as possible on the regular performance of the web browser.

Conversely, when browsers use a SOCKS proxy the proxy is ignored in the calculation of connection limits, so the browser behaviour and performance is as normal.

Therefore, Charles now supports use of the SOCKS proxy protocol as easily as HTTP proxying. Read how to configure Charles for SOCKS transparent proxying.