Website သို့မဟုတ် app ကို deploy လုပ်ပြီးနောက် 404 error များ ပြင်နည်း

Local တွင် အလုပ်လုပ်သော်လည်း deploy ပြီးနောက် စာမျက်နှာများ 404 ပြနေလျှင် အဖြစ်အများဆုံး အကြောင်းမှာ single-page app (SPA) routing မပြည့်စုံခြင်း ဖြစ်သည်: server က /dashboard ဆိုသော ဖိုင်ကို ရှာသော်လည်း ထိုဖိုင် မရှိပါ၊ အကြောင်းမှာ ထို route သည် JavaScript ထဲတွင်သာ ရှိသောကြောင့် ဖြစ်သည်။ ပြင်နည်းမှာ app route များအတွက် index.html ကို ပြသသော fallback စည်းမျဉ်း ဖြစ်သည်။ အခြား အကြောင်းများမှာ build output တွင် ဖိုင်ပျောက်ခြင်း၊ case-sensitive path များ၊ trailing slash ကွာခြားမှု၊ base path မှား၊ နှင့် API route များ deploy မလုပ်ခဲ့ခြင်း တို့ ဖြစ်သည်။

ဘယ် URL က 404 ပြနေသလဲ၊ ဘယ်လို ရောက်လာသလဲ ဦးစွာ မှတ်ထားပါ။ ပုံစံက အကြောင်းရင်းကို တိုက်ရိုက် ညွှန်ပြသည်။

အဆင့် ၁: ပုံစံကို ရှာပါ

တကယ့် status code ကို မြင်ရန် developer tools (right-click → Inspect) ဖွင့်ပြီး Network tab သို့သွား၊ reload လုပ်ပြီး ပထမ request ၏ status ကို ကြည့်ပါ။

အဆင့် ၂: SPA fallback ထည့်ပါ

ဤမှာ ဂန္တဝင် ပြဿနာ ဖြစ်သည်။ React၊ Vue သို့မဟုတ် Svelte single-page app တွင် server မှာ တကယ့်ဖိုင် အနည်းငယ်သာ ရှိသည်: index.html နှင့် JavaScript နှင့် CSS အချို့။ /dashboard သို့မဟုတ် /projects/42 ကဲ့သို့ route များကို browser ထဲရှိ router က ကိုင်တွယ်သည်။

• link ကို နှိပ်လျှင် အလုပ်လုပ်သည်: router က URL ကို ပြောင်းပြီး server ကို မမေးဘဲ စာမျက်နှာအသစ်ကို ဆွဲသည်။
• Refresh သို့မဟုတ် link ကို တိုက်ရိုက်ဖွင့်လျှင် မအောင်မြင်: browser က server ထံ /dashboard တောင်းသည်၊ server တွင် ထိုဖိုင် မရှိ၊ 404 ပြန်သည်။

ပြင်နည်းမှာ စည်းမျဉ်းတစ်ခု ဖြစ်သည်: request က တကယ့် ဖိုင်နှင့် မကိုက်ညီလျှင် index.html ကို status 200 ဖြင့် ပြပြီး router ကို လွှဲပေးပါ။ ထည့်ရန်နည်းသည် host ပေါ် မူတည်သည် (အသေးစိတ်များ ပြောင်းလဲနိုင်သဖြင့် host ၏ လက်ရှိ docs ကို စစ်ဆေးပါ):

fallback က တကယ့် ဖိုင်များကို မဖုံးအုပ်စေရန် သေချာပါစေ: /assets/app.js တောင်းဆိုမှုများသည် JavaScript ဖိုင်ကို ဆက်ပြန်ရမည်။ ၎င်းတို့က index.html ပြန်လာလျှင် "Failed to load module script" error ပါသော blank page ဖြစ်မည်။ blank white page ပြင်နည်း ကို ကြည့်ပါ။

ထို့အပြင် router တွင် catch-all route ထည့်ပါ၊ မည်သည့် စာမျက်နှာနှင့်မှ မကိုက်ညီသော URL များက ဗလာမဟုတ်ဘဲ ရင်းနှီးသော "Page not found" ပြစေရန်။

