Hogyan javítsa a 404-es hibákat telepítés után

Ha az appja helyben működik, de telepítés után 404-et ad az oldal, a leggyakoribb ok a hiányzó egyoldalas app (SPA) útválasztás: a szerver a /dashboard nevű fájlt keresi, amely nem létezik, mert ez az útvonal csak a JavaScriptben van meg. A javítás egy fallback-szabály, amely az app útvonalaira az index.html-t szolgálja ki. Más okok: hiányzó fájlok a build kimenetében, kis- és nagybetűre érzékeny útvonalak, záró perjel különbségek, rossz base path, és olyan API-útvonalak, amelyek soha nem települtek.

Kezdje azzal, hogy pontosan feljegyzi, melyik URL ad 404-et és hogyan jutott el oda. A minta közvetlenül a okra mutat.

1. lépés: Keresse meg a mintát

A valódi státuszkód megtekintéséhez nyissa meg a fejlesztői eszközöket (jobb klikk → Vizsgálat), menjen a Hálózat fülre, frissítsen, és nézze meg az első kérés státuszát.

2. lépés: Adja hozzá az SPA-fallbacket

Ez a klasszikus eset. Egy React-, Vue- vagy Svelte-alapú egyoldalas appban a szervernek csak néhány valódi fájlja van: index.html, néhány JavaScript- és CSS-fájl. Az olyan útvonalakat, mint a /dashboard vagy a /projects/42, a böngészőben futó router kezeli.

• Linkre kattintás működik: a router megváltoztatja az URL-t, és a böngészőben rajzolja ki az új oldalt, a szervert nem kérdezve.
• Frissítés vagy közvetlen megnyitás nem működik: a böngésző a szervertől a /dashboard-ot kéri, a szervernek nincs ilyen fájlja, és 404-et ad.

A javítás egy szabály, amely azt mondja: ha a kérés nem egyezik egy valódi fájllal, szolgálja ki az index.html-t 200 státusszal, és hagyja, hogy a router átvegye. Hogy ez hogyan történik, a hosztól függ (ellenőrizze a hosztja aktuális dokumentációját, mert a részletek változnak):

Győződjön meg róla, hogy a szabály nem nyeli el a valódi fájlokat: a /assets/app.js kérésre továbbra is a JavaScript fájlt kell visszaadnia. Ha helyette index.html-t ad, üres oldalt és „Failed to load module script” hibát kap. Lásd: hogyan javítsa az üres fehér oldalt.

Adjon a routernek egy catch-all útvonalat is, hogy az oldalak nélküli URL-ek barátságos „Az oldal nem található” üzenetet mutassanak, és ne semmit.

