How web proxies work

A web proxy puts one hostname, such as www.example.com, behind Coritan's edge. The edge answers HTTP and HTTPS for the name with a certificate issued for it, checks requests with the web application firewall (WAF), applies your redirects and forwards each remaining request to your origin: the server that runs the site. The origin can be one of your servers hosted here or any public address. The public Edge Proxy page describes the product. The dashboard shows a web proxy as a hostname of a website, and gives each one a number such as #31. A web proxy needs a full hostname: a wildcard name such as *.example.com cannot have one, and the API answers 422 with A wildcard name cannot have a web proxy. Add a route for each hostname instead. Create a web proxy for each hostname you serve.

Visitors reach the edge over HTTPS on port 443, or over plain HTTP on port 80.

• HTTP/3 runs over QUIC on UDP port 443. The edge offers it in an Alt-Svc header on its HTTP/2 and HTTP/1.1 answers, so a browser that supports it switches on a later request. The edge does not accept early data (0-RTT) on HTTP/3.
• Over TCP, the edge and the browser agree on HTTP/2 or HTTP/1.1 during the TLS handshake.
• The edge accepts TLS 1.3 and TLS 1.2, and refuses SSL 3.0, TLS 1.0 and TLS 1.1.
• On TLS 1.2, the edge offers only ECDHE key exchange with AES-GCM or ChaCha20-Poly1305. Every connection has forward secrecy: a key stolen later cannot decrypt it.

How visitors connect does not depend on the origin protocol (Origin protocols).

The edge handles each request for the name in this order. The first step that answers ends the request.

1. On plain HTTP, the edge answers certificate validation requests under /.well-known/acme-challenge/ for certificates it is issuing itself.
2. When the name has no web proxy, the edge answers 404 with a page that reads This domain is not assigned to any active service on our network.
3. A whole-domain redirect, when set, answers every request. The origin is never contacted.
4. With Force HTTPS on, a plain HTTP request gets a 301 redirect to the same address over HTTPS.
5. Redirect rules answer requests whose path matches one, highest priority first.
6. A client that sends too many requests gets 429 with {"error":"Too many requests"}.
7. With the Web application firewall on, your own WAF rules block, challenge or limit the requests they match (Rules of your own).
8. With WebSockets on, a request that opens a WebSocket connection goes straight to the origin.
9. The edge answers from its cache when it holds a copy of a static file (Caching).
10. With the Web application firewall on, the WAF's managed rules check the request (The web application firewall).
11. A request body larger than the web proxy's limit gets 413 with {"error":"Request body too large"}.
12. The edge forwards the request to an origin and passes the origin's answer back to the visitor.

The origin is an IP address or a hostname, with a port. It must be reachable from the internet: the API refuses an origin on a private or reserved network, such as 10.0.0.10 or localhost, and a hostname that does not resolve in public DNS.

Connect to the origin over TLS makes the edge use HTTPS on the way to the origin. The origin must then present a valid certificate for the origin host from a public certificate authority. A self-signed certificate, an expired one or one for another name fails, and visitors get an error page that names Origin TLS failed. When the origin host is an IP address, the certificate must list that address.

A web proxy can also have additional origins. The edge spreads requests across the origin host and every additional origin, and favours the one with the fewest requests in progress. It does not check the origins' health in advance, so every origin must be able to answer every request.

• When the edge cannot connect to an origin, it tries the next one. It tries a GET, HEAD or OPTIONS request twice on each origin.
• An origin that keeps failing is skipped for a short time, then tried again. When every origin is skipped, visitors get an error page that names All origins marked down.

The Origin protocol sets how the edge talks to the origin. It depends on Connect to the origin over TLS as this table shows.

The origin protocol does not change how visitors connect to the edge.

• The visitor's method, path and headers, including Host, so the origin sees the web proxy's name.
• X-Forwarded-For and X-Real-IP with the visitor's IP address, and X-Forwarded-Proto with https or http. The edge removes any X-Forwarded-For, X-Real-IP, X-Forwarded-Proto or Forwarded header the visitor sent.
• Your custom request headers, on every request.
• With PROXY protocol to origin on, a PROXY protocol version 2 header at the start of each connection, carrying the visitor's address. The origin must expect it, or every request fails. The edge sends a connection only the requests of the visitor its header names.

The path changes when you set a prefix. The edge removes Strip path prefix from the start of the path, then adds Prepend origin path in front of what is left. With /api stripped and /v2 prepended, a request for /api/users?page=2 reaches the origin as /v2/users?page=2, and a request for /about as /v2/about. When the origin answers with a Location or Content-Location header, the edge maps its path back, so visitors get a path they can request.

The edge serves HTTPS for the name with a certificate issued for it (How SSL/TLS certificates work). A new web proxy requests one while Request a certificate automatically is on. Until the certificate is active, the edge answers HTTPS for the name with a certificate for another name, and browsers warn visitors.

