#nextjs

system The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points. vercel.com/docs/projects/domains/troubleshooting You can also use v0 to narrow down the possibilities.

SkyMesh Dynamics ah, then I'm not the only one who reported this

Ryu Hi Yuze, Your openssl test is a good way to narrow it down. Since this fails when the trailing dot is included in SNI: echo | openssl s_client -connect deckclip.app:443 -servername 'deckclip.app.' but works without it: echo | openssl s_client -connect deckclip.app:443 -servername 'deckclip.app' then this is happening before your Next.js app or vercel.json redirects can run. So I don’t think there’s an app-level redirect/header fix for the HTTPS case. A trailing dot is valid in DNS as an absolute/FQDN form, but TLS certificate/SNI matching is a separate layer. If Vercel’s edge does not normaliz

Ryu Hi Adam, I’d separate “the environment variable exists” from “the request is actually sending the right auth to the right place.” If this is using Vercel AI Gateway, the request should be server-side and should send the Gateway key as a bearer token to the Gateway endpoint, not expose it in the browser: const response = await fetch("ai-gateway.vercel.sh/v1/chat/completions", { method: "POST", headers: { Authorization: Bearer ${process.env.AI_GATEWAY_API_KEY}, "Content-Type": "application/json", }, body: JSON.stringify({ model: "openai/gpt-4.1-mini", messages: [{ role: "user", content: "test" }

Craiguito Since vercel build && vercel deploy --prebuilt works, I’d treat Git Integration as the broken layer here and stop trying to fix it inside next.config. The useful workaround is probably to make prebuilt deploys the normal GitHub path for now: GitHub Action on pushes to your deploy branch cd rtlab_dashboard install/build/test there vercel build --token ... vercel deploy --prebuilt --archive=tgz --target=production --token ... That keeps Vercel from re-finalizing from the repo root and uses the output you already proved works. If you still want to chase Git Integration, I’d make a tiny public rep

Ryu Hi ya2s, I'd treat this as a limitation of combining a plain Multi-Zone rewrite with Vercel Authentication on the destination project. A rewrite can keep the browser URL on Project A for normal traffic, but once Project B's Deployment Protection challenges the request, the auth flow belongs to Project B. That means the redirect/cookie flow can reasonably end up on Project B's deployment/custom domain instead of staying fully masked behind Project A. For the architecture you want, I don't think a vercel.json rewrite alone is the right layer, because it can't safely attach a private bypass secre

Ryu Hi Adeline, Your suspicion sounds pretty reasonable. When an AI app grows from "one prompt generates everything" into multiple muses, menus, timelines, variations, etc., the fragile part is usually that too much decision-making is left inside the prompt. I'd separate this into a more deterministic pipeline: User selects / describes the party App deterministically chooses the muse/theme metadata from a fixed JSON or database table AI generates only the sections that actually need language generation Output is validated against a schema Failed or mismatched sections are retried individually, not

Ryu Hi James, For an /api/og route handler, I'd first check the response headers rather than assuming it is cached automatically. In the App Router, route handlers are not cached by default unless you opt into caching or return cache headers. A quick test would be: curl -I "your-domain.com/api/og?type=page&id=example" curl -I "your-domain.com/api/og?type=page&id=example" Look at cache-control and x-vercel-cache. If you see MISS/no useful cache headers each time, the image is probably being regenerated on requests. For a generated OG image that can be reused, you can try adding cache headers to the

system The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points. vercel.com/docs/projects/domains/troubleshooting You can also use v0 to narrow down the possibilities.

Vinaydabas611 40 viewers/day is low for 3h50 of CPU, so before pinning it on crawlers or compute, confirm your actual request count in the logs. If it's far above your real traffic, the usual hidden cause is your own app re-firing server renders --- a router.refresh() / auto-refresh on tab focus or navigation, aggressive client-side polling, or default prefetch firing a burst of RSC requests on every page. (A third-party uptime monitor on a tight interval does the same.) The tell is a repeating, multi-route request pattern in the logs that no human would produce. If real crawlers are a big share: a robots.t

system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

system There's another community post with 404 debugging tips that might be helpful. Please give these solutions a try and let us know how it goes. community.vercel.com/t/debugging-404-errors/437 A human should be around soon to offer more advice. But you can also get helpful information quickly by asking v0.

system The domain troubleshooting guide can help with most custom domain configuration issues. You might be able to use that guide to solve it before a human is available to help you. Then you can come back here and share the answer for bonus points. vercel.com/docs/projects/domains/troubleshooting You can also use v0 to narrow down the possibilities.