Slik fikser du intern feil 500 i Next.js Server Components

Du åpner en rute i et Next.js App Router-prosjekt, siden fungerte for et øyeblikk siden, og nå viser nettleseren en Intern serverfeil eller et HTTP 500-svar. Oppfriskning hjelper ikke. Konsollen på klientsiden kan vise lite nyttig informasjon fordi feilen oppstod mens en Server Component ble gjengitt på serveren.

Denne situasjonen er vanlig nok til å føles mystisk, men en 500-feil er ikke en diagnose. Det betyr at serveren møtte en uventet tilstand under håndtering av forespørselen. Next.js kan returnere en 500-feil for en uhåndtert applikasjonsfeil, og Server Components er spesielt viktige å inspisere fordi de kan utføre dataadgang, databasespørringer, autentiseringssjekker og annen serverkunlogikk under gjengivelse.

Versjonsnotat: som kontrollert den 11. september 2026, lister den offisielle Next.js-dokumentasjonen Next.js 16.3.4 som den nyeste versjonen. Feilformuleringer, utviklingsoverlegg, kjøretidsatferd og distribusjonslogger kan variere etter versjon og hostingplattform, så bruk stabelsporet fra ditt eget prosjekt som primært bevis.

Hva forårsaker vanligvis en 500-feil i en Server Component?

I App Router bruker Next.js Server Components som standard. Den offisielle dokumentasjonen for Server- og Client Components forklarer at Server Components utføres på serveren og kan utføre serverbasert arbeid som dataadgang. Hvis en av disse operasjonene kaster en feil og unntaket ikke håndteres på en måte som produserer et gyldig svar eller en reserve, kan forespørselen mislykkes.

Trinn 1: Reproduser den feilende ruten lokalt og les serverutdataene

Nettleseren forteller deg at en forespørsel mislyktes; serverens stabelspor vil sannsynligvis fortelle deg hvorfor. Se etter den første linjen i din egen applikasjonskode snarere enn den siste linjen inne i rammeverkets interne deler. Registrer ruten, filen, linjenummeret, feiltypen og om feilen oppstår ved hver forespørsel eller kun med spesifikke data.

Hvis problemet kun skjer i produksjon, bruk vertens kjøretidslogger i stedet. På Vercel skiller den offisielle loggingveiledningen mellom byggelogger og kjøretidslogger og forklarer at kjøretidsoppføringer kan filtreres etter statuskode og forespørselssti. Vercel dokumenterer også at en funksjonsinvokasjonsfeil kan returnere en 500 når kjøretiden krasjer eller et ufanget unntak eller avvisning oppstår.

Trinn 2: Isoler datahenting og gjør feil eksplisitte

Server Components feiler vanligvis mens de venter på en oppstrøms API eller database. Den offisielle Next.js-opplæringen for datahenting viser Server Components som utfører asynkron serverbasert dataadgang. Behandle hver ekstern avhengighet som et mulig feilpunkt.

For fetch(), skill mellom en nettverksfeil og et HTTP-feilsvar. Et svar med en ikke-suksessstatus bør sjekkes før du analyserer eller gjengir dataene. En liten wrapper gjør det virkelige problemet synlig i serverloggene:

async function getData() {
  const apiUrl = process.env.API_URL;

  if (!apiUrl) {
    throw new Error('API_URL is not configured');
  }

  const response = await fetch(apiUrl, { cache: 'no-store' });

  if (!response.ok) {
    throw new Error(`Upstream request failed: ${response.status}`);
  }

  return response.json();
}

Logg ikke tilgangstokens, informasjonskapsler, autorisasjonshoder, databasepassord eller fullstendige URL-er som inneholder hemmeligheter. En statuskode, forespørselsmålnavn, korrelasjons-ID og sanitert feilmelding er normalt nok til å identifisere den feilende avhengigheten.

Trinn 3: Sjekk miljøvariabler og server/klient-grensen

Hvis samme commit fungerer lokalt men returnerer 500 etter distribusjon, sammenlign miljøene før du endrer applikasjonslogikk. Bekreft at hver nødvendig serverbasert variabel finnes i distribusjonsmålet og at verdien peker til en tjeneste som er nåbar fra det kjøretidsmiljøet. En lokal .env-fil beviser ikke at produksjonsdistribusjonen har de samme verdiene.

Inspekter deretter komponentgrenser. Next.js Server Components er standard i App Router, mens interaktiv kode som trenger tilstand, effekter, hendelsesbehandling eller nettleserbaserte API-er hører hjemme i en Client Component. Det offisielle Next.js-opplæringsmaterialet demonstrerer å flytte en komponent som bruker useState bak en 'use client'-direktiv. Noen grensefeil fanges under kompilering snarere enn å bli en 500-feil, men å utelukke dem forhindrer deg i å behandle en kodestrukturfeil som en hostingstans.

