Charles Proxy Setup & Configuration: Mocking And Manipulating API Behavior With A Local Proxy Server – Part 2

In this five-part article series, you will learn how to manipulate your API behavior with a local proxy server. After setting the scene with an introduction, we will now learn how to set up the Charles Proxy and its configuration.

In diesem Artikel:

To get started, please follow the official instructions to install Charles on your preferred platform.

On Windows, Charles is automatically configuring your system and browser settings to route all traffic through it when you start the program. The same applies to macOS when you confirm the permission dialog.

On Linux, things are slightly different. You have two options:

  1. Setting your http_proxy and https_proxy environment variables to localhost:8888. Many applications use the environment variables and, in general, will affect most of your network traffic.
  2. Installing a browser add-on for easy toggling between proxy on/off just for browser traffic, e.g., Proxy SwitchyOmega add-on for Chrome.

SSL Decryption

If you are going to work with HTTPS, you also need to set up SSL decryption. Without it, all traffic would be encrypted directly between API and frontend – which is good! With SSL decryption enabled, Charles will establish two secure connections. One to the API and one to the frontend. This way, Charles can read messages from both sides. It is a classic man-in-the-middle.

Follow these steps to activate SSL decryption. Replace * with your API, e.g.,

When you have already pointed your browser to Charles and are browsing to an SSL-decrypted page, you will notice a security warning about an invalid certificate authority.

Your browser is mistrusting Charles’ certificate, which is a good thing (otherwise, SSL would be entirely worthless).

To fix this, you need to either trust each site’s certificate permanently or trust the Charles root certificate. Read more about the platform specifications here.

Recording Your Traffic

Assuming you have everything up and running, you can now start your first traffic recording session. Click on the “Start Recording” button and wait a couple of seconds.

You will probably see a massive list of connections. Yes, browsers are very chatty, especially with many tabs opened.

With default settings, we see every single connection from our browser. We can fix this quickly: In the menu, click “Proxy” → “Recording Settings” → “Include” and then add your API’s hostname. For this demonstration, we’re using the services of to create a simple REST API.

You may have to restart Charles at this point, to apply the new settings without having some weird glitches.

Deactivate Caching

It’s essential to take care of caching. In case your API sends caching headers, Charles will serve cached contents automatically, and you will not be able to inspect a response’s body. In the menu bar, click “Tools” → “No Caching”.

Our first record will now look like this:

On the right side, the upper box shows the request, the bottom one the response.


In this short article, we have taken a look at how to install and set up Charles Proxy to record traffic and decrypt SSL traffic for testing and debugging purposes. Charles makes this process flawless, and we will use this as a base for the upcoming articles.

In the third article of this series, you will see Charles Proxy in action.

Mehr Artikel zu API, Tools

Aktuelle Artikel, Screencasts, Webinare und Interviews unserer Experten für Sie

Verpassen Sie keine Inhalte zu Angular, .NET Core, Blazor, Azure und Kubernetes und melden Sie sich zu unserem kostenlosen monatlichen Dev-Newsletter an.

Newsletter Anmeldung
Diese Artikel könnten Sie interessieren

Git Fixup: Wie repariere ich meine Historie?

Git gibt uns mit der fixup-Option eine einfache aber effektive Möglichkeit, kleine Versäumnisse nachträglich so zu korrigieren, dass sie gar nicht mehr auffallen. Wie das genau geht, wollen wir in diesem Artikel erforschen. Mein Kollege Yannick Baron hat in seiner englischen Artikelserie zu Git bereits den interactive Rebase behandelt. Dort hat er auch die Möglichkeiten des fixup kurz angesprochen. Hier wollen wir uns etwas intensiver mit diesem Feature befassen.

Verwendung für Postman-Tests: ASP.NET Core API-Dokumentation mit Swagger – Teil 10 [Screencast]

Im zehnten und letzten Teil sehen Sie, wie Sie aus der Dokumentation auch Postman-Tests generieren können.

Code-Generierung aus der Dokumentation: ASP.NET Core API-Dokumentation mit Swagger – Teil 9 [Screencast]

Im neunten Teil sehen Sie, wie aus unserer Dokumentation vollständige Clients generiert werden können.

Swagger-UI anpassen: ASP.NET Core API-Dokumentation mit Swagger – Teil 8 [Screencast]

Im achten Teil sehen Sie, welche Modifikationen Sie am Swagger-UI vornehmen können. Zum Beispiel die Einbindung eines eigenen Logos in die Dokumentation oder einige weitere Features die Swagger mitbringt, welche aber nicht von Beginn an aktiviert sind.

Einbindung von Authentication & Authorization: ASP.NET Core API-Dokumentation mit Swagger – Teil 7 [Screencast]

Im siebten Teil sehen Sie, wie eine API, die Authentifizierung benötigt, korrekt dokumentiert wird.

Dokumentation versionierter APIs: ASP.NET Core API-Dokumentation mit Swagger – Teil 6 [Screencast]

Im sechsten Teil sehen Sie wie Sie vorgehen können, um mehrere API-Versionen gleichzeitig zu dokumentieren und wie Sie diese Versionen in SwaggerUI einbinden.