> ## Documentation Index > Fetch the complete documentation index at: https://docs.serval.com/llms.txt > Use this file to discover all available pages before exploring further. # Network Security and Firewalls > Network configuration for running Serval on enterprise networks, including exempting Serval's streaming pages from proxy SSL/TLS inspection. # 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. | Domain | Protocol | Port | Purpose | | -------------------------- | -------- | ---- | ------------------------------------------------ | | `app.serval.com` | HTTPS | 443 | Sign-in and landing page | | `.serval.com` | HTTPS | 443 | Your organization's web app, API, and streaming | | `api.us1.serval.com` | HTTPS | 443 | Shared API used during sign-in and org selection | | `svwebhook.us1.serval.com` | HTTPS | 443 | Inbound webhooks from connected apps | | `public.api.serval.com` | HTTPS | 443 | Public 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](/sections/self-hosting/private-network-access). ### Fixing it: exempt the Serval API from inspection **Serval Cloud** — your API host is region-specific, in the form `api..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](#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.` or your unified API host `api.`, as configured during deployment. 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. 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](https://help.zscaler.com/zia/skipping-inspection-traffic-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](https://developers.cloudflare.com/cloudflare-one/traffic-policies/http-policies/tls-decryption/) (Cloudflare docs). Add an **SSL Decryption** policy with the **Do Not Decrypt** action for the hostnames. See [SSL decryption](https://docs.netskope.com/en/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](https://docs.paloaltonetworks.com/network-security/decryption/administration/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](https://securitydocs.cisco.com/docs/umbrella-sig/olh/151445.dita) (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. 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](/sections/self-hosting/index) for delivery-model details. ## See also * [Private Network Access](/sections/self-hosting/private-network-access) — how Serval reaches systems on your internal network under each delivery model. * [Product security](/sections/documentation/platform/product-security) — Serval's security posture, data handling, and platform controls.