Okay, so my initial prediction of the issue being the range header was correct. I wrote some middleware in order to ignore the range header and the scraping for the dynamic routes works great now.

If anyone else has this same problem just add a middleware.ts script into the root of the project and then what I did was add this code to essentially just delete the Range header. If you want to do something more complicated, you can check out https://nextjs.org/docs/advanced-features/middleware for more on middleware.

My code to ignore the range header:

import { NextRequest, NextResponse } from 'next/server'

export default function middleware(request: NextRequest) {
  const headers = new Headers(request.headers);
  headers.delete('Range');
  const responseWithoutRange = NextResponse.next({request: {headers}});
  return responseWithoutRange;
}

Edit: This seemed to make all my routes very slow compared to not using middleware at all so the workaround for this workaround is just by using a simple if check to make sure this is only being done if the request has the range header in the first place.

import { NextRequest, NextResponse } from "next/server";

export default function middleware(request: NextRequest) {
  if (request.headers.has("Range")) {
    const headers = new Headers(request.headers);
    headers.delete("Range");
    const responseWithoutRange = NextResponse.next({ request: { headers } });
    return responseWithoutRange;
  }
}

This is a workaround I found for now, but hopefully it gets officially fixed soon :)

This is more of a facebook crawler issue than a nextjs one, especially since the other tool worked just fine.
Moreover, if you look at the source of example, the OG tag is there, which means nextjs is doing its streaming tech as expected by browsers. For this reason I suspect nextjs will not be able to "fix" it sans introducing a facebook-specific check for its crawler. Which might or might not bode well, since crawlers generally don't like when they get fed special page versions for them.
For the slowness, by disabling Range header you basically disable response streaming, the whole point of the app directory structure. NextJS probably falls back to fully rendering the page in absence it, hence the perceived slow down.

Just for the reference, when you talk about "fb debugger", you only use it as an example because the actual prod setup doesn't show OG previews on facebook, right?

Is there any way to understand that request was made by a FB crawler and delete Range header only for those?

I tried to figure out what the heck, but failed.
I am trying to get correct opengraph previews for inner pages of the website, but FB scraper gets totally messed up meta tags, when for example, Telegram processes the links just fine.
For example, this link https://www.culturaweek.fi/fi/tapahtumat/konferenssi
See the metadata and then check what FB is getting: https://developers.facebook.com/tools/debug/echo/?q=https%3A%2F%2Fwww.culturaweek.fi%2Ffi%2Ftapahtumat%2Fkonferenssi%2F

I experienced the same issue when Facebook was crawling the links on my site.
I tried removing the "Range" header like @Culturalist suggested and it seemed to work, but again to avoid removing the header for all request make a check for whether its the facebook crawler or not.

Not totally sure that this check will catch all cases for the facebook crawler but with what I have tried, it works.

Here is the code I added to my middleware:

const headers = new Headers(req.headers);
if (
  req.headers.get("User-Agent")?.includes("facebookexternalhit") &&
  req.headers.has("Range")
) {
  headers.delete("Range");
}
// ...
return NextResponse.next({
  request: { headers },
});

This issue has been automatically marked as stale due to two years of inactivity. It will be closed in 7 days unless there’s further input. If you believe this issue is still relevant, please leave a comment or provide updated details. Thank you.