#cdn

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. https://vercel.com/docs/domains/troubleshooting

Pauline P. Narvas Hey, @suheb! Feel free to share more details about your project, it'd help us tailor our suggestions, but some ideas to get you started: **Bundle Size Optimization** - Use `<@next>` `/bundle-analyzer` to identify large dependencies: `ANALYZE=true npm run build` - Enable `optimizePackageImports` in next.config.js for icon/utility libraries - Implement code splitting and lazy loading for non-critical components - Tree-shake unused code and remove unnecessary dependencies **Image Optimization** - Use Next.js `<Image>` component for automatic optimization - Images are served in modern formats (WebP/AVIF) reducing size by 25-35% - Enable lazy loading and use `sizes` prop for responsive images - Consider using a CDN for very large image libraries **Build & Deployment Speed** - Leverage Vercel's build cache (enabled by default) - Use Turborepo for monorepos to cache and parallelize builds - Consider enhanced build machines for large projects (up to 70% faster) - Enable Turbopack for faster local development Let us know how you get on!

Ryu A good way to approach this is to separate build/deployment size from runtime loading performance. For deployment/build size: * Remove unused dependencies. * Check for large assets accidentally included in the repo. * Avoid bundling server-only packages into client components. * Use dynamic imports for heavy UI/client-only code. * Keep generated files, uploads, and local cache folders out of the deployment. For page performance: * Use `next/image` for images. * Compress large images before uploading them. * Lazy-load below-the-fold components where it makes sense. * Check bundle size with a bundle analyzer. * Use Vercel Speed Insights or Web Vitals to see what is actually slow. The most useful first step is usually to identify the biggest files/dependencies instead of guessing. Once you know whether the problem is large assets, heavy JS, or slow server/data fetching, the fix is much clearer.

Ryu Hi Devansh, If those Sentry events cluster around deploy times, I’d treat this as version skew first. With `dynamic(() => import(...), { ssr: false })`, the browser may not request that CSS/JS chunk until later. If the user loaded HTML/JS from an older deployment, then a new production deployment goes live, that old client can later try to fetch a chunk URL that no longer exists on the deployment it is being routed to. That usually shows up as: ``` Loading CSS chunk failed /_next/static/css/<hash>.css ``` A good way to confirm is to check the failed asset request in Sentry or browser devtools: ``` status: 404 or failed network request url: /_next/static/css/... time: close to a new deployment ``` I’d also compare one failed chunk URL directly: ``` curl -I https://your-domain.com/_next/static/css/FAILED_HASH.css ``` If it returns `404`, and the event happened after a deployment, that strongly points to stale client/runtime vs new deployment assets rather than a normal React error. A few mitigations I’d check: * enable/verify Vercel Skew Protection if your plan/project supports it * make sure HTML/RSC responses are not being cached by an extra CDN/proxy in front of Vercel * do not override caching for `/_next/static/*` * keep deployment retention / skew max age long enough for typical user sessions * add a one-time reload fallback for chunk-load failures so users recover instead of staying on a broken page Vercel’s Skew Protection docs describe the exact problem: keeping framework-managed JS/CSS/data requests pinned to the deployment that served the original page: https://vercel.com/docs/skew-protection I would not remove `dynamic()` just because of this. Dynamic imports can make the issue more visible because chunks are requested later, but the underlying thing to prove is whether the failed CSS URL is from an older deployment and returning 404 after rollout.

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. https://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 normalize `deckclip.app.` to `deckclip.app` before selecting the certificate, the handshake can fail before any HTTP request exists. The practical workaround is to avoid generating or linking to the trailing-dot form anywhere in your app/canonical URLs. For users manually typing `https://deckclip.app``./`, there probably is not a project-side fix unless Vercel changes edge/SNI normalization behavior. The useful evidence to keep in the thread is exactly what you already have: same domain, same IP path, only the SNI value changes, and the trailing-dot SNI fails before HTTP.

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. https://vercel.com/docs/projects/domains/troubleshooting You can also use v0 to narrow down the possibilities.

