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 domainX-Real-IP-- The visitor's actual IP addressX-Forwarded-For-- The IP chain including the visitor's IPX-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 responseCache-Control-- The origin's caching directivesSet-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 Domain | Origin URL |
|---|---|
| www.example.com | example.lovable.app |
| www.mysite.io | mysite.vercel.app |
| www.clientsite.com | client-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:
| Aspect | Bot Path | Human Path |
|---|---|---|
| Detection | User-Agent matches bot pattern | User-Agent does not match |
| Response source | Redis cache or Puppeteer render | Origin server (proxied) |
| Content | Static HTML snapshot | Live SPA with JavaScript |
| Interactivity | None (static HTML) | Full client-side interactivity |
| Response time | < 50ms (cache hit) | Depends on origin performance |
Next Steps
- Bot Detection -- How bots and humans are distinguished
- Rendering Pipeline -- What happens on the bot path
- DNS Configuration -- How DNS routing enables the proxy