កម្មវិធីភ្ញៀវរបស់អ្នករង់ចាំហុកសិបវិនាទី។ ដប់វិនាទីក្រោយមក វាទទួលបាន HTTP 504។ ការដំឡើង timeout នៃកម្មវិធីភ្ញៀវទៅពីរនាទីមិនផ្តល់ហាសិបវិនាទីបន្ថែមដល់ច្រកទ្វារទេ។

504 ពិពណ៌នាអំពីច្រកទ្វារ ឬ proxy ដែលមិនបានទទួលការឆ្លើយតបពី upstream ទាន់ពេល ពេលវាព្យាយាមបញ្ចប់សំណើ។ ច្រកទ្វារបានសម្រេចចិត្តរួចហើយ ហើយបានផ្ញើការឆ្លើយតបត្រឡប់មកវិញ។ កម្មវិធីភ្ញៀវរបស់អ្នកអាចអានការឆ្លើយតបនោះបានយ៉ាងរលូន។

តើអ្នកសម្របសម្រួលណាបានផ្ញើវាមកវិញ?

proxy ខាងមុខអាចជាអ្នកបញ្ចេញ។ ច្រកទ្វារក្រោយៗដែលគេហទំព័រដំណើរការក៏អាចជា។ ជាមួយ TLS ធម្មតាពីចុងដល់ចុងក្នុង CONNECT ការឆ្លើយតប HTTP ពីក្នុងការផ្លាស់ប្តូរគោលដៅដែលបានការពារនោះមិនដូចគ្នានឹង ការបដិសេធ CONNECT ខ្លួនឯង ទេ។

រក្សាទុកដំណាក់កាល ក្បាលការឆ្លើយតប ពាក្យនៅលើទំព័រកំហុស និងកំណត់ហេតុដែលត្រូវគ្នានៅពេលមាន។ ស្លាកម៉ាស៊ីនមេអាចជាតម្រុយ ប៉ុន្តែមិនគួរចាត់ទុកជាការកំណត់ដែលមិនខុសឡើយ។ ផ្លូវអាចមានអ្នកសម្របសម្រួលច្រើនជាងម្នាក់ដែលបានកំណត់ក្នុងកម្មវិធីភ្ញៀវរបស់អ្នក។

បន្ទាប់មក ពិនិត្យមើលហេតុអ្វីបានជាប្រតិបត្តិការ upstream នោះមិនបានបញ្ចប់។ ភាពអាចឈានដល់ សេវាដែលផ្ទុកលើស តួសំណើដែល upstream មិនអាចដំណើរការតាមការរំពឹង និងឥរិយាបថកម្មវិធី សុទ្ធតែអាចមានសារៈសំខាន់។ ស្ថានភាពជាលេខតែម្នាក់ឯងមិនបញ្ជាក់ថាការផ្លាស់ប្តូរ User-Agent ឬការបន្ថែមជម្រើស timeout មួយគឺជាដំណោះស្រាយសកលទេ។

ប្រៀបធៀបសំណើដូចគ្នា

នៅពេលឧបករណ៍ផ្សេងដំណើរការ សូមប្រៀបធៀបវិធីសាស្ត្រ គោលដៅ ការអ៊ិនកូដតួ ការផ្ទៀងផ្ទាត់ និងផ្លូវ។ «URL បើកនៅក្នុងកម្មវិធីរុករក» មិនមែនជាការប្រៀបធៀបពេញលេញជាមួយការដាក់ស្នើ multipart តាមកម្មវិធីភ្ញៀវសេវាទេ។

ប្រសិនបើអ្នកដំណើរការច្រកទ្វារដែលបញ្ចេញ សូមធ្វើឱ្យថវិកា upstream របស់វាស៊ីគ្នានឹងបន្ទុកការងារដែលគាំទ្រ និងកាលកំណត់ជុំវិញ។ ប្រសិនបើមិនដូច្នេះ សូមរក្សាលទ្ធផលរបស់វាជាភស្តុតាង ហើយប្រើផ្លូវចូលប្រើ ឬផ្លូវគាំទ្រដែលបានចងក្រងដោយប្រតិបត្តិករ។ ការរង់ចាំយូរជាងនៅមូលដ្ឋានមិនអាចផ្លាស់ប្តូរការឆ្លើយតបដែលមកដល់រួចហើយបានទេ។

អត្ថបទពាក់ព័ន្ធ