@cloudflare/vite-plugin: HTTPS/HTTP2 Host/:authority handling drops non-default port from request.url (breaks Clerk handshake redirects)

[intrdx]

What versions & operating system are you using?

• OS: Windows 11
• Node: v24.18.1
• Package manager: pnpm 11.17.0
• @cloudflare/vite-plugin: 1.45.1
• wrangler: 4.112.0
• vite / Vite+: 8.1.5 / vite-plus 0.2.6
• Framework: TanStack Start + @clerk/tanstack-react-start 1.4.20

Please provide a link to a minimal reproduction

• Vite HTTPS + @cloudflare/vite-plugin + Clerk middleware below reproduces

Describe the Bug

When the Vite + @cloudflare/vite-plugin dev server is served over HTTPS, Clerk handshake redirects lose the non-default port (:5173) and can loop, e.g.:

• Expected: https://localhost:5173/...
• Actual: https://localhost/... (port dropped)
  This only shows up under HTTPS. Plain HTTP on localhost:5173 works.

Why this is plugin-side

Clerk builds handshake redirect_url from clerkUrl, which comes from @clerk/backend's deriveUrlFromHeaders() using:

1. x-forwarded-host / x-forwarded-proto when present
2. otherwise request.url / Host
   In @cloudflare/vite-plugin, request adaptation currently:
3. Builds the Fetch Request in createRequest from Node req headers
4. Skips HTTP/2 pseudo-headers starting with : (including :authority)
5. Falls back host to "localhost" when Host is missing
6. Sets X-Forwarded-Host from that host in toMiniflareRequest
   On HTTPS, browsers often use HTTP/2, where authority is in :authority rather than a classic Host header. If Host is absent/incomplete and :authority is ignored, the reconstructed origin can become https://localhost without :5173. Clerk then redirects using that broken origin.
   This looks like a remaining gap after prior host/protocol fixes:

• 🐛 BUG: @cloudflare/vite-plugin redirects to wrangler port in dev server #8684 / Add X-Forwarded-Host header to requests #8706 (X-Forwarded-Host for Clerk wrong-host redirects)
• Vite plugin breaks host headers #10884 / related host header preservation work
• @cloudflare/vite-plugin: Worker request.url is always http://… behind a TLS-terminating proxy — dev.upstream_protocol and X-Forwarded-Proto both ignored #13801 / [vite-plugin-cloudflare] Honor X-Forwarded-Proto when constructing request.url #13920 (X-Forwarded-Proto for request.url)
  Those address host/protocol forwarding, but not this HTTPS/HTTP2 port/authority reconstruction case.

Expected behavior

With Vite listening on https://localhost:5173 (and/or https://<LAN-IP>:5173):

• Worker request.url origin includes host and port (:5173)
• X-Forwarded-Host preserves host and port
• Auth libraries (Clerk) that reconstruct redirects from request URL / forwarded headers keep :5173

Actual behavior

Under HTTPS:

• Handshake / redirect URLs become https://localhost/ (no :5173)
• Clerk __clerk_handshake / dev-browser-missing redirect chain loops on the wrong origin
  Under HTTP:
• Same app / Clerk setup works on http://localhost:5173

Suspected code path

In @cloudflare/vite-plugin request adaptation:

• createRequest(...) host resolution:
  • prefers Host
  • ignores :authority (pseudo-header skipped in header copy)
  • falls back to "localhost" (no port)
• toMiniflareRequest(...) then sets X-Forwarded-Host from that host

Suggested fix

When constructing the request URL / forwarded host in the Vite plugin:

1. Prefer explicit option host
2. Then req.headers.host
3. Then req.headers[':authority'] (HTTP/2)
4. Then parsed headers host
5. Only then fallback to localhost
   Also ensure the resolved host (including non-default port) is present before setting X-Forwarded-Host.

Additional context

This is especially painful for local mobile/LAN testing where HTTPS is required (secure context / LiveKit, etc.), and Cloudflare docs/issues have previously recommended HTTPS for LAN/dev cases. But this bug blocks local development with HTTPS Vite dev server.

src/start.ts:

import { clerkMiddleware } from '@clerk/tanstack-react-start/server';
import { createCsrfMiddleware, createStart } from '@tanstack/react-start';

const csrfMiddleware = createCsrfMiddleware({
  filter: (ctx) => ctx.handlerType === 'serverFn',
});

export const startInstance = createStart(() => ({
  requestMiddleware: [csrfMiddleware, clerkMiddleware()],
}));

vite.config.ts:

import fs from 'node:fs';
import { cloudflare } from '@cloudflare/vite-plugin';
import { tanstackStart } from '@tanstack/react-start/plugin/vite';
import { defineConfig } from 'vite-plus'; // or 'vite'