Server setting ကို မပြောင်းနိုင်လျှင် hash routing (URL များ /#/dashboard ပုံစံ) က ပြဿနာကို ရှောင်ပေးသည်၊ အကြောင်းမှာ # နောက်ပိုင်းကို server သို့ ဘယ်တော့မှ မပို့ပါ။ ၎င်းသည် ပထမရွေးချယ်မှု မဟုတ်ဘဲ ကျော်လွှားနည်းတစ်ခုသာ ဖြစ်သည်: URL များ ကြည့်ရဆိုးပြီး search engine အတွက် ပိုမသင့်တော်ပါ။

Server ဘက်တွင် စာမျက်နှာများ ပြုလုပ်သော သို့မဟုတ် build အချိန်တွင် generate လုပ်သော framework များ (Next.js၊ Astro နှင့် ဆင်တူသည်များ) တွင် စာမျက်နှာတစ်ခုချင်းစီအတွက် တကယ့် ဖိုင်များ သို့မဟုတ် server route များ ရှိတတ်သဖြင့် ဤပြဿနာ နည်းပါးသည်။ ၎င်းတို့၏ အတူတူ အရာမှာ build အချိန်တွင် generate မလုပ်ခဲ့သော စာမျက်နှာ ဖြစ်သည်။

အဆင့် ၃: တကယ် deploy ဖြစ်သည်ကို စစ်ပါ

အားလုံး 404 ဖြစ်လျှင် server က build ထားသော app ကို ပြသနေခြင်း မဟုတ်ပါ။

• မှန်ကန်သော folder။ host က build output ကို (များသောအားဖြင့် Vite အတွက် dist၊ Create React App အတွက် build၊ static Next.js export အတွက် out) publish လုပ်ရမည်၊ project root ကို မဟုတ်ပါ။
• Build အလုပ်လုပ်ခဲ့သည်။ deploy log ကို ဖတ်ပါ။ build ပျက်ခဲ့လျှင် host က ဘာမျှ deploy မလုပ်ခဲ့ခြင်း သို့မဟုတ် ဟောင်းဗားရှင်းကို ပြနိုင်သည်။
• index.html သည် published folder ၏ top level တွင် ရှိရမည်၊ sub-folder တွင် မဟုတ်ပါ။
• Base path ကိုက်ညီသည်။ app ကို example.com/app/ မှ ပြသပါက ထို base ဖြင့် build လုပ်ရမည် (Vite ၏ base၊ React Router ၏ basename)၊ မဟုတ်ပါက route နှင့် asset အားလုံး ပျောက်မည်။

အဆင့် ၄: ပျောက်နေသော ဖိုင်များနှင့် မှားသော path များကို ပြင်ပါ

စာမျက်နှာများ load ဖြစ်သော်လည်း asset များ 404 ဖြစ်လျှင်:

• Case sensitivity။ macOS နှင့် Windows တွင် Logo.png နှင့် logo.png ကို ပုံမှန်အားဖြင့် တူညီသောဖိုင်အဖြစ် သတ်မှတ်သည်။ Linux server အများစုက မသတ်မှတ်ပါ။ reference တိုင်းကို ဖိုင်အမည်အတိအကျနှင့် ကိုက်ညီအောင် ပြုလုပ်ပါ။
• Build ပြင်ပ ဖိုင်များ။ Vite တွင် public/ ထဲ ဖိုင်များကို အတိုင်း ကော်ပီကူးပြီး root မှ ရည်ညွှန်းသည် (/logo.png)။ code တွင် import လုပ်သော ဖိုင်များကို bundle လုပ်သည်။ project ထဲ အခြားနေရာရှိ ဖိုင်သည် deploy မလုပ်ခဲ့နိုင်ပါ။
• Relative path များ။ images/photo.jpg ကို လက်ရှိ URL နှင့် ဆက်စပ်ပြီး ဖြေရှင်းသဖြင့် /blog/post-1 တွင် ပျက်သည်။ /images/photo.jpg ကို သုံးပါ။
• Local disk သို့ သိမ်းထားသော upload ဖိုင်များ။ အသုံးပြုသူ upload များကို server ၏ folder ထဲ ရေးထားလျှင် version အသစ် deploy လုပ်သောအခါ ပျောက်သွားသည်။ သင့်တော်သော file storage သုံးပါ။

အဆင့် ၅: trailing slash များကို တသမတ်တည်း ကိုင်တွယ်ပါ

/about နှင့် /about/ သည် URL နှစ်ခု ဖြစ်သည်။ host များသည် slash ထည့်ခြင်း သို့မဟုတ် ဖယ်ခြင်းတွင် ကွာခြားပြီး သင့် link များ သို့မဟုတ် router နှင့် မကိုက်ညီလျှင် 404 သို့မဟုတ် redirect loop ဖြစ်နိုင်သည်။ style တစ်ခုကို ရွေး၊ သင့် link များကို ထိုပုံစံ သုံးစေပြီး host ကို အခြားပုံစံကို ထိုတစ်ခုသို့ redirect လုပ်ရန် configure လုပ်ပါ။ တသမတ်တည်းဖြစ်မှုသည် search engine များကိုလည်း ကူညီသည်၊ မဟုတ်ပါက စာမျက်နှာတစ်ခုစီကို နှစ်ခုအဖြစ် တွေ့နိုင်သည်။

အဆင့် ၆: 404 ဖြစ်သော API route များကို ပြင်ပါ

စာမျက်နှာ load ဖြစ်သော်လည်း Network tab တွင် /api/... request များ 404 ပြနေလျှင်:

• Back end deploy မလုပ်ခဲ့ပါ။ static host က ဖိုင်များကိုသာ ပြသသည်; back end သည် တစ်နေရာတွင် run ရမည်။
• Production တွင် path ကို မတူစွာ routing လုပ်ထားသည်။ Development တွင် proxy က /api ကို အခြား server သို့ ပို့ထားနိုင်သည်။ Production တွင် host တွင် ညီမျှသော rewrite လိုအပ်သည်၊ သို့မဟုတ် frontend သည် API ၏ တကယ့် လိပ်စာကို ခေါ်ရမည်။
• SPA fallback က ဖမ်းမိခဲ့သည်။ API request က status 200 ဖြင့် index.html ပြန်လာခြင်းသည် fallback စည်းမျဉ်း ကျယ်လွန်းကြောင်း ဆိုလိုသည်။ /api/* ကို ၎င်းမှ ဖယ်ထားပါ။

Published app ၏ /api/orders တောင်းဆိုမှုများ 404 ပြနေသည်၊ သို့သော် preview တွင် အလုပ်လုပ်သည်။ preview နှင့် published app တွင် /api ကို ဘယ်လို routing လုပ်ထားသလဲ စစ်ဆေးပြီး published frontend က backend ကို တူညီသောနည်းဖြင့် ရောက်အောင် ပြင်ပါ။

အဆင့် ၇: ဟောင်း URL များကို redirect လုပ်ပါ

အခြား site မှ ပြောင်းလာခြင်း သို့မဟုတ် ဖွဲ့စည်းပုံပြင်ခြင်း ရှိလျှင် လူများနှင့် search engine များ အသုံးပြုဆဲ ဟောင်း URL များသည် 404 ဖြစ်မည်။ ဟောင်း URL တစ်ခုစီမှ အသစ်သို့ 301 (permanent) redirect ထည့်ပါ။ စာရင်းတစ်ခု ထားပြီး launch ပြီးနောက် နမူနာအချို့ စမ်းပါ။ WordPress site ရွှေ့နည်း တွင် ထိုစာရင်း ဆောက်ပုံကို ရှင်းပြထားသည်။

အဆင့် ၈: domain ကို စစ်ပါ

Host ၏ လိပ်စာတွင် app အလုပ်လုပ်သော်လည်း custom domain တွင် 404 ဖြစ်လျှင် domain က မှားသော project ကို ညွှန်နေနိုင်သည်၊ သို့မဟုတ် host တွင် site ကို domain ချိတ်ဆက်ခြင်း မရှိသေးနိုင်ပါ။ DNS record များနှင့် host ၏ domain setting များကို စစ်ဆေးပါ။ custom domain ချိတ်ဆက်နည်း ကို ကြည့်ပါ။

သင့် 404 စာမျက်နှာကို အသုံးဝင်အောင် လုပ်ပါ

အချို့ 404 များသည် မှန်ကန်ပါသည်: တစ်စုံတစ်ဦးက URL ကို မှားရိုက်ခဲ့သည်။ ထိုစာမျက်နှာကို အကူအညီဖြစ်စေပါ:

• တိုတောင်းသော မက်ဆေ့ချ်နှင့် home page နှင့် အဓိက အပိုင်းများသို့ link
• Site တွင် search ရှိလျှင် search box
• Site ၏ အခြားစာမျက်နှာများနှင့် တူညီသော header နှင့် navigation

သင့် setup ခွင့်ပြုသည့်နေရာတွင် မရှိသော စာမျက်နှာများအတွက် တကယ့် 404 status ပြန်ပါ။ status 200 ဖြင့် "not found" မက်ဆေ့ချ်ပြန်ခြင်းကို search engine များက soft 404 ဟု ခေါ်ပြီး crawl အချိန်ကို ဖြုန်းစေကာ indexing ကို ရှုပ်ထွေးစေနိုင်သည်။

အဖြစ်များသော အမှားများ

• Click ဖြင့်သာ စမ်းခြင်း။ အမြဲတမ်း deep URL များကို tab အသစ်တွင် ကူးထည့်ပြီး refresh လုပ်ပြီး စမ်းပါ။
• အရာအားလုံးကို ဖမ်းသော fallback။ Asset နှင့် API route များက index.html ပြန်ခြင်းသည် blank page နှင့် ရှုပ်ထွေးသော API error များ ဖြစ်စေသည်။
• Server တွင်သာ ပျက်သော အကြီးအသေး ကွာခြားမှု။
• Source folder ကို deploy လုပ်ခြင်း build output အစား။
• Redirect မရှိဘဲ URL များ ပြန်ဖွဲ့စည်းခြင်း။ ဟောင်း link တိုင်း 404 ဖြစ်သွားသည်။

Mythex တွင် 404 များ

Mythex တွင် workspace မှ publish လုပ်ပြီး static front end များကို static site အဖြစ် deploy လုပ်သည်။ published စာမျက်နှာ 404 ဖြစ်လျှင် agent ကို တိကျသော URL၊ refresh တွင် သို့မဟုတ် click တွင် ဖြစ်သလား၊ နှင့် Network tab ပြသသည်များကို ပေးပြီး routing ကို စစ်ဆေးခိုင်းပါ။ ပြင်ပြီးနောက် ထပ် publish လုပ်ပါ၊ အကြောင်းမှာ live app သည် ထပ် publish မလုပ်မချင်း snapshot ဖြစ်သည်။ မကြာသေးမီက project ကို ပြောင်းပြီး live site ဟောင်းနေလျှင် ထပ် publish လုပ်ပြီး hard-refresh လုပ်ပါ။ build ပျက်လျှင် publish dialog ရှိ Fix with AI ကို သုံးပါ။ docs ရှိ app ကို publish လုပ်နည်း နှင့် Publish troubleshooting ကို ကြည့်ပါ၊ ထို့အပြင် AI-built app ကို debug လုပ်နည်း လမ်းညွှန်ကိုလည်း ကြည့်ပါ။

404 checklist

• ဘယ် URL တွေ 404 ဖြစ်သလဲ၊ click၊ refresh သို့မဟုတ် နှစ်ခုလုံးလား မှတ်ထားပြီး
• SPA fallback က app route များအတွက် index.html ကို status 200 ဖြင့် ပြသသည်
• Fallback က တကယ့် ဖိုင်များနှင့် /api/* ကို ဖယ်ထားသည်
• Router တွင် catch-all "not found" route ရှိသည်
• Build output folder ကို publish လုပ်ပြီး build အောင်မြင်ခဲ့သည်
• Base path သည် app ကို ပြသသော နေရာနှင့် ကိုက်ညီသည်
• ဖိုင်အမည် အကြီးအသေးသည် reference တိုင်းနှင့် ကိုက်ညီသည်
• Asset path များသည် / ဖြင့် စသည်
• Trailing-slash ပုံစံ တသမတ်တည်း
• API route များ production တွင် deploy နှင့် routing လုပ်ပြီး
• ဟောင်း URL များအတွက် 301 redirect များ
• Deep link များကို tab အသစ်တွင် ကူးထည့်ပြီး စမ်းပြီး

မေးခွန်းများ