Deploy хийсний дараах 404 алдааг хэрхэн засах вэ

Хэрэв апп тань локалд ажилладаг ч deploy хийсний дараа хуудсууд 404 буцаавал хамгийн түгээмэл шалтгаан бол нэг хуудсан апп (SPA) routing дутуу байгаа явдал: сервер /dashboard гэх файлыг хайдаг ч тэр файл байдаггүй, учир нь тэр маршрут зөвхөн JavaScript дотор байдаг. Засвар нь аппын маршрутуудад index.html үйлчлэх fallback дүрэм юм. Бусад шалтгаан нь build гаралтаас дутсан файлууд, том жижиг үсэгтэй зам, trailing slash-ийн зөрүү, буруу base path, мөн хэзээ ч deploy хийгдээгүй API маршрутууд байна.

Эхлээд ямар URL 404 гарч байгааг, хаанаас хүрсэнийг тэмдэглэ. Хэв маяг нь шууд шалтгаан руу заадаг.

Алхам 1: Хэв маягийг ол

Жинхэнэ статус кодыг харахын тулд developer tools нээ (хулганы баруун товчоор → Inspect), Network таб руу ор, дахин ачаалуулаад эхний хүсэлтийн статусыг хар.

Алхам 2: SPA fallback нэм

Энэ бол сонгодог арга. React, Vue эсвэл Svelte нэг хуудсан аппд сервер зөвхөн цөөн жинхэнэ файлтай байдаг: index.html болон зарим JavaScript, CSS. /dashboard эсвэл /projects/42 гэх маршрутуудыг хөтөч дотрох router боловсруулдаг.

• Линк дарахад ажилладаг: router URL-ийг өөрчилж, сервертэй асуухгүйгээр шинэ хуудсыг зурдаг.
• Шинэчлэх эсвэл линкийг шууд нээхэд бүтэлгүйтдэг: хөтөч /dashboard-ийг серверээс асуух ба серверт тийм файл байхгүй тул 404 буцаана.

Засвар нь дүрэм юм: хүсэлт жинхэнэ файлтай таарахгүй бол 200 статустай index.html үйлчилж, router-т хяналтыг өгнө. Яаж нэмэх нь хостоос хамаарна (хостын одоогийн баримт бичгийг шалга, учир нь дэлгэрэнгүй нь өөрчлөгддөг):

Дүрэм жинхэнэ файлуудыг бүү залгиг: /assets/app.js хүсэлт JavaScript файлаа буцаах ёстой. Хэрэв index.html буцаавал “Failed to load module script” алдаатай хоосон хуудас гарна. Харна уу: цагаан хоосон хуудсыг хэрхэн засах вэ.

Мөн router-т catch-all маршрут өгөөрэй, ингэснээр ямар ч хуудсанд таарахгүй URL хоосон биш, харин “Хуудас олдсонгүй” гэсэн найрсаг мессеж харуулна.

