Proxy Settings
Controls the operation of the proxy server that is the core of Charles.
Ports
The proxy server operates on two ports, one for the HTTP proxy and on for the SOCKS proxy. The defaults for these are usually fine. You may need to change them if you have something already using one of the ports on your system.
Dynamic proxy ports enables you to let Charles choose available ports when it starts up. This is useful if you’re running Charles in a multiuser environment.
Decrypt SSL
You can turn on or off the decrypt SSL functionality. This defaults to on. If you turn this off Charles doesn’t interfere in SSL connections and all you will see is encrypted data in Charles.
Automatic Browser Configuration
Charles has a list of browsers and Operating Systems for which it can automatically configure proxy settings. This is a very useful and essential feature, otherwise you would have to configure and reconfigure your browser’s proxy settings everytime you wanted to use Charles.
You can turn on/off which browsers/OS proxy settings that are configured automatically when Charles is started. You can turn on/off proxy setting configuration while Charles is running by using the options in the Proxy menu.
Bypass Domains
This is a list of hostnames to bypass when using a proxy (ie. Charles). The list is passed on to the proxy settings in your browser/OS. Generally an empty list is fine, but if you have host names that can’t be accessed through Charles you could add them here.
The Bypass Domains list is a whitespace separated list of hosts and domains. If you enter a domain like xk72.com, most browsers will take that to mean bypass *.xk72.com as well.
SOCKS Transparent Proxying
SOCKS transparent proxying was introduced in Charles 3.1. Read more about the reasons for using SOCKS transparent proxying in HTTP vs SOCKS proxy.
Open the Proxy Settings in the Proxy menu. The easiest way to enable the SOCKS configuration is to click the “SOCKS Proxy Mode” button in the Quick Configuration panel. That will enable the SOCKS Proxy and configure your browsers to use SOCKS instead of HTTP.
It can be hard to observe the different behaviour. The easiest way is to visit http://maps.google.com/ and zoom in on the map. Click on the HTML page in the Charles tree (probably <default>) and then switch to the Chart view. Take a look at how many of the requests for images “mt?n=...” occur in parallel in the chart. Compare that between the HTTP and SOCKS modes. You should see approximately 2 concurrent map tile fetches with HTTP compared to 8 with SOCKS.
HTTP vs SOCKS Proxy
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.