Connectivity Requirements

A Stairwell forwarder needs outbound HTTPS on port 443 to four hostname patterns, and it needs that traffic to reach Stairwell without a device in the middle terminating and re-signing the TLS session. Allowing the hostnames and forgetting the TLS inspection exemption is the most common cause of a deployment that installs cleanly and collects nothing.

What must the forwarder be able to reach?

All of these, outbound, TCP port 443.

Inside the first pattern, four endpoints matter enough to name individually, because a firewall can allow some and not others and the result looks healthy from a browser:

The two intake rows are the ones to check first when a rollout goes quiet. A fleet can register perfectly against an allowlist that permits the web app and not intake, which produces a console full of assets and an empty object store.

Why do I have to bypass TLS inspection?

Because the forwarder verifies that it is talking to Stairwell, and a TLS-inspecting proxy is, by design, not Stairwell.

Many enterprise networks route outbound HTTPS through a device that terminates the session, inspects the plaintext, and re-signs it with the organization's own certificate authority. Browsers on those machines accept the substitute certificate, because that internal authority is trusted locally. So the network looks correct to everybody who works on it. The forwarder does not accept it. The install succeeds, the service starts, nothing errors loudly, and no data arrives.

Add all four hostname patterns above to the decryption bypass list on whatever device performs the inspection. Do it at the same time as the firewall change, so you are not solving the same problem twice a week apart.

What about HTTP/2?

Two of the endpoints are gRPC, which rides on HTTP/2. A device that handles ordinary HTTPS correctly and mishandles or downgrades HTTP/2 will pass the web app and fail intake.

This is worth calling out separately because it produces a partial failure rather than a clean one, and because it is easy to conclude the network is fine after testing only the console in a browser. If your egress path includes a proxy that normalizes or downgrades protocols, confirm HTTP/2 survives it to grpc.intake.app.stairwell.com before a wide rollout.

Can the forwarder go through a proxy?

Yes, authenticated or unauthenticated, in this form:

http://[username:password@]<host_or_ip>:<port>

How you supply it depends on the platform.

• Windows, at install time. Pass HTTPSPROXY to the installer, along with the environment ID and token. See Install on Windows.
• Windows, after install. Set a HttpsProxy string value under the forwarder's key in the registry and restart the forwarder service. The key differs by forwarder version, so get the current path from Stairwell support rather than guessing.
• Linux. Set proxyURL in the forwarder's configuration file before the first service start. See Install on Linux.

Two things to confirm when a proxy is involved. Stairwell's hostnames have to be reachable through it, and they still need to be exempt from decryption on it. And if the machine also has HTTP_PROXY or HTTPS_PROXY set in the environment, check which configuration the forwarder is actually going to get: swell verify compatibility reports the proxy environment variables it finds, which is exactly what that part of the report is for.

How do I confirm connectivity before I deploy?

Run swell verify connectivity from one machine on the network you are about to deploy into. It probes every public Stairwell endpoint, confirms the certificate presented is the one Stairwell serves rather than one signed by something local, and prints a pass or fail row per endpoint. It exits non-zero when a required probe fails, so it works as a gate in whatever tooling pushes your installs.

Pre-Deployment Check walks through the output, what each failure detail means, and who fixes it. Two points from it are worth repeating here:

• Run it from each network path you are deploying into. A pass in the datacenter says nothing about a branch office behind a different proxy, or a cloud subnet with its own egress rules.
• Reachability and delivery are different claims. Adding --asset_id uploads a real generated file through intake to an asset that already exists, which proves data from this network lands in Stairwell rather than that the door was open. That is the check to run once a pilot host is up and before the fleet follows.

What breaks when only part of this is allowed?

Every row above is a change on your network, not a change in Stairwell. That is the reason this page comes before the install pages: the fix is cheap when it belongs to one host and expensive when it belongs to a fleet.