Серверийн тохиргоог өөрчилж чадахгүй бол hash routing (/#/dashboard шиг URL) нь асуудлыг тойрдог, учир нь #-ийн дараах хэсэг серверт хэзээ ч очдоггүй. Энэ нь эхний сонголт биш, түр шийдэл: URL илүү муухай, хайлтын системд бага ээлтэй.

Серверт хуудсуудыг үүсгэдэг эсвэл build үед гаргадаг framework (Next.js, Astro болон төстэй) ихэвчлэн хуудас бүрт жинхэнэ файл эсвэл сервер маршрут байдаг тул энэ асуудал тэнд бага тохиолддог. Тэдгээрийн эквивалент нь build үед үүсэж амжаагүй хуудас байна.

Алхам 3: Юу үнэхээр deploy хийгдсэнийг шалга

Бүгд 404 болвол сервер таны build хийсэн аппыг үйлчлээгүй байх магадлалтай.

• Зөв хавтас. Хост нь build гаралтыг (Vite-д ихэвчлэн dist, Create React App-д build, статик Next.js export-д out) нийтлэх ёстой, төслийн үндсийг биш.
• Build ажилласан. Deploy лог уншаарай. Build бүтэлгүйтвэл хост юу ч deploy хийгээгүй эсвэл хуучин хувилбар үлдсэн байж болно.
• index.html нийтлэгдсэн хавтасны үндсэн түвшинд байх ёстой, дэд хавтаст биш.
• Base path таарч байна. Апп example.com/app/ дээр үйлчилж байвал тэр base-ээр build хийгдсэн байх ёстой (Vite-ийн base, React Router-ийн basename), эс бөгөөс маршрут бүр болон asset бүр алдана.

Алхам 4: Дутуу файл, буруу замыг засах

Хуудсууд ачаалдаг ч asset-ууд 404 болбол:

• Том жижиг үсэг. macOS болон Windows нь ихэвчлэн Logo.png ба logo.png-ийг нэг файл гэж үздэг. Ихэнх Linux сервер үздэггүй. Лавлагаа бүрийг жинхэнэ файлын нэртэй яг таарууулаарай.
• Build-ээс гадуур файлууд. Vite-д public/-д байгаа файлууд хуулагдаж, үндсээс (/logo.png) заагдана. Кодонд импорт хийсэн файлууд багцлагдана. Төслийн өөр газар байгаа файл огт deploy хийгдээгүй байж болно.
• Харьцангуй зам. images/photo.jpg нь одоогийн URL-д харьцуулан шийдэгддэг тул /blog/post-1 дээр эвдэрнэ. /images/photo.jpg ашигла.
• Локал дискэнд хадгалсан upload. Хэрэглэгчдийн upload серверийн өөрийн хавтаст бичигдсэн бол шинэ хувилбар deploy хийхэд алга болно. Зохих файлын хадгалалт ашигла.

Алхам 5: Trailing slash-ийг тогтвортой зохицуул

/about ба /about/ хоёр өөр URL. Хостууд slash нэмэх эсвэл хасах эсэхээр ялгаатай, мөн линк эсвэл router-тай зөрвөл 404 эсвэл redirect loop гарч болно. Нэг хэлбэр сонгож, линкүүдээ түүнтэй тааруул, хостыг нөгөө хэлбэрийг түүн рүү чиглүүлэхээр тохируул. Энэ нь хайлтын системд мөн тустай, эс бөгөөс хуудас бүрийн хоёр хуулбарыг харж магадгүй.

Алхам 6: 404 гардаг API маршрутуудыг засах

Хуудас ачаалдаг ч Network таб /api/... хүсэлтүүдэд 404 буцаавал:

• Backend deploy хийгдээгүй. Статик хост зөвхөн файл үйлчилдэг; backend хаа нэгтээ ажиллах ёстой.
• Замыг production дээр өөрөөр чиглүүлдэг. Хөгжүүлэлтэд proxy нь /api-г тусдаа серверт дамжуулж байсан байж болно. Production дээр хосттой тэнцэх rewrite хэрэгтэй, эсвэл front end нь API-гийн жинхэнэ хаягийг дуудах ёстой.
• SPA fallback түрүүлж барьсан. API хүсэлт index.html-ийг 200 статустайгаар буцаавал fallback дүрэм хэт өргөн байна. /api/*-г түүнээс хасаарай.

Нийтлэгдсэн аппын /api/orders хүсэлтүүд 404 буцааж байна, гэхдээ preview дээр ажиллаж байна. /api-г preview болон нийтлэгдсэн аппад хэрхэн чиглүүлж байгааг шалгаад, нийтлэгдсэн front end backend-д ижил аргаар хүрдэг болго.

Алхам 7: Хуучин URL-уудыг дахин чиглүүл

Хэрэв өөр сайтаас шилжсэн эсвэл бүтцээ өөрчилсөн бол хүмүүс болон хайлтын системүүд ашигласан хуучин URL-ууд 404 болно. Хуучин URL бүрээс шинэ байршил руу 301 (байнгын) redirect нэм. Жагсаалт хөтөл, хөөргөсний дараа дээжийг туршаарай. WordPress сайтыг шилжүүлэх гарын авлага энэ жагсаалтыг бүтээхэд тусална.

Алхам 8: Домэйнээ шалга

Хэрэв апп хостын хаяг дээр ажиллаж байгаа ч захиалгат домэйн дээр 404 гарвал домэйн буруу төсөл рүү заасан эсвэл хост тань уг домэйнийг сайтдаа хараахан холбоогүй байж болно. DNS бичлэг болон хостын домэйн тохиргоог шалга. Захиалгат домэйн хэрхэн холбох вэ харна уу.

Өөрийн жинхэнэ 404 хуудсыг тусламжтай болго

Зарим 404 зөв: хэн нэгэн URL-аа буруу бичсэн. Тэр хуудсыг тусламжтай болго:

• Богино мессеж ба нүүр хуудас болон гол хэсгүүдэд линк
• Сайтад хайлт байвал хайлтын талбар
• Бусад сайтын толгой хэсэг ба навигацитай адил

Тохиргоо зөвшөөрвөл байхгүй хуудсанд жинхэнэ 404 статус буцаа. 200 статустай “олдсонгүй” мессеж нь хайлтын системд зөөлөн 404 гэж нэрлэгддэг, энэ нь тэдний crawl хугацааг дэмий үрж индекслэлтийг төөрөгдүүлдэг.

Түгээмэл алдаа

• Зөвхөн дарж турших. Үргэлж гүн URL-ийг шинэ таб дээр буулгаж, шинэчлэн туршаарай.
• Бүгдийг барьдаг fallback. Asset болон API маршрут index.html буцааж, хоосон хуудас болон төөрөгдүүлсэн API алдаа үүсгэдэг.
• Зөвхөн сервер дээр бүтэлгүйтдэг том жижиг үсгийн зөрүү.
• Эх хавтсыг deploy хийх build гаралтын оронд.
• URL-ийг redirect-гүй өөрчлөх. Хуучин линк бүр 404 болно.

Mythex дэх 404

Mythex-д та workspace-аас нийтэлдэг, статик front end нь статик сайт болгон deploy хийгддэг. Нийтлэгдсэн хуудас 404 гарвал агентад яг URL-ийг, шинэчлэхэд эсвэл дарахад гарсан эсэхийг, Network табт юу харагдаж байгааг өгөөд маршрутыг шалгуулаарай. Засвараас хойш дахин нийтлээрэй, учир нь амьд апп нь та дахин нийтлэх хүртэл агшин зуурын хуулбар байдаг. Хэрэв саяхан төслөө өөрчилсөн бол амьд сайт хуучин харагдвал дахин нийтэлж, hard-refresh хий. Build бүтэлгүйтвэл нийтлэх цонхны Fix with AI ашигла. Харна уу: баримт бичгийн Нийтлэх болон Нийтлэх асуудлыг шийдэх, мөн AI-аар бүтээсэн аппыг дебаг хийх гарын авлага.

404 хяналтын жагсаалт

• Аль URL 404 гарч байгааг, линкээр, шинэчлэхээр, эсвэл хоёуланд нь гарч байгааг тэмдэглэсэн
• SPA fallback аппын маршрутуудад 200 статустай index.html буцаадаг
• Fallback жинхэнэ файлууд болон /api/*-г хасдаг
• Router-т “олдсонгүй” гэсэн catch-all маршрут байгаа
• Build гаралтын хавтас нийтлэгдэж байгаа, build амжилттай
• Base path нь аппыг үйлчлэх газартай таарч байна
• Файлын нэрийн том жижиг үсэг бүх лавлагаатай таарч байна
• Asset замууд /-ээр эхэлдэг
• Trailing slash-ийн хэв маяг тогтвортой
• API маршрутууд production дээр deploy хийгдсэн, зөв чиглүүлэгдсэн
• Хуучин URL-уудад 301 redirect байгаа
• Гүн линкүүд шинэ табд буулгаж туршигдсан

Асуултууд