How do I use TestingBot Tunnel with manual (live) testing?

On the manual testing session configuration screen, pick the tunnel you want to use from the tunnel dropdown. The same tunnel works for desktop VMs, mobile simulators and emulators, and physical devices. Team members can also share tunnels so everyone on the account can use a single tunnel during manual testing.

How many TestingBot Tunnels can I run simultaneously?

The number of concurrent tunnels depends on your account plan. The default limit is 2 simultaneous tunnels per account. Higher limits are available on paid plans, contact support if you need a custom limit.

Can I use WebSockets or Server-Sent Events with the tunnel?

Yes. TestingBot Tunnel v4 and later supports ws://, wss:// and Server-Sent Events. WebSocket and SSE proxying requires that SSL bumping and the local caching proxy are disabled, so start the tunnel with both --nobump and --nocache. WebSocket connections cannot use the literal hostname localhost, so add a custom hostname like 127.0.0.1 testingbot.test to /etc/hosts and connect to ws://testingbot.test:3000.

How can I improve TestingBot Tunnel performance?

Use the --fast-fail-regexps (-F) flag to bypass the tunnel for domains that do not affect your tests, such as analytics, ad networks and third-party trackers. Fewer proxied requests means faster page loads. Example: java -jar testingbot-tunnel.jar -F '.*google-analytics\.com.*,.*facebook\.com.*'. You can also disable the caching proxy with --nocache if your test traffic is highly dynamic.

TestingBot Tunnel FAQ - Common Questions Answered

Q: How do I handle SSL certificate pinning in my mobile app?

TestingBot Tunnel performs SSL interception (SSL bumping) by default to transparently handle self-signed and expired certificates. All TestingBot VMs and devices already trust our CA. If your app uses certificate pinning, download the TestingBot CA certificate from https://testingbot.com/downloads/testingbot-ssl-bumping.crt and add it to your app's trust store, or disable SSL bumping by starting the tunnel with the --nobump flag.

Q: Can I use localhost with the tunnel?

Yes on desktop VMs. The ports 80, 443, 3000, 3001, 3030, 3400 and 8080 are proxied by default. For other ports, set the localHttpPorts or localHttpsPorts capability with an array of port numbers. Mobile simulators, emulators and physical devices cannot resolve the literal hostname localhost, so add a custom hostname like 127.0.0.1 mywebsite.local to your /etc/hosts file on the tunnel machine and reference http://mywebsite.local in your tests.

Q: Can I use the same tunnel for both virtual and real devices?

Yes. A single tunnel instance routes traffic for desktop VMs, simulators, emulators and physical devices. There is no need to start separate tunnels for different device types.

Q: Does TestingBot Tunnel work behind a corporate firewall or VPN?

Yes. The tunnel only requires outbound access on port 443 (HTTPS) and port 22 (SSH) to *.testingbot.com. It does not open any inbound ports on your network. If your firewall blocks outbound port 22, contact support for an HTTPS-only fallback. For corporate proxies, route tunnel traffic through your proxy with the --proxy and --proxy-userpwd flags.

Q: What ports does TestingBot Tunnel use?

Outbound from your machine, the tunnel opens port 443 (HTTPS) and port 22 (SSH) to *.testingbot.com. Locally, it binds to port 4445 by default for the Selenium hub (override with --se-port) and port 8087 for the local proxy (override with --localproxy). Metrics are exposed on port 8003 (override with --metrics-port). No inbound ports are needed.

How do I use the tunnel with manual (live) testing?

When starting a manual test session, select which tunnel to use from the session configuration screen. This works across all platforms: desktop VMs, simulators, emulators and physical devices.

Team members can start shared tunnels (with the --shared flag) that everyone on the team can use during manual testing.

How do I handle SSL certificate pinning in my mobile app?

By default, TestingBot Tunnel performs SSL interception (also called SSL bumping) to handle common certificate issues like self-signed or expired certificates. All TestingBot VMs and devices are configured to trust our CA certificate.