The certificate can only be issued once the name reaches the edge, or when Coritan hosts its DNS zone (Web proxies and DNS records). Request or renew the certificate covers the web proxy's Certificate card.

The WAF checks each request against a managed rule set before the request reaches your origin. The rules look for SQL injection, cross-site scripting, command injection, path traversal, server-side request forgery, XML external entities, header injection and vulnerability scanners. They read the path, the query string, the method, the headers and the first 64 KB of the request body. From the body they read form fields, JSON, XML and text, and leave out uploaded files: the file parts of a form and a body that is a file, such as a zip, an image or a video.

Each rule that matches adds to the request's score.

• A request with a high score gets a 403 page that reads The web application firewall blocked your request to protect this website from traffic that looks malicious.
• A request with a lower score that still looks suspicious gets a page titled Just a moment, which asks the visitor a simple math question, such as What is 4 + 7?. A browser that answers it is not asked again on that web proxy for 20 minutes, as long as its IP address stays the same. Scripts that do not read the page cannot pass it.

The edge never asks the question for a file a page loads (a picture, a stylesheet, a script, a font, a sound or a video) or for a request a browser makes from inside a page. Those are served unless their score reaches the block threshold, so a page that opens always loads in full.

You cannot see or change the managed rules, and you cannot exempt a path from them. The Web application firewall switch turns the WAF on or off for the whole web proxy (Change a web proxy's settings). The managed rules do not check a request that opens a WebSocket connection while WebSockets is on, or a file the edge answers from its cache.

You can add WAF rules of your own to a web proxy. A rule blocks or challenges the requests that match a condition, such as a path or a country, or limits how many requests one visitor sends in a time window. Your rules check every request while the Web application firewall is on, before the cache and the managed rules, and they cannot let through a request that the managed rules refuse.

Add them on the Custom rules card of the Security tab of the website that holds the name, or with the API (Protect a website). Once account plans open on your account, your plan sets how many rules you can have and which kinds.

A web proxy can redirect in two ways (Redirect requests with rules):

• Redirect rules send matching paths elsewhere, and the other requests still reach the origin.
• A whole-domain redirect sends every request for the name to another address, and the origin is never contacted.

The edge keeps copies of static files and answers later requests for them without asking the origin. It caches an answer only when all of these hold:

• The request is a GET or HEAD with no Authorization header, and the origin answered 200.
• The answer is an image, a font, an audio file or a video, going by its Content-Type. An answer with no type, or with application/octet-stream, counts when its path ends in a media extension such as .png, .woff2 or .mp4.
• The answer has no Set-Cookie header, and its Cache-Control has neither no-store nor private, nor a max-age of 0.
• The answer states a Content-Length of 10 MB or less.
• The path does not start with /api/, /ws/, /admin, /docs, /openapi or /health.

The edge never caches HTML pages. It caches scripts, styles and JSON only under a path that starts with /assets/v/ and a version, such as /assets/v/3f9a1c/app.js, and only when the origin marks them immutable.

A cached copy stays for as long as the origin's s-maxage or max-age says, or for an hour when it says neither. The edge can drop a copy sooner to make room for others. Answers carry X-Cache: HIT when they come from the cache and X-Cache: MISS when they come from the origin.

Two settings change this for a web proxy: caching on or off, and a time that replaces the origin's. You can also clear the cache, so every file comes from the origin again on its next request. For any hostname of a website, the website's Caching tab has all three, and lets signed-in visitors skip the cache (Speed up a website with the cache). For any web proxy, the API has them. Once account plans open on your account, they come with the Pro, Business and Enterprise plans.

When the edge cannot reach the origin, it answers with its own error page: 502 when the connection fails and 504 when the origin does not answer within the origin timeout. The page carries a reference called the ray ID, which also travels in the Coritan-Ray response header, and the Coritan-Error header names the failure.

• Customise the error page changes the page's words, links and look.
• Development mode adds the origin's address and the exact failure while you debug (Use development mode while you debug).
• Troubleshoot proxies and join addresses explains each failure.

A web proxy only receives traffic once its name resolves to Coritan's edge.

• When Coritan hosts the zone, turn Proxied on for the name's A or AAAA record, and Coritan's nameservers answer with the edge's addresses instead of the record's own (Proxied records). When you create a web proxy for a name that has no A, AAAA or CNAME record yet, Coritan adds a proxied A or AAAA record for it, with the origin's address and the comment Created for the proxy route.
• When another provider hosts the zone, set the name's A record at that provider to the edge address. The SSL/TLS tab shows the address when you choose HTTP validation (Issue a certificate with HTTP validation). Delete any AAAA record for the name there too: visitors on IPv6 networks would reach the address in it instead of the edge, and the certificate check fails while it exists.

A proxied record works without a web proxy of your own. When you turn Proxied on for a name that has no web proxy, Coritan creates one with the WAF on and requests a certificate for it. Its origins are the addresses of every proxied A and AAAA record at the name. It starts on HTTP to port 80 and moves to HTTPS on port 443, without checking the origin's certificate, once every origin answers HTTPS there (Proxied records). That web proxy is yours, as the zone is: it is on the tabs of the zone's website and in the Web proxies tab of Game Shield, and you can change every setting but its origin's address, which follows the records. Its port and its connection to the origin stay yours to set. A request that changes its origin's address, or deletes it, answers 409 with origin_follows_dns: change the records on the DNS tab instead, or turn Proxied off to stop Coritan's network serving the name. In a zone that belongs to an organization, the web proxy belongs to no account, as before.

A proxied record also acts on a web proxy you created for its name:

• Changing the record's Content changes the web proxy's origin host to the new value. A second proxied record at the name does not add an origin to it: give it more origins on its Origin tab (Change a web proxy's origin).
• Turning Proxied off for the name's last proxied A or AAAA record, deleting that record or deleting the zone deletes the web proxy, with its settings, redirect rules and error page. While another proxied record is left at the name, the web proxy stays.

Deleting a web proxy leaves its DNS records as they are. A proxied record for the name then sends visitors to the edge, which answers 404 until the name has a web proxy again.

A web proxy is a hostname of a website: its name is, or sits under, a domain that you registered here or host the DNS zone of. Its settings are the website's tabs, one hostname at a time with ?host= in the address (Manage a website's origin, Redirect visitors and set headers, Choose an encryption mode, Speed up a website with the cache).

In Game Shield, the Web proxies tab lists the web proxies on the account, up to 200, with their own tiles (Web proxies). A card opens the website's tab for that hostname. Opening a web proxy by its old address, /dashboard/proxies/web/ and its number, does the same, and replaces the history entry so that Back does not return to the forwarding address.

A web proxy whose domain no website holds, for example after you deleted the zone, keeps a page of its own, opened from the same list. All web proxies at the top of it comes back to the list. The header shows the name, its status, its certificate state, such as Certificate active or No certificate, and where it forwards to. The Overview tab has three cards.

Web proxy

The Domain, the Origins with their ports and whether each uses TLS, the Origin protocol, how the Path changes, the names of any Custom headers, whether PROXY protocol is sent, the Limits and when the web proxy was Created. Edit origin opens the Origin tab (Change a web proxy's origin).

Certificate

The certificate Coritan's network serves for the name: Issued by, Expires, Covers and Renewed. It also shows how many certificates the registered domain can still get this week (Request or renew the certificate).

Switches

Web application firewall, Force HTTPS, WebSockets and Development mode. Each switch saves as soon as you change it (Change a web proxy's settings).

List your web proxies, newest first, with GET /api/v1/proxy/routes. It takes page, from 1, and per_page, from 1 to 200 with 50 by default:

curl "https://api.coritan.com/api/v1/proxy/routes?page=1&per_page=50" \
  -H "Authorization: Bearer $CORITAN_TOKEN"

{
  "routes": [
    {
      "id": 31,
      "domain": "www.example.com",
      "upstream_host": "203.0.113.10",
      "upstream_port": 8080,
      "upstream_ssl": false,
      "status": "active",
      "force_https": true,
      "websocket_enabled": true,
      "waf_enabled": true,
      "ssl_mode": "full",
      "redirect_to": null,
      "strip_path_prefix": null,
      "upstream_path_prefix": null,
      "upstream_backends": null,
      "development_mode": false,
      "development_mode_expires_at": null,
      "development_mode_active": false,
      "development_mode_seconds_left": null,
      "certificate": {
        "id": 12,
        "domain": "www.example.com",
        "status": "active",
        "issuer": "letsencrypt",
        "issued_at": "2026-09-01T10:02:11",
        "expires_at": "2026-11-30T10:02:10",
        "wildcard": false
      },
      "created_at": "2026-09-01 10:00:04"
    }
  ],
  "total": 1,
  "page": 1,
  "per_page": 50
}

certificate is the certificate the edge serves for the name, or null, and its status is the certificate's state (Certificate statuses). Read it rather than ssl_mode, which records the last request: off when none was made or the certificate was revoked, pending after a request, and full when the web proxy took over a certificate that already covered the name. wildcard is true when a wildcard certificate for the parent name covers it. development_mode_active says whether the edge still shows diagnostics, because development mode can have expired while development_mode is still true.

Read one web proxy with GET /api/v1/proxy/routes/{route_id}:

curl https://api.coritan.com/api/v1/proxy/routes/31 \
  -H "Authorization: Bearer $CORITAN_TOKEN"

The answer holds every stored setting, including upstream_protocol, send_proxy_protocol, grpc_enabled, max_body_size_mb, timeout_seconds, custom_headers, the redirect_* fields and error_page. Booleans other than the development_mode* fields come back as 0 or 1, and custom_headers and upstream_backends come back as JSON text. A web proxy that is not on your account answers 404 with Route not found. Change a web proxy's origin describes each field.