Ha nem tudja módosítani a szerverbeállításokat, a hash-alapú útválasztás (/#/dashboard típusú URL-ek) elkerüli a problémát, mert a # utáni rész soha nem kerül a szerverre. Ez megkerülés, nem első választás: az URL-ek csúnyábbak, és kevésbé barátságosak a keresőmotoroknak.

Az olyan keretrendszerek, amelyek szerveroldalon renderelnek vagy build időben generálnak oldalakat (Next.js, Astro és hasonlók), általában valódi fájlokat vagy szerver-útvonalakat adnak minden oldalhoz, így itt ez a probléma ritkább. Az ő megfelelőjük az, ha egy oldal nem lett generálva build időben.

3. lépés: Ellenőrizze, mi lett valójában telepítve

Ha minden 404-et ad, a szerver valószínűleg nem a felépített appot szolgálja ki.

• A megfelelő mappa. A hostnak a build kimenetét kell közzétennie (Vite esetén általában dist, Create React App esetén build, statikus Next.js exportnál out), nem a projekt gyökerét.
• A build lefutott. Olvassa el a telepítési naplót. Ha a build hibázott, a host lehet, hogy semmit nem telepített, vagy egy régi verziót.
• Az index.html a közzétett mappa legfelső szintjén van, nem egy almappában.
• A base path egyezik. Ha az app a example.com/app/ alatt fut, azzal a base-szel kell buildelni (Vite base, React Router basename), különben minden útvonal és eszköz elvész.

4. lépés: Javítsa a hiányzó fájlokat és a rossz útvonalakat

Ha az oldalak betöltődnek, de az eszközök 404-et adnak:

• Kis- és nagybetű-érzékenység. A macOS és a Windows általában ugyanannak tekinti a Logo.png és a logo.png fájlokat. A legtöbb Linux-szerver nem. Minden hivatkozás egyezzen pontosan a valódi fájlnévvel.
• Fájlok a buildon kívül. Vitében a public/ mappa fájljai változatlanul másolódnak, és a gyökérről hivatkozhatók (/logo.png). A kódban importált fájlok bele vannak csomagolva. A projekt más helyén lévő fájl lehet, hogy egyáltalán nem települ.
• Relatív útvonalak. Az images/photo.jpg az aktuális URL-hez képest oldódik fel, ezért a /blog/post-1 oldalon eltörik. Használja a /images/photo.jpg formát.
• Helyi lemezre mentett feltöltések. Ha a felhasználói feltöltések a szerver saját mappájába kerültek, eltűnnek, amikor új verzió települ. Használjon megfelelő fájltárolást.

5. lépés: Kezelje egységesen a záró perjeleket

A /about és a /about/ különböző URL-ek. A hosztok eltérően kezelik, hogy hozzáadnak vagy eltávolítanak-e perjelet, és ha ez nem egyezik a linkjeivel vagy a routerrel, 404-et vagy átirányítási hurkot kaphat. Válasszon egy stílust, használja a linkjeiben, és állítsa be a hostot, hogy a másik formát erre irányítsa át. A következetesség a keresőmotoroknak is segít, amelyek egyébként minden oldalból két példányt látnának.

6. lépés: Javítsa a 404-et adó API-útvonalakat

Ha az oldal betöltődik, de a Hálózat fülön a /api/... kérések 404-et adnak:

• A back end nincs telepítve. Egy statikus host csak fájlokat szolgál ki; a back endnek valahol futnia kell.
• Az útvonal élesben másképp van irányítva. Fejlesztés közben egy proxy átirányíthatta az /api-t egy külön szerverre. Élesben a hostnak ekvivalens rewrite-ra van szüksége, vagy a front endnek az API valódi címét kell hívnia.
• Az SPA-fallback elkapta. Ha egy API-kérés 200 státusszal index.html-t ad vissza, a fallback-szabály túl széles. Zárja ki belőle a /api/* útvonalakat.

A közzétett app /api/orders kérései 404-et adnak, de az előnézetben működnek. Ellenőrizze, hogyan van az /api útvonalazva az előnézetben és a közzétett appban, és állítsa be, hogy a közzétett front end ugyanúgy érje el a back endet.

7. lépés: Irányítsa át a régi URL-eket

Ha másik webhelyről költözött, vagy átszervezte az URL-eket, a régi címek, amelyeket az emberek és a keresőmotorok még használnak, 404-et adnak. Adjon hozzá egy 301 (állandó) átirányítást minden régi URL-ből az új helyére. Vezessen listát, és indítás után mintavétellel teszteljen. A WordPress-oldal költöztetéséről szóló útmutatóban a lista összeállítását is leírjuk.

8. lépés: Ellenőrizze a domaint

Ha az app a host címén működik, de az egyéni domainen 404-et ad, lehet, hogy a domain rossz projektre mutat, vagy a host még nem csatolta a domaint a webhelyéhez. Ellenőrizze a DNS-rekordokat és a host domainbeállításait. Lásd: hogyan csatlakoztasson egyéni domaint.

Tegye hasznossá a valódi 404-es oldalát

Néhány 404 helyes: valaki elgépelte az URL-t. Tegye hasznossá ezt az oldalt:

• Rövid üzenet és linkek a főoldalra és a fontos szakaszokra
• Keresőmező, ha van keresés az oldalon
• Ugyanaz a fejléc és navigáció, mint a webhely többi részén

Ahol a beállítás engedi, adjon valódi 404-es státuszt a nem létező oldalakhoz. A 200 státusszal visszaadott „nem található” üzenetet a keresőmotorok soft 404-nek hívják, és pazarolhatja a feltérképezési idejüket, valamint összezavarhatja az indexelést.

Gyakori hibák

• Csak kattintással tesztelni. Mindig úgy teszteljen, hogy mély URL-eket illeszt be egy új lapra, és frissít.
• Mindent elkapó fallback. Az eszközök és az API-útvonalak index.html-t adnak, ami üres oldalakat és zavaros API-hibákat okoz.
• Eltérő kis- és nagybetűk, amelyek csak a szerveren törnek el.
• A forrásmappa telepítése a build kimenete helyett.
• URL-ek átszervezése átirányítások nélkül. Minden régi link 404 lesz.

404-ek a Mythexben

A Mythexben a munkaterületről publikál, és a statikus front endek statikus webhelyként települnek. Ha egy közzétett oldal 404-et ad, adja meg az ügynöknek a pontos URL-t, hogy frissítéskor vagy kattintáskor történik-e, és mit mutat a Hálózat fül, és kérje meg, hogy ellenőrizze az útválasztást. A javítás után publikáljon újra, mert az élő app pillanatkép, amíg újra nem publikál. Ha nemrég változtatott a projekten, és az élő oldal réginek tűnik, publikáljon újra és frissítsen erőteljesen. Ha a build hibázik, a közzétételi párbeszédablakban használja a Javítás AI-val gombot. Lásd: Hogyan publikáljon és Publikálási hibaelhárítás a dokumentációban, valamint az AI-val épített app hibakeresése útmutatónk.

404-ellenőrzőlista

• Pontosan feljegyezte, mely URL-ek adnak 404-et, és kattintásnál, frissítésnél vagy mindkettőnél
• Az SPA-fallback az app útvonalaira 200 státusszal az index.html-t adja
• A fallback kizárja a valódi fájlokat és a /api/* útvonalakat
• A routernek van catch-all „nem található” útvonala
• A build kimeneti mappája az, ami közzé van téve, és a build sikeres volt
• A base path egyezik azzal a címmel, ahol az app fut
• A fájlnevek kis- és nagybetűs írásmódja minden hivatkozásban egyezik
• Az eszköz-útvonalak /-rel kezdődnek
• A záró perjel-stílus következetes
• Az API-útvonalak telepítve és élesben útvonalazva vannak
• 301-es átirányítások a régi URL-ekhez
• A mély linkek tesztelve, beillesztve egy új lapra

Kérdések