Skip to main content

​
Network Security and Firewalls

This page covers the network configuration for reaching Serval on enterprise networks: the Serval Cloud domains to allow through your firewall, and how to keep security proxies from breaking Serval’s streaming pages.

​
Serval Cloud domains

Allow the following Serval Cloud (US) hosts so the web app and API work from your network. All Serval traffic is HTTPS on port 443; self-hosted deployments use your own domains instead.
DomainProtocolPortPurpose
app.serval.comHTTPS443Sign-in and landing page
<your-org>.serval.comHTTPS443Your organization’s web app, API, and streaming
api.us1.serval.comHTTPS443Shared API used during sign-in and org selection
svwebhook.us1.serval.comHTTPS443Inbound webhooks from connected apps
public.api.serval.comHTTPS443Public REST API (only if you use it)
Wildcard alternative. If your firewall accepts wildcards, allow *.serval.com and *.us1.serval.com (HTTPS, port 443). Note that *.serval.com does not match the two-label host public.api.serval.com, so allow that one explicitly if you use the public REST API.

​
Streaming pages behind a WAF or proxy

​
How Serval uses streaming

Most web requests are simple round trips: the browser sends a request, the server returns one complete response, and the connection closes. Several Serval pages work differently. To show content that updates live — an AI reply forming as it is generated, a workflow run reporting progress, a ticket conversation updating in real time — they use a streaming response: a single HTTPS connection that stays open and delivers data progressively as it becomes available, rather than all at once at the end. This is the same idea behind live AI chat experiences across the web. It is normal, secure HTTPS traffic on port 443; the only thing unusual about it is that the response is long-lived rather than instantaneous. Pages that rely on streaming include the workflow builder and workflow run views and the help desk ticket view, along with other parts of the app that update live. Most other pages use ordinary requests and are unaffected.

​
Why inspecting proxies break it

Many enterprise networks route outbound traffic through a forward proxy, secure web gateway, or WAF — for example Zscaler or Cloudflare. To examine encrypted traffic, these devices typically perform SSL/TLS inspection: they decrypt the response, scan it (deep packet inspection), and re-encrypt it before passing it to the browser. Scanning generally requires the proxy to buffer the response until it is complete. A streaming response has no completion to wait for — it deliberately stays open. The proxy keeps buffering, waiting for an end that never comes, and nothing reaches the browser until the proxy’s own timeout fires. The affected page appears to hang: the app loads, but the page never shows its live content and may eventually time out or error.

​
Recognizing the problem

An inspecting proxy is the likely cause when:
  • only specific pages are affected (workflow builder and runs, help desk tickets) while the rest of Serval works normally;
  • those pages sit on a loading state and never show live or AI-generated content;
  • the problem appears only on the corporate network or VPN, not when the same user is off-network; and
  • the behavior is consistent across users and browsers on that network.
If pages fail everywhere — including off-network — the cause is more likely DNS, certificate trust, or general connectivity than a proxy. See Private Network Access.

​
Fixing it: exempt the Serval API from inspection

1

Identify your Serval API hostnames

Serval Cloud — your API host is region-specific, in the form api.<region>.serval.com (for example, api.us1.serval.com). You can confirm the exact host in your browser’s developer tools, on the Network tab, while loading an affected page. See Serval Cloud domains above for the full host list and wildcard options.Self-hosted — use the API hostname(s) for your deployment: either the per-service pattern *.api.<your-domain> or your unified API host api.<your-domain>, as configured during deployment.
2

Exempt those hostnames from SSL/TLS inspection

On your proxy or WAF, add a rule that exempts the Serval API hostnames from SSL/TLS inspection (also called HTTPS inspection or decryption). Match the exemption by hostname, not by URL path.Proxies evaluate this exemption against the hostname in the TLS handshake (the SNI) before they decrypt anything, so a hostname-scoped exemption leaves the streaming connection untouched end to end. Exempting from inspection also removes the response buffering and deep packet inspection that inspection performs — the behaviors that hold a streaming response open until it times out.
3

Apply the setting for your proxy

The control is named differently by each vendor. Consult your vendor’s documentation for the exact steps:
Set the Do Not Inspect action on an SSL/TLS Inspection rule scoped to the Serval API hostnames. See Skipping inspection of traffic to specific URLs or cloud apps (Zscaler docs).
Create a Do Not Inspect HTTP policy for the hostnames. The HTTPS bypass matches on the TLS SNI and is evaluated before Allow/Block policies. See TLS decryption (Cloudflare docs).
Add an SSL Decryption policy with the Do Not Decrypt action for the hostnames. See SSL decryption (Netskope docs).
Add the hostnames to Decryption Exclusions (wildcards allowed); the firewall matches on the TLS SNI and the server certificate common name. See Decryption exclusions (Palo Alto Networks docs).
Add the hostnames to the Web Selective Decryption List so they pass through without decryption. See Manage selective decryption (Cisco docs).
Other proxies (Fortinet, Forcepoint, Broadcom/Symantec, and similar) offer the same capability under names such as “SSL/TLS inspection exemption,” “decryption exclusion,” or “do not decrypt” — scope it to the Serval API hostnames.
4

Verify

Reload an affected page — for example, open a help desk ticket or a workflow run.
The live content appears and updates within a few seconds, on the corporate network, for all users.

​
Self-hosted deployments

If you run Serval yourself, the same constraint applies to any reverse proxy or load balancer you place in front of it: it must not buffer streaming responses (for nginx, set proxy_buffering off on the API routes). See Self-Hosting Options for delivery-model details.

​
See also

  • Private Network Access — how Serval reaches systems on your internal network under each delivery model.
  • Product security — Serval’s security posture, data handling, and platform controls.