Developing or consuming web services and not using Charles? Well, you might be missing some necessary information that makes debugging quick, reliable and advanced. Chrome and Firefox have some good network monitoring built in already, but for Mac, Charles is King.

Whether integrating mobile, or other non-browser-facing web services, the same tooling becomes essential. Developers need to know what the request looks like, and what the response headers are. Basically, all the details surrounding the request & response when things go awry.

Local Traffic

Lets begin by understanding how Charles works underneath. You can setup Charles to act as a HTTP proxy. This means that it will take all requests and forward them onto the appropriate endpoint and then delegate back. Just fire up Charles and go to proxy > proxy settings as shown below.

By default, Charles is set up to use port 8888 on the localhost. This is set at the network level. To change it, open your operating systems network settings and click on the "proxies" tab.

All outward facing traffic on the machine should show up now in the Charles console. Say a user wants to see the traffic for local invocations, the suggestions are to either use the IP address assigned to the machine (DHCP) or set up a local indirection. For example, putting an entry for "" in /etc/hosts	localhost

Now when firing up an iOS simulator, all traffic going through will appear on the Charles console. It doesn't matter what port the traffic is on - 80, 8080, 3000, 4242, all will be proxied/sniffed.

Remote Traffic

For local traffic that method works pretty well. But, say a user wants to debug from their iOS device and see the traffic in Charles? Not a problem. First the iOS device and the computer running Charles need to be on the same WIFI network. Next, get the outward facing IP address of the computer (ex:, not the iOS device. In the wifi connection settings on the iOS device enter the computer's IP address and the Charles proxy (8888 as above). Like this:

Note: when running web containers, like node.js, make sure that the web application is listening on instead of This ensures the app will accept this outside traffic. It may take a little while until Charles asks to allow this outside IP address (the iOS device) to use the proxy. Remember to disable the iOS proxy settings when finished or all traffic will be slowed down or it will fail.


By dispelling some of the magic underneath debugging with Charles, developers are armed with an understanding of how Charles works and some tactics to use Charles for some non-browser based traffic:

  • local out of browser traffic (ex: iOS simulator)
  • remote out of browser traffic (ex: remote iOS device)

Newfound means will allow, hopefully, for more effective web application development.