Mock and Manipulate Network Traffic to Test Your Mobile Application Via Charles and Proxyman

Mock and Manipulate Network Traffic to Test Your Mobile Application Via Charles and Proxyman

What are Charles and Proxyman? 

Charles and Proxyman are super efficient tools to capture and manipulate the HTTP(s) requests and responses of your mobile application, making it fairly easy to see if something goes wrong. The different ways of editing the request and responses, from modifying the status codes, headers, body, etc., that allow you to simulate both positive and negative test scenarios, these applications can help you test your application easily and thoroughly. 

Charles Proxy and Proxyman share several common features and functionalities:

  • Editing the HTTP requests and responses: Users can intercept, view, and modify HTTP/HTTPS requests and responses in real-time, facilitating debugging and testing scenarios. 
  • Breakpoints: Particularly useful to intercept or, in other words, pause the network call so you can make changes to the request and responses.
  • Repeat requests to test network changes
  • Simulate different internet connection speeds: You can simulate different network conditions to observe the behavior of your application. It is useful for testing loading screens, timeouts, and so on.

Charles has a free trial of one month that you can use to explore the tool, and Proxyman is completely free for the basic features but puts some limitations - some of them are mentioned further along in the article. Let’s compare them and see how we can use some of these features on both tools.

In general, there are a huge number of possibilities these tools can be utilized. In this blog we are going to focus mainly on editing the HTTP requests and responses via Map Local and Rewrite features. Additionally we will see how to effortlessly communicate the results and findings of our testing sessions by sharing and reading it. Before we dive in with the practical examples and further explanation what these features are and how they can help, let’s first see how we can get started.

Getting started

You can install Charles and configure it fairly easily following the official documentation. The same goes for Proxyman, you can download it from here and follow the instructions for the setup on their documentation page.

Once you are all set up, you will be able to see the traffic in Charles or Proxyman and can start the magic of exploiting their features to try to break your application.

Usual app traffic visual representation in Charles (left) and Proxyman (right)

For more general information about Charles in debugging HTTP/HTTPs requests, the throttling feature, and the use of Fiddler, you can check out this TestDevLab blog post.

All practical examples in this blog post will use a free food delivery application called Kliknijadi that you can find on the Play/App Store. You can download it and try to execute the same steps that we will explain here, either by using Charles or Proxyman or even both, so you can compare them and practice them yourself.

Map Local 

Map Local allows you to modify a request in such a way that its response appears to be delivered from the same location as the initial response while, in actuality, it is sourced from a completely different location, for example, a local file. The "Map Local" feature is a functionality that allows testers and developers to map a local file to a specific URL or path, meaning, when a request is made to that URL or path, the proxy will respond with the content of the mapped local file.

Map local can be used by testers in various situations to achieve testing even when we don’t have the right preconditions or state of the app meaning we can use map local to:

  • test different error codes which we could not reach because of lack of test setup or data
  • test UI of the app, like localization, push notifications, authentication failures etc.
  • test UI changes on app with disregard of the backend (backend changes could be not implemented yet or pending)

Map Local is particularly useful when you want to test the UI of the application by modifying the body of the sent request and make the response display something of your own to see how it will display on the actual app. You mock the data that is sent to the app to get the desired result. For our application, we will be changing one of the titles displayed by making it longer so we can check how long titles are handled in case one of those is sent by the backend in a real-life scenario. Let’s see how we can do this with Charles and Proxyman.

Map local with Charles Proxy

The first step is to download the actual response displayed in Charles. Here is how it currently looks in our example:

The original response returned from Kliknijadi app in Charles

You can go to the endpoint that you want to modify, right-click on it, and several options will be displayed. Choose the “Save response…” option and a window will appear to save the file locally. Save it in a location of your preference.

To modify it, you need to open the file in a text editor. Sometimes, these files are not displayed in a pretty manner, so make sure to be careful when making the desired changes. After the modification is done, save the file. As mentioned previously, we will be changing one of the titles displayed in the app from the original response.

Saved response from Charles, opened in VS code for modification

To actually modify the request so that it displays our modified response, we need to:

  • Right-click on the same request that we just saved the response from 
  • Choose the “Map Local…” option 
    • the “Edit mapping” window will appear, and it actually already has the right information populated in the “Map from” section)
  • Upload our local file in the “Map to section”
Response modification in Charles

Once we confirm our changes, we are ready to send the request. We can do that by refreshing the window or going a step back in the application under test and opening the same window again. In both cases, our request will be triggered again. The modified response will be received, and it will be reflected on the front end of the application.

Modified response in Charles, reflected in the Kliknijadi app

As you can see, our application does not display the long title in full and does not accommodate the front end to fit this title in the manner of expanding to view, truncating it, or similar.  Depending on the expected result, you can check whether your application promotes the desired behavior.

Map local with Proxyman

Now, let’s see how we can do the Map local with Proxyman. Again, we need the actual response, but in the case of Proxyman, we don’t need to save it locally. Instead, we copy it from the Response > Body section with a right-click and copy option.

Copy the actual response directly from Proxyman UI

Once we have copied the body, we can map it locally, reaching the same effect we had with Charles. We can do that by

  • Right click on the endpoint, 
  • Hovering over the “Tools" option 
    • another submenu opens that contains the option “Map Local…”
  • Choose the “Map Local…” option 
    • will open the Map Local Editor window
  • Paste the body we copied in the editor in the Local file tab 

After that, we do the changes to the title in our example app and save it by clicking on the “Save” button.

Keep in mind that the free Proxyman application has some limitations, i.e, it limits the map local endpoints to two, which is not a problem if you need to alter only two responses, but it might limit you if you want to do extensive testing and put some pressure on your application.