Agus 6148 did you ever figure it out? having the same issue

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. https://vercel.com/docs/projects/domains/troubleshooting You can also use v0 to narrow down the possibilities.

Pauline P. Narvas In most cases, if you exceed your usage limits on the Hobby plan, you will have to wait 30 days before you can use the feature again.

mwask will all my projects be paused???

Longnguyenthanh075 5963 I am having the same issue as I approaching end limits of 10GB, the document said up to 10GB for Hobby plan and no mention of resetting as well. I am well past that 30-day period but have not see it resets. I checked with the CS bots from vercel it said the limit will be resetted.

Pauline P. Narvas Welcome to the Vercel Community! Cool project Vercel’s CDN supports HTTP/2 through ALPN negotiation. When testing with curl, try: `curl -I --http2-prior-knowledge https://reeflocal.io` The results are: ``` HTTP/2 200 accept-ranges: bytes access-control-allow-origin: * age: 69 cache-control: public, max-age=0, must-revalidate content-disposition: inline content-type: text/html; charset=utf-8 date: Fri, 17 Apr 2026 11:08:08 GMT etag: "4b264812b229d2b3a2943254c19261d8" last-modified: Fri, 17 Apr 2026 11:06:58 GMT server: Vercel strict-transport-security: max-age=63072000 x-vercel-cache: HIT x-vercel-id: lhr1::29hdk-1776424087993-d123805054ce content-length: 9145 ``` For Brotli/gzip compression, include the Accept-Encoding header: `curl -H "Accept-Encoding: gzip, br" -I https://reeflocal.io` I can see: ``` HTTP/2 200 access-control-allow-origin: * age: 108 cache-control: public, max-age=0, must-revalidate content-disposition: inline content-encoding: br content-type: text/html; charset=utf-8 date: Fri, 17 Apr 2026 11:08:46 GMT etag: W/"4b264812b229d2b3a2943254c19261d8" last-modified: Fri, 17 Apr 2026 11:06:58 GMT server: Vercel strict-transport-security: max-age=63072000 x-vercel-cache: HIT x-vercel-id: lhr1::f8fq6-1776424126886-571b3cb5b9a5 ``` If you’re behind a proxy, it might downgrade connections to HTTP/1.1. Test from a different network to confirm!

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. https://vercel.com/docs/projects/domains/troubleshooting You can also use v0 to narrow down the possibilities.

Pauline P. Narvas We have a guide for this: https://vercel.com/kb/guide/resolve-err-too-many-redirects-when-using-cloudflare-proxy-with-vercel Let us know how you get on!

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. https://vercel.com/docs/projects/domains/troubleshooting You can also use v0 to narrow down the possibilities.

Ryan K **Additional details:** * Domain: `www.jobbox.cc` * Vercel project: `jadash` * Both domains show "Valid Configuration" in dashboard * DNS resolves to two IPs via CNAME `b75307a8ca13a8ee.vercel-dns-017.com`: `216.198.79.1` and `64.29.17.1` * `curl` tests with SNI pass correctly on all IPs * SSL Labs shows Certificate #2 (No SNI) serving `no-sni.vercel-infra.com` with MISMATCH — serial number `06ea88a51285ec7fd039f147fe24ea020104` * This persisted even after removing and re-adding both domains to force SSL re-provisioning * Real users are getting "Safari can't establish a secure connection" and "Website can't be reached" errors * Certificate #1 (with SNI) shows subject as `jobbox.cc` only — `www.jobbox.cc` not in Alternative Names

Pauline P. Narvas Can you try clearing Vercel’s Edge Cache? Go to your project dashboard → Settings → Functions → Purge Everything. This will clear all cached content. Give that a go and let us know how you get on!