Sjekk også alle serverbare pakker som antar en spesifikk Node.js-funksjonalitet, filsystemstruktur, binær eller nettverksmiljø. En avhengighet kan fungere på én maskin og feile i et annet kjøretidsmiljø hvis disse antakelsene er ulike.

Trinn 4: Legg til riktig feilhåndtering i stedet for å skjule unntaket

Når rotårsaken er kjent, avgjør om feilen er forventet eller uventet. En manglende post kan fortjene et ikke-funnet-svar. En valideringsfeil kan fortjene en normal melding. Et uventet unntak bør logges og tillates å nå en feilgrense i stedet for å bli stille konvertert til tomme data som bryter et annet sted.

Next.js dokumenterer den spesielle error.tsx-filen som en rute-segment feilgrense for uventede feil. Komponenten er en Client Component og kan tilby en ny forsøk gjennom den medfølgende reset-funksjonen. Den offisielle Next.js-feilhåndteringsveiledningen demonstrerer også bruk av notFound() når en forespurt ressurs ikke eksisterer.

'use client';

export default function Error({
  reset,
}: {
  reset: () => void;
}) {
  return (
    <main>
      <h2>Noe gikk galt.</h2>
      <button onClick={() => reset()}>Prøv igjen</button>
    </main>
  );
}

En feilgrense forbedrer hva brukeren ser; den fikser ikke det underliggende unntaket. Behold serverbasert logg som identifiserer årsaken, og eksponer ikke følsomme stabelspor eller hemmeligheter i brukergrensesnittet.

Trinn 5: Verifiser fiksen i et produksjonslignende bygg

En utviklingsserver er nødvendig for diagnose, men det er ikke den endelige testen. Etter at ruten fungerer lokalt, kjør et produksjonsbygg med prosjektets pakkebehandler, start det i produksjonsmodus når det er praktisk, og forespør den samme ruten med de samme relevante dataforholdene. Verifiser deretter det distribuerte miljøet med åpne kjøretidslogger.

npm run build
npm start

Hvis hostingplattformen bygger annerledes enn din bærbare datamaskin, test også en forhåndsvisningsdistribusjon før du fremmer endringen. En fiks er kun troverdig når ruten returnerer forventet status, gjengir forventet innhold, og ingen ny serverunntak vises for den forespørselen.

Slik bekrefter du at 500-feilen faktisk er fikset

• Den tidligere feilende URL-en lastes gjentatte ganger uten et HTTP 500-svar.
• Serverterminalen eller produksjonskjøretidsloggene viser ikke lenger det opprinnelige unntaket.
• Samme fiks overlever npm run build og en produksjonsmodus-kjøring eller forhåndsvisningsdistribusjon.
• Nødvendige miljøvariabler er til stede i miljøet der feilen opprinnelig oppstod.
• Eksterne API- eller databasefeil produserer nå en kontrollert feilbane i stedet for et uforklarlig krasj.
• Interaktiv nettleserbasert kode er inne i Client Components, mens hemmeligheter og privilegert dataadgang forblir på serveren.
• En error.tsx-grense gir brukerne en rimelig reserve for uventede rute-segmentfeil.

Hvis det fortsatt feiler

Reduser ruten til den slutter å feile. Erstatt midlertidig én avhengighet om gangen med en kjent sikker verdi: først databasekallet, deretter den eksterne API-en, deretter autentisering eller sesjonsoppslag, deretter barnekomponenter. Den første fjernede operasjonen som får 500-feilen til å forsvinne, identifiserer området som skal undersøkes. Gjenopprett hver avhengighet etter testing i stedet for å la falske data være i den endelige applikasjonen.

For et produksjonskun problem, sammenlign den nøyaktige distribuerte commit-en, Node-/kjøretidskonfigurasjonen, miljøvariablene, nettverksnåbarheten og avhengighetsversjonene. Hvis plattformen rapporterer en leverandørspesifikk feilkode, bruk leverandørens offisielle dokumentasjon for den nøyaktige koden i stedet for å anta at alle 500-feiler har samme årsak.

Den viktigste feilsøkingsregelen er enkel: behandle «Intern feil 500» som symptomet. Det nyttige beviset er serverbasert unntak som skjedde umiddelbart før det. Finn det unntaket først, gjør den feilende avhengigheten eksplisitt, korriger miljøet eller kodegrensen som utløste det, og verifiser resultatet i det samme kjøretidsmiljøet der problemet oppstod.