If mabl can't connect to your application during a cloud run, it could be due to one of the following causes: your firewall is blocking traffic from the internet, a Link Agent isn't routing the run, or a service in front of your app is challenging mabl's traffic as a bot. This article walks through each issue and explains how to troubleshoot.
If the same test passes in the Trainer or locally, read Why tests pass locally but fail in the cloud first. It explains what differs between the two and narrows down where to look.
Confirm network settings
Many connectivity issues come from a test environment behind a firewall that blocks inbound traffic from the internet. mabl test traffic originates from machines in the cloud, so a firewall that only allows traffic from your office or VPN also blocks every cloud run.
To test an application behind a firewall, either add mabl's static IP addresses to an allowlist for inbound connections or run tests over mabl Link. Setting up your network for mabl lists everything your network needs to allow.
Check Link Agent connectivity
If the environment is supposed to use mabl Link, start with the Link Agent before involving your network team. On Settings > Networking, confirm that an agent is connected to the tunnel and that the environment you're running tests in routes through that tunnel.
A connected agent can reach mabl, but that alone doesn't prove it can reach your application. To test the tunnel directly, see Testing and diagnosing Link connections. For symptoms and fixes, see Troubleshooting issues with mabl Link.
Tests fail even though mabl's IP addresses are allowlisted
A correct allowlist can pass every request from mabl and the test can still fail partway through. Services that sit between mabl and your app, such as a content delivery network, a web application firewall, an identity provider, or a payment provider, run their own bot protection. mabl's cloud browsers come from datacenter IP addresses and identify themselves as automated, so those services may challenge them regardless of what your firewall allows.
A challenge doesn't always look like a block. It typically returns a verification page where the test expected your app, and the step times out waiting for an element that never appears. Check the screenshot and DOM snapshot on the failed step.
Confirm that bot protection is the cause
Run the same test in a few different ways and compare the results:
- Over mabl Link. When tests run over mabl Link, traffic originates inside your network rather than from mabl's IP addresses. If the test passes over Link and fails without it, a service in front of your app is challenging traffic from datacenter IP addresses.
- Locally, in headless mode. Run the test on your own machine in headless mode, where the browser runs without a visible window, for example with the mabl CLI. If the test fails there too, the protection is detecting the automated browser itself rather than where the traffic comes from.
Find mabl's traffic in your CDN or WAF logs
By default, browser test requests include the X-Mabl-Agent header, and their user agent string contains mabl. Your network team can use these markers to find mabl's traffic in their logs and write rules for it.
API tests and mobile tests don't include these markers. Setting up your network for mabl has the details.
When a service challenges a request, the reason is recorded in that service's logs, not in mabl's test output. The verification page usually shows a request ID. Ask the team or vendor that runs the service to look it up and tell you which rule the request triggered. Once you know the rule, Custom HTTP headers explains how to have your test environment accept a header that lets mabl through.
Reach out to the mabl team
If you've worked through the steps above and still can't find the cause, reach out in-app or by email. Include the test run link and, for Link-enabled environments, the tunnel name and the Link Agent ID from Settings > Networking.