Jacob Paris Where are you seeing the NOT FOUND errors? Can you share the one of the request IDs that doesn't exist in your project and I'll see if I can track down what project it's supposed to be related to? Double check though that it's not just a request that's older than your log visibility, as that'd be the obvious reason it doesn't show up About the architecture: you seem to be using your BFF layer just as a proxy, so if one of your pages needs to make three calls to your backend, that's three calls coming from your frontend, through the BFF, to your backend, and then back A big part of the value of the BFF is that you can make a custom "endpoint" in your app to perfectly serve a page's requirements, so it's only one hop from the frontend to the BFF, then a few back and forth to the backend, and then one hop back to the frontend with everything it needs. You want those "back and forth" hops to be as short as possible, so ideally the BFF is deployed to the same datacenter as your backend (or as close as possible) The edge runtime positions the BFF closer to the user instead, so it actually hurts performance in this case as the multiple round trips will be happening over a longer geographical distance. If you prefer to continue doing a straight proxy approach (which does give you the DDoS protection, observability, etc) we're actually doing that with this forum here. You can make a new Vercel project for your hetzner backend and deploy a vercel.ts file that rewrites all traffic to your hetzner URL. On the hetzner side, you verify that the proxy header is included and then you know there can't be any direct access outside of the vercel proxy. https://vercel.com/blog/how-we-run-vercels-cdn-in-front-of-discourse

Acud Hi @jacobparis . Thanks for your response. Here’s an identifier of one of the errors: `fra1::6cwcg-1775199256422-25c889bae8fc`. To answer your first question, the error is seen in the browser when the browser does a call to the backend through the function to start and OAuth flow with Google. The observed behavior is that most of the time it works, then at some point it just packs up and the error starts showing, until after some time it resolves again. There’s nothing concrete I can point to that causes this behavior. It isn’t a function cold start either. It just errors fast and immediately, no delay or anything, which is quite strange. I’ve never been able to find it in the logs. Not immediately after and not some time after. Thank you for clarifying the deviation from the BFF proxy. What you’re saying does make a lot of sense, and I’ll have to revisit this design at a later stage. For now, the relevant functionality has been removed so that I could just unblock and continue working by calling the backend directly. The problem mentioned above, though, still puzzles me. Since the errors aren’t traceable and those request IDs don’t show up in the project’s logs, I would be quite averse to using Vercel functions in general as this seems to create significant unknowns in the process of debugging things.

Pauline P. Narvas Have you had a look at these docs? https://vercel.com/docs/errors/INFINITE_LOOP_DETECTED > To troubleshoot this error, follow these steps: > 1. Check the application's source code: Look for any code that might cause an infinite loop, such as a looping fetch or an unconditional redirect > 2. Check the application's configuration: Review any configuration files, such as `next.config.js` or `vercel.json`, to ensure they are not causing the infinite loop > 3. Review external API or database calls: Ensure that any external API or database calls your application is making do not have errors or infinite loops > 4. Handle unhandled exceptions: Check the application logs for any unhandled exceptions that might be causing the infinite loop > 5. Use Vercel's status page: If you have tried the steps above and are still experiencing the error, check Vercel's status page for any reported outages in the CDN, which can sometimes cause this error If you're using an LLM, you can also use the following prompt: ``` I'm encountering an error and reviewing the docs at https://vercel.com/docs/errors/INFINITE_LOOP_DETECTED.md to understand what's happening. Please help me resolve this by: 1. **Suggest the fix**: Analyze my codebase context and propose what needs to be changed to resolve this error. If you do not have access to my codebase, ask me for the codebase and try to fix the error based on the information you have. 2. **Explain the root cause**: Break down why this error occurred: - What was the code actually doing vs. what it needed to do? - What conditions triggered this specific error? - What misconception or oversight led to this? 3. **Teach the concept**: Help me understand the underlying principle: - Why does this error exist and what is it protecting me from? - What's the correct mental model for this concept? - How does this fit into the broader framework/language design? 4. **Show warning signs**: Help me recognize this pattern in the future: - What should I look out for that might cause this again? - Are there similar mistakes I might make in related scenarios? - What code smells or patterns indicate this issue? 5. **Discuss alternatives**: Explain if there are different valid approaches and their trade-offs My goal is to fix the immediate issue while building lasting understanding so I can avoid and resolve similar errors independently in the future. ```

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. https://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.

