#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/domains/troubleshooting

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.

Lucynkohla 5313 Update: wanted to rule out this being specific to my project before assuming it's just this one alias. I created a brand-new, unrelated project under the same team and deployed the same app to it as its very first deployment. It has the identical fault — clean alias returns 404: NOT_FOUND immediately, and even a completely fresh deployment (zero shared history, build only minutes old) returns platform 404 on every route once past Vercel Authentication. That rules out project-level corruption or stale config for me — this looks like it's scoped at the team/account level rather than anything wro

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.

Amy Egan There are a lot of possible causes. I hope you were already able to solve it using the tips shared by the bot. If not, it would be helpful to see the site and code to get a better understanding of what's going wrong in this case. Are you able to share a minimal reproducible example or a publicly accessible URL for the site?

Ryu Hi Elmar, Nice minimal repro. Since local next start is byte-perfect and the deployed Node function changes invalid UTF-8 byte sequences into ef bf bd, I’d keep treating this as a response serialization boundary issue, not a sharp or image-specific issue. To narrow it down, I’d split the workaround into separate deployed variants: // A: Buffer + Content-Length return new Response(buf, { headers: { "Content-Type": "application/octet-stream", "Content-Length": String(buf.byteLength), }, }) // B: plain Uint8Array copy, no Content-Length return new Response(new Uint8Array(buf), { headers: { "Conte

Ryu Hi Zangyj1971, I don’t think another community member can reliably confirm whether CLI issue #17069 is still present in 58.0.0, but you can separate the documented workflow from the suspected bug pretty cleanly. The documented CLI behavior is that a normal CLI deploy without --prod should create a Preview deployment, while --prod creates Production. So for a fresh linked project, the safest thing to test is: vercel deploy --target=preview --logs vercel inspect <deployment-url> Then check the inspected deployment’s environment/target before using it in any release flow. For Git, Vercel treats 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.

Ryu Hi Radit, The part I’d double-check is whether the URL you’re testing is the deployment’s unique generated URL from the deployment details page, not only project/branch aliases. A platform 404: NOT_FOUND on an alias can be an alias/routing issue. A platform 404: NOT_FOUND on the unique deployment URL is a stronger signal that the deployment is not being served correctly at the edge even though the dashboard says Ready. I’d capture all three side by side: curl -sSI nova-new-bay.vercel.app | egrep -i 'HTTP/|x-vercel|server|cache|age' curl -sSI nova-home-web-git-main-xxxx-7119s-projects.vercel.ap

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.

Ryu Hi Solomon, The Functions tab only showing /api/auth/[...nextauth] is not necessarily a problem by itself. Static App Router pages will not always show up there as functions. The more important signal is the exact 404 type and which URL is returning it. I’d separate three cases: Unique deployment URL returns 404 Project/production alias returns 404 Only specific app paths like /todo return 404 Can you test the unique deployment URL from the deployment details page, not just the project alias? curl -I https://<deployment-id-or-unique-url>.vercel.app/ curl -I https://<deployment-id-or-unique-url

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/domains/troubleshooting

Bahadurkhan10 I am experiencing the same problem for one of US location. Have you found any solution for this issue of yours, that will be very helpful to me. community.vercel.com/t/custom-domain-inaccessible-from-one-us-isp-location-while-vercel-app-url-works/46326?u=bahadurkhan10

Ryu Hi Agnipickles, One thing I’d separate here: the git.deploymentEnabled block only controls whether a Git push creates a deployment. It does not decide whether that deployment is Preview or Production. The target should mainly come from the project’s Production Branch setting or from an explicit CLI target. So I’d check Project Settings → Environments → Production → Branch Tracking and confirm the production branch is exactly: production-disabled Then I’d try one very small smoke test with a branch name that does not include prod or production, just to remove naming/rules confusion: git checkou

Ryu Hi Xydotguy, I can’t help with internal scheduling, but the repro you described does sound narrow enough to make this actionable. For a production workaround, I’d try to avoid the exact combination that seems to trigger the duplicate headers: render-time redirect() / permanentRedirect() inside a statically cached or force-static route. If the redirect is known from the URL alone, moving it to next.config.js should avoid the App Router render path entirely: module.exports = { async redirects() { return [ { source: "/old-path", destination: "/redirect", permanent: true, }, ] }, } If it has to be

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.

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.

Amy Egan Where you able to get it solved?

Ryu Hi Senseijayrome, v0 creates its own working branch off main when a chat is connected to GitHub, so if it is stuck at “Create Branch” I’d first separate repo permissions from the v0/GitHub connection state. A few things I’d check: In GitHub, confirm the Vercel/v0 GitHub app has access to AtlasJamaica/atlas-transportation-solutions-jamaica, not just your GitHub account generally. Check whether the repo has branch protection or repository rulesets that block creating or pushing branches matching v0/*. Try creating a test branch manually from main: git fetch origin git checkout -b v0/manual-test