export default defineConfig({
  server: {
    https: {
      key: fs.readFileSync('.certs/dev-key.pem'),
      cert: fs.readFileSync('.certs/dev.pem'),
    },
  },
  plugins: [
    cloudflare({ viteEnvironment: { name: 'ssr' } }),
    tanstackStart(),
    // ...
  ],
});

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #14931

Summary

Under HTTPS (HTTP/2) dev, @cloudflare/vite-plugin drops the non-default port when reconstructing the request host, causing Clerk handshake redirects to lose :5173 and loop.

Classification

• Type: Bug
• Component: packages/vite-plugin-cloudflare
• Severity: Medium
• Has Reproduction: Partial (reproduction described in prose, no clonable link provided)
• Quality: Complete

Findings

• Created: not available (context.json truncated)
• Author: intrdx
• Version: @cloudflare/vite-plugin 1.45.1, wrangler 4.112.0, vite 8.1.5, Node v24.18.1, Windows 11
• Labels: not available (context.json truncated)
• Comments: not available (context.json truncated)

Analysis

• Component is clear: the report explicitly names @cloudflare/vite-plugin request adaptation (createRequest / toMiniflareRequest) as the source, so this maps to packages/vite-plugin-cloudflare.
• Root cause is well-articulated: on HTTPS the browser uses HTTP/2 where the authority lives in the :authority pseudo-header. The plugin skips :-prefixed pseudo-headers and falls back to "localhost" when Host is absent, so the reconstructed origin becomes https://localhost (port :5173 dropped). This is then propagated via X-Forwarded-Host, which Clerk's deriveUrlFromHeaders() uses to build the handshake redirect_url.
• Scoped and reproducible symptom: only manifests under HTTPS/HTTP2; plain HTTP on localhost:5173 works. This is a strong, specific signal that makes the bug actionable.
• Consistent with prior fixes: the reporter links related host/proto work (🐛 BUG: @cloudflare/vite-plugin redirects to wrangler port in dev server #8684/Add X-Forwarded-Host header to requests #8706, Vite plugin breaks host headers #10884, @cloudflare/vite-plugin: Worker request.url is always http://… behind a TLS-terminating proxy — dev.upstream_protocol and X-Forwarded-Proto both ignored #13801/[vite-plugin-cloudflare] Honor X-Forwarded-Proto when constructing request.url #13920), suggesting this is a remaining gap (:authority handling for HTTP/2) rather than a regression of those fixes.
• Reproduction gap: the "minimal reproduction" is described in prose (Vite HTTPS + plugin + Clerk middleware) rather than a clonable repo/link. A maintainer may be able to construct one from the description, but a link would speed verification.

Recommendation

Status: KEEP OPEN

Reasoning: This is a well-researched, plausible bug in the vite-plugin's Node-request-to-Fetch-Request adaptation, with a clearly identified root cause (dropping HTTP/2 :authority when Host is missing) and a scoped symptom (HTTPS only). It is actionable and worth investigating even though a clonable repro link is not attached.

Action: Route to the vite-plugin team to verify HTTP/2 :authority handling in the request adaptation path and, if confirmed, use :authority (including port) as a fallback when the Host header is absent so X-Forwarded-Host carries the correct host:port. Optionally ask the reporter for a minimal clonable reproduction to speed verification.

Suggested Labels: vite-plugin, bug

Suggested Comment

Thanks for the detailed write-up — the analysis of the HTTP/2 :authority vs Host handling is really helpful. To help us verify quickly, could you share a minimal clonable reproduction (a small GitHub repo we can clone and run over HTTPS)? In particular it would help to confirm:

• Whether Host is entirely absent (vs present without the port) on your HTTP/2 requests
• The exact X-Forwarded-Host value the worker receives during the Clerk handshake

With that we can confirm the fix should fall back to the :authority pseudo-header (preserving the port) when Host is missing.

Structured summary (JSON)

{
  "issueNumber": 14931,
  "title": "HTTPS dev server drops non-default port from host, breaking Clerk handshake redirects",
  "githubUrl": "https://github.com/cloudflare/workers-sdk/issues/14931",
  "recommendation": "KEEP OPEN",
  "difficulty": "medium",
  "reasoning": "Well-researched vite-plugin bug: HTTP/2 :authority is skipped and Host falls back to localhost, dropping the :5173 port from X-Forwarded-Host and breaking Clerk handshake redirects under HTTPS. Root cause is clearly identified and actionable.",
  "suggestedAction": "Route to the vite-plugin team to verify HTTP/2 :authority handling in request adaptation and fall back to :authority (with port) when Host is absent; optionally request a clonable minimal reproduction.",
  "hasSuggestedComment": true,
  "suggestedLabels": ["vite-plugin", "bug"]
}