Pauline P. Narvas Could you try the following? Go to your Vercel dashboard → Project Settings → Caches → Purge Everything See if that fixes it!

Pauline P. Narvas That is odd! Do you have a URL handy for us to take a look? Otherwise, I recommend redeploying if you haven’t already. Make sure build cache is off!

Al441395 Hi! It doesn’t look like an edge cache issue. A Vercel `NOT_FOUND` response usually means there is no active deployment serving that domain, rather than stale cached content. Since the request is reaching Vercel (you have an `x-vercel-id`) and you already tried purging the CDN cache, it’s unlikely that caching is the problem. This typically happens when there is no successful “Ready” deployment, the production alias is missing, or the domain is not pointing to an active deployment. In other words, Vercel isn’t finding anything to serve for that domain at the moment. I’d recommend checking your deployments to make sure there is one in a “Ready” state, that it’s assigned to production, and that the domain is correctly connected to it. If everything looks off, try redeploying and promoting it to production. Hope this helps

Ryu Hi Operendia, Your evidence points away from the app upload code and toward the public Blob serving path. If the Blob API can list the object with `HTTP 200`, but the direct public URL returns: ``` 503 SERVICE_UNAVAILABLE X-Vercel-Error: SERVICE_UNAVAILABLE Body: The deployment is currently unavailable ``` then this is not a normal “file missing” case. A missing blob would be a different kind of failure, and your URL format also matches the public Blob URL format Vercel documents: https://vercel.com/docs/vercel-blob/public-storage I’d do one isolation test before escalating it as store-specific: ``` 1. Create a brand-new public Blob store in the same team 2. Upload one tiny test image/text file with access: "public" 3. Open the returned public URL directly with curl -I ``` If the new store works but `pywla5knjbnow7ji.public.blob.vercel-storage.com` still returns 503 for every object, that strongly suggests the old store’s public serving layer is stuck or unavailable. If the new store also returns 503, then I’d check whether the team/project is paused, blocked, or over a Blob usage limit, because that would affect serving even if the token can still perform some API operations. The useful escalation summary would be: ``` Store ID: pywla5knjbnow7ji Blob API list/upload: 200 Public blob URL: 503 SERVICE_UNAVAILABLE Affects all blobs, old and new Tested from multiple networks Latest X-Vercel-Id: Latest timestamp: New public Blob store test result: Team/project paused or usage-limit banner: yes/no ``` Do not post the `BLOB_READ_WRITE_TOKEN`, but the public blob URL, `X-Vercel-Id`, and timestamp are safe and useful for Vercel to correlate.

Anshuman Bhardwaj Hi @schutzworks, welcome to the Vercel Community! Can you try setting the header value in `vercel.json` to an empty string? https://vercel.com/docs/project-configuration/vercel-json#headers

Anshuman Bhardwaj Hi @ahmadsajid3470-5358, I'm happy that you're considering Vercel for your project. I think you can find some of the biggest New Media outlets on our https://vercel.com/customers page. If you optimize and cache your content properly, I think Vercel can take you very far. Let me know if you have specific questions.

Selçuk Çukur Yes, Vercel is definitely suitable for a gaming content and news site like yours. Since most of your pages are static (guides, updates, blog posts), Vercel’s global CDN will serve them super fast to visitors everywhere. * **Performance:** Static content is cached at the edge, so even during traffic spikes after big game updates, pages load quickly. * **SEO:** If you’re using Next.js or similar, server‑side rendering and fast response times help search engines index your content properly. * **Traffic handling:** You don’t need to worry about scaling servers — Vercel automatically handles spikes in traffic. * **CDN:** Built‑in CDN means your content is globally available without extra setup. In short, for a gaming news and guide site, Vercel gives you speed, scalability, and simplicity. If you add dynamic features later (comments, accounts, etc.), you can extend with serverless functions or external APIs.

Ahmad Sajid Thanks man this helps me.