If your app uses certificate pinning, download the TestingBot CA certificate and add it to your app's trusted certificates. Alternatively, disable SSL interception by starting the tunnel with the --nobump flag.

How many tunnels can I run simultaneously?

The number of simultaneous tunnels depends on your account plan. The default limit is 2 concurrent tunnels. Upgrade your plan if you need more.

Can I use localhost with the tunnel?

Desktop VMs: Yes, localhost works on all desktop VMs. The following ports are proxied by default: 80, 443, 3000, 3001, 3030, 3400, 8080.

For additional ports, use the localHttpPorts or localHttpsPorts capabilities with an array of port numbers.

Mobile devices: Simulators, emulators and physical devices cannot resolve localhost. Create a custom hostname in your hosts file on the machine running the tunnel:

# Add to /etc/hosts on your tunnel machine
127.0.0.1 mywebsite.local

Then use http://mywebsite.local in your tests. The tunnel will route requests to your local server.

Can I use WebSockets or SSE with the tunnel?

Yes, TestingBot Tunnel v4 and later supports WebSockets (ws:// and wss://) and Server-Sent Events (SSE).

Prerequisite flags

WebSocket and SSE proxying requires the --nobump and --nocache flags. These are prerequisites, not optional fix-it switches: the local caching proxy and the SSL-bumping interceptor cannot forward streaming protocols.

java -jar testingbot-tunnel.jar --nocache --nobump

Hostname for WebSocket

WebSocket connections cannot use localhost directly. Create a custom hostname in your /etc/hosts file:

127.0.0.1  testingbot.test

Then connect using ws://testingbot.test:3000.

How can I improve tunnel performance?

Use the --fast-fail-regexps (or -F) option to bypass the tunnel for domains that do not affect your tests, such as analytics, ads or third-party trackers:

java -jar testingbot-tunnel.jar -F ".*google-analytics\.com.*,.*facebook\.com.*"

This reduces the number of requests proxied through the tunnel, improving overall test speed. For high-traffic test runs, consider running multiple tunnels in parallel.

Can I use the same tunnel for both virtual and real devices?

Yes, a single tunnel instance works with desktop VMs, simulators, emulators and physical devices. There is no need to start separate tunnels for different device types.

Does TestingBot Tunnel work behind a corporate firewall or VPN?

Yes. The tunnel only needs outbound access to *.testingbot.com on port 443 (HTTPS) and port 22 (SSH). It does not require any inbound ports.

For corporate networks that force all traffic through an HTTP proxy, route tunnel traffic through the proxy with --proxy and --proxy-userpwd:

java -jar testingbot-tunnel.jar --proxy corp-proxy.example.com:8080 --proxy-userpwd user:password

See the upstream proxy guide for PAC and SOCKS variations.

What ports does TestingBot Tunnel use?

Direction	Port	Purpose
Outbound	443	HTTPS to `*.testingbot.com`
Outbound	22	SSH tunnel
Local bind	4445	Selenium hub (override `--se-port`)
Local bind	8087	Local proxy (override `--localproxy`)
Local bind	8003	Metrics endpoint (override `--metrics-port`)

No inbound ports are required.

Is TestingBot Tunnel free?

Yes. TestingBot Tunnel is free for all TestingBot accounts including the free trial. It is open source under an MIT license, source on GitHub.

How do I update TestingBot Tunnel to the latest version?

Download the latest JAR from the tunnel home page, unzip and replace your existing testingbot-tunnel.jar. If you use Docker, run docker pull testingbot/tunnel. If you use Maven, bump the com.testingbot:TestingBotTunnel version in your pom.xml. See the changelog for the current release notes.

Why does my tunnel disconnect or time out?

The most common causes are: an idle network connection being killed by a corporate firewall or NAT timeout, JVM out of memory on the tunnel host, or a transient outbound connectivity issue.

Run the tunnel with --doctor to validate ports and credentials, watch the metrics endpoint on port 8003 for connection counters, and check the log file specified by --logfile for stack traces. The troubleshooting guide walks through the most frequent root causes.