Skip to main content
Cisco Meraki Documentation

Using HAR Files to Troubleshoot Web Pages that are Failing to Fully Load

This page explains how to use the HAR capture functionality in web browsers to troubleshoot why web pages aren't loading properly in certain circumstances

What is a HAR file, and how can it help diagnose a problem?

A HAR (HTTP ARchive) file is a way to preserve and archive the interactions and exchanges between a web browser and a site. Among a lot of performance data and other factors that are generally only of interest to web developers, they also contain things like HTTP status codes for all of the transactions that go on behind the scenes whenever a given web page is loaded.

One major shortcoming of packet captures in this day and age, when nearly all communications are sent over TLS, and thus encrypted on the wire, is that they cannot provide visibility into application-layer payloads, and thus don't provide visibility into any HTTP-related issues that might be occurring when a given website is not loading as expected.

When should I consider taking a HAR capture?

Whenever you see websites starting to load, but fail or stop partway through, a HAR file might prove more useful than a pcap, since it's likely an error in the actual HTTP transaction(s) that is/are taking place.

When should I not consider taking a HAR capture?

If you are seeing something like ERR_CONNECTION_REFUSED or ERR_CONNECTION_RESET, or anything mentioning DNS, this typically means the connection to the website failed before a TLS session ever fully established.

In such situations, a packet capture is the preferred troubleshooting method, since the relevant points of failure will be visible on the wire.

How do I take a HAR capture?

The following explains how to take a HAR capture in Google Chrome - if you would prefer to use another browser, please consult their respective documentation:

  1. Open a new tab, and open the Developer Console using either the appropriate keyboard shortcut (F12), or by opening the menu in the top right, and navigating to More Tools -> Developer Tools
  2. Select the "Network" tab on the pane that opens, and ensure that both the recording button is lit up in red, and the check box marked "Preserve log" is selected
  3. Navigate to the website you're trying to troubleshoot, and verify that you see network activity logged in the pane to the right, as the following example shows:

har step one.jpg

  1. Right click in that pane, and select "Save all as HAR with content," as noted in the screenshot below:

Screen Shot 2022-08-02 at 3.38.49 PM.png

How do I read and analyze a HAR capture?

We recommend using Google's HAR Analyzer to view the contents of what you have captured. In general, the easiest way to start determining what's failing is to take a working, and a non-working capture, and compare the two to see what's failing to load properly, as seen in the example below.

An example case study

A user calls in to complain that your company's website cannot be loaded from the office, but they're able to reach it if they disconnect their cell phone from the office WiFi and use their carrier network instead. After a confirming the issue yourself by testing the site from home, and then connecting into the office VPN, you also verify that you're both seeing the same thing: an entirely blank page. Nothing in your configuration that would firmly suggest a problem there, so you decide to take a HAR capture in the non-working (top) and working (bottom) scenarios* to compare what might be going on:

*Note: The captures from this case study were taken as part of the troubleshooting process on a Meraki Support case. Some information has been redacted from them to avoid inadvertently disclosing any information about the customer on the case in question.

HAR Non-working.jpg

HAR working.jpg

From these two comparisons, you can see that the website in question is sending your users a 200 OK with no data when it's failing, and properly loading from outside of your office network. Given that this is TLS traffic, and that MXs cannot see nor modify TLS payloads, you conclude this is a problem with the web server, and reach out to the provider for further troubleshooting.