Paste the response and make modifications directly in Proxyman UI

After saving the response, we can go ahead and call the endpoint again. The front end should update with the response we modified, which impersonates the real response. The updated title on the front end is the same as we saw it with Charles.

Modified response in Proxyman, reflected in the Kliknijadi app

Another way to do the Map local is by saving the response body like we did with Charles. For that you need to:

  • Right-click on the endpoint 
  • Choose the Export option 
  • Choose the Response body option 
    • this will allow you to save the body locally and then proceed with altering it the same way we did with Charles 

There is an option to select a local file in the Map Local Editor window so you can upload your changes.


Another way of modifying the request so that we get the desired response is the Rewrite option. 

The "Rewrite" feature in Charles Proxy allows users to dynamically modify the content of HTTP requests and responses as they pass through the proxy. This powerful capability is particularly useful for testing and debugging scenarios, as it enables users to alter various aspects of the traffic. The rewrite option can be used to:

  • Add / Remove / Modify the Header
  • Modify the Host, Path or URL
  • Add / Remove / Modify a Query Parameter 
  • Alter the Response status or 
  • Modify the request or response body 

This option is exclusive to Charles, but let’s see how we can get the same effect with Proxyman as well. For this example, we will be changing the status code of the request from 200 OK to 500 Internal Server Error code. If you are new to API and want to know more about it, including the meaning of the status codes, check out this TestDevlab blog.

Rewrite with Charles Proxy

In Charles, you can find the Rewrite option in the Tools menu. Choosing the Rewrite option will open a window in which you can make your own settings. To make the settings for our example, we need to:

Rewrite option steps displayed by order in Charles

  • Enable the rewrite option by selecting the “Enable Rewrite” 
  • Click on the Add button at the bottom of the window
    • This will enable the location, type, and action options on the right side of the window 
  • Add a name for our rewrite settings
  • Click on “Add” button on the Location settings
    • This will open the “Edit location window”. In the “Host” input field on this window, we paste the endpoint we want to modify. The other input fields, Charles will automatically populate if you click on any of them. The location can be saved by clicking on the “OK” button. The desired endpoint can be copied from the traffic in Charles in advance.
Populate the “Edit location” window from the “Rewrite” option in Charles
  • Click on the “Add” button in the Type and Action section. 
    • This will open the “Rewrite rule” window where we will make our modifications. In the “Type” dropdown menu, we can choose “Response Status” from the options displayed. Notice how only “Value” input fields are enabled in the Match and Replace window sections. In the Match section “Value” input field, we enter the actual response we get, which is 200 OK. In the Replace window section “Value” input field, we enter the desired response, in our case, 500 Internal Server Error. We save the changes by clicking on the “OK” button.
Populated “Rewrite Rule” window from the “Rewrite” option in Charles

With everything set, we just need to call the endpoint again in order to see the result of our modifications. Charles will respond with a 500 Internal Server Error status code, and this will be mirrored on the user interface of our sample application in the form of an error message.

Reflecting the 500 response status code in the Kliknijadi app and in Charles

Rewrite with Proxyman

In Proxyman, given that we don’t have the Rewrite option as such, we can use the Map local option to modify the status code of the request. Following the same approach for map local, this time, instead of changing the title in the body, we will change the status code of the request. 

Modifying the response status code to 500 via Proxyman UI

After saving the modifications and calling the endpoint again, we will get the 500 Internal server error code for the request. We can see in the application that the user is notified that there has been a problem, as it should happen in a real-life scenario. Additionally, the failure of the request will be reflected in Proxyman as well if you look at the response details.

Reflecting the 500 response status code in the Kliknijadi app and in Proxyman

Saving, sharing, and reading sessions

Charles and Proxyman offer the ability to share the traffic from your application with another person, so it is easier for them to pinpoint the exact problem you may have or to get more information on the behavior of the application. To developers and testers, reading what is behind the application behavior can give explanations and make life easier for this kind of audience.

In Charles, you can save a single endpoint and all of its information, or you can save your whole traffic or a fraction of it, based on your needs. Whichever option you choose, you need to highlight the desired endpoints, right-click, and choose the “Export Session” option. You can go ahead and save the traffic on your local machine. The extension Charles uses for its files is .chls. This type of file can be opened via Charles, but Proxyman can also open them. The only difference in Proxyman is that it will require for the .chls file to be converted to a .har file so Proxyman can read it. 

Proxyman also allows you to save your traffic. The default extension of the Proxyman file is .proxymanlogv2, but you can also save the traffic as .har, .csv, or even a Postman. This way, Proxyman gives greater freedom in using the files, given the range of the apps that can open them. This is, in a way, a limitation of Charles since Charles only saves .chls files. Another limitation is that Charles cannot open the .proxymanlogv2 files nor offer an option to convert them in order to be opened. 

In conclusion, both Charles and Proxyman are essential tools for efficiently managing and examining network traffic in mobile applications. They offer features for modifying data, setting breakpoints, testing network conditions, and simulating various scenarios. These tools are valuable for developers and testers aiming to enhance application performance and debug issues.

Setup is well-documented and user-friendly, and both tools provide a comprehensive view of network interactions for in-depth analysis. "Map Local" allows users to alter response data, while Charles' "Rewrite" and Proxyman's status code modifications help test the application's response to different codes.

Furthermore, these tools support session saving and sharing, streamlining collaboration and troubleshooting. 

Both are powerful aids for developers and testers, offering different strengths to improve mobile application performance and understanding of network behavior.

Subscribe to our newsletter

Sign up for our newsletter to get regular updates and insights into our solutions and technologies: