Origin Proxy

Overview

When RndrKit identifies a request as coming from a human visitor (not a bot), it proxies the request directly to your origin server. The visitor experiences your website exactly as if they were accessing the origin directly -- same content, same performance, same interactivity.

How the Proxy Works

The proxy flow is straightforward:

Human visitor requests www.example.com/about
    |
    v
DNS resolves to RndrKit (via CNAME)
    |
    v
Nginx: User-Agent is not a bot (is_bot = 0)
    |
    v
Express API: Proxy request to origin (example.lovable.app/about)
    |
    v
Origin responds with SPA HTML + assets
    |
    v
Response forwarded to visitor

The visitor's browser receives the response from the origin server and renders the SPA normally, including JavaScript execution and client-side routing.

What Gets Proxied

Request Headers

The proxy forwards all relevant request headers to the origin:

  • Host -- Set to the origin domain
  • X-Real-IP -- The visitor's actual IP address
  • X-Forwarded-For -- The IP chain including the visitor's IP
  • X-Forwarded-Proto -- The protocol (HTTPS)
  • X-Forwarded-Host -- The original requested host
  • Cookies, authorization headers, and other standard headers

Response Headers

The origin's response headers are passed through to the visitor, including:

  • Content-Type -- The MIME type of the response
  • Cache-Control -- The origin's caching directives
  • Set-Cookie -- Session and authentication cookies
  • Custom headers set by the origin application

Response Body

The full response body is forwarded without modification. For SPAs, this is typically:

  • The HTML shell with a root <div> and script tags
  • JavaScript bundles (loaded by the browser separately)
  • CSS stylesheets
  • Images, fonts, and other assets

Origin URL Configuration

When you add a domain to RndrKit, you specify the origin URL. This is the address of your actual hosted application:

Custom DomainOrigin URL
www.example.comexample.lovable.app
www.mysite.iomysite.vercel.app
www.clientsite.comclient-app.netlify.app

The origin URL must be accessible over HTTPS. RndrKit makes the proxy request to https://{origin_url}{path}.

Performance Impact

The proxy adds minimal overhead to human requests:

  • Latency overhead: Typically 5-20ms added to the total response time.
  • No content modification: The response is passed through as-is, with no processing or transformation.
  • Connection pooling: RndrKit uses HTTP/1.1 keepalive connections to the origin, reducing connection setup overhead for repeated requests.

For most sites, the proxy overhead is imperceptible to visitors.

Transparency

Human visitors have no way to tell that their request is being proxied through RndrKit:

  • The browser address bar shows your custom domain (not the origin URL).
  • SSL is terminated at RndrKit, and a separate SSL connection is made to the origin.
  • JavaScript, client-side routing, and interactive features work normally.
  • Form submissions, API calls, and authentication flows function as expected.

Static Assets

When your SPA loads, the browser makes additional requests for JavaScript bundles, CSS files, images, and other assets. These requests also flow through RndrKit's proxy:

Browser loads www.example.com/about
    |
    v
HTML shell is returned (via proxy)
    |
    v
Browser requests:
  - /_next/static/chunks/main.js  (proxied to origin)
  - /styles/global.css             (proxied to origin)
  - /images/hero.jpg               (proxied to origin)

All static asset requests from human visitors are proxied to the origin. They are not pre-rendered or cached by RndrKit's rendering engine (that is only for bot requests).

Error Handling

If the origin server is unreachable or returns an error:

  • Origin down: RndrKit returns a 502 Bad Gateway error to the visitor.
  • Origin timeout: If the origin does not respond within the timeout period (60 seconds), RndrKit returns a 504 Gateway Timeout.
  • Origin 4xx/5xx: Error responses from the origin are passed through to the visitor as-is.

RndrKit does not cache error responses. If the origin returns a 500 error, the next request will attempt to reach the origin again.

Difference from Bot Path

It is worth understanding the distinction between the bot and human paths:

AspectBot PathHuman Path
DetectionUser-Agent matches bot patternUser-Agent does not match
Response sourceRedis cache or Puppeteer renderOrigin server (proxied)
ContentStatic HTML snapshotLive SPA with JavaScript
InteractivityNone (static HTML)Full client-side interactivity
Response time< 50ms (cache hit)Depends on origin performance

Next Steps