Cloudflare Free vs Web Hosting: Apakah Fungsi Setiap…

Dua perkhidmatan dalam satu laluan permintaan

Penyedia hosting web menyimpan fail laman atau menjalankan aplikasi yang menghasilkan halaman. Perkhidmatan DNS dan proksi songsang Cloudflare yang biasa boleh berada di antara pelawat dengan pelayan asal, menyelesaikan nama domain, mengendalikan permintaan web yang sesuai serta menggunakan cache dan kawalan keselamatan tertentu. Peranan ini berbeza. Mengaktifkan pelan Free Cloudflare tidak memindahkan pangkalan data WordPress, memuat naik fail ke hos baharu atau mengambil alih penyelenggaraan pelayan. Pelanggan boleh menggunakan kedua-duanya bersama atau memilih seni bina lain. Soalan pertama ialah tempat laman sebenar dijalankan, diikuti lapisan rangkaian yang menerima permintaan pelawat.

Kenali pelayan asal sebelum membuat perubahan

Pelayan asal ialah sistem yang membekalkan kandungan apabila Cloudflare tidak dapat menjawab daripada cache atau perkhidmatan lain yang dikonfigurasi. Ia mungkin akaun hosting berkongsi, VPS, platform terurus atau titik capaian aplikasi. Catat nama hos asal, alamat IP jika berkaitan, penyedia hosting, jenis aplikasi dan pentadbir sebelum mengubah DNS. Rekod berproksi boleh menyebabkan pelawat melihat alamat Cloudflare dan bukan alamat asal, tetapi itu tidak bermaksud pelayan asal telah hilang. Jika pelayan aplikasi gagal, halaman dinamik yang tidak berada dalam cache mungkin turut gagal. Melindungi laluan ke pelayan tidak sama dengan menyediakan pelayan pendua.

DNS bukan hosting laman web

DNS berautoriti menjawab pertanyaan tentang destinasi sesuatu nama hos. Hosting web menjawab permintaan HTTP dengan menghantar halaman atau menjalankan kod. Cloudflare boleh menjadi penyedia DNS tanpa memproksikan nama hos tertentu; dalam keadaan DNS-only, rekod menunjukkan destinasi dan pelawat menyambung terus ke sana. Rekod DNS tidak boleh membaiki fail laman yang hilang, pangkalan data rosak atau langganan hosting yang tamat. Simpan inventori yang membezakan pendaftar domain, penyedia DNS, hos web dan penyedia e-mel. Langkah ini mengelakkan salah faham bahawa pertukaran pelayan nama turut memindahkan semua perkhidmatan yang menggunakan domain tersebut.

Maksud awan jingga dan kelabu

Dokumentasi Cloudflare menyatakan bahawa rekod A, AAAA dan CNAME yang sesuai boleh diproksikan. Status awan jingga mengarahkan trafik HTTP atau HTTPS yang disokong melalui Cloudflare, manakala DNS-only berwarna kelabu memulangkan destinasi sebenar tanpa laluan proksi. Rekod MX dan TXT tidak diproksikan. Kawalan ini digunakan mengikut nama hos berkaitan, jadi rekod laman dan rekod mel tidak boleh dianggap sama. Awan jingga bukan jaminan hasil keselamatan, kejayaan cache atau kelajuan halaman tertentu. Semak rekod yang melayani web, keserasian aplikasi dengan proksi dan destinasi yang patut diselesaikan sebelum menukar tetapan.

Mengapa e-mel memerlukan semakan DNS sendiri

E-mel perniagaan lazimnya menggunakan rekod MX untuk menentukan destinasi mesej masuk serta nama hos bagi sambungan SMTP, IMAP atau POP3. Proksi HTTP biasa Cloudflare tidak membawa protokol mel tersebut. Panduan penyelesaian masalah rasminya memberi amaran bahawa nama hos mel yang menghala ke alamat proksi Cloudflare boleh menyebabkan aplikasi e-mel gagal bersambung. Kekalkan nama hos mel khusus sebagai DNS-only dan semak destinasi MX tepat dengan arahan penyedia mel. Pelihara rekod SPF, DKIM dan DMARC jika digunakan; pertukaran DNS berautoriti tanpa menyalin rekod ini boleh mengganggu pengesahan atau penghantaran. Cloudflare Email Routing ialah ciri berasingan dan tidak patut diaktifkan tanpa sengaja.

Cache percuma mempunyai sempadan tertentu

Rangkaian penghantaran kandungan boleh mengurangkan permintaan berulang kepada pelayan asal dengan menghantar fail yang layak daripada lokasi rangkaian berdekatan. Dokumentasi cache semasa Cloudflare menyenaraikan aset statik seperti imej, CSS dan JavaScript sebagai kandungan yang biasanya boleh dicache, tertakluk pada pengepala respons serta peraturan lain. HTML dan JSON tidak dicache secara lalai dalam tingkah laku standardnya. Pelawat yang meminta halaman tidak dicache masih perlu menunggu aplikasi dan pangkalan data asal. Anggap cache sebagai pengoptimuman yang perlu diukur, bukan pengganti kapasiti hosting. Kenal pasti laluan awam yang sesuai dicache dan laluan yang mengandungi maklumat peribadi atau sentiasa berubah.

Elakkan cache halaman pelanggan peribadi

Kedai dalam talian, sistem tempahan atau laman keahlian mungkin menghasilkan kandungan berbeza bagi setiap pengguna yang log masuk. Peraturan cache-everything yang terlalu luas tanpa memahami kuki, pengesahan dan kunci cache boleh menyebabkan kandungan lapuk atau perkongsian tidak wajar. Semakan selamat membezakan maklumat produk awam daripada troli, papan pemuka akaun, pembayaran dan halaman pentadbiran. Periksa tingkah laku Cache-Control serta Set-Cookie pada pelayan asal sebelum menambah peraturan, kemudian uji sesi pengguna berdaftar dan pelawat biasa secara berasingan. Halaman brosur statik dan halaman akaun peribadi tidak patut menggunakan dasar sama hanya kerana kedua-duanya memakai HTTPS. Sediakan cara membersihkan cache selepas penerbitan perubahan.

HTTPS mempunyai dua sambungan berasingan

Apabila nama hos diproksikan, pelayar menyambung ke Cloudflare dan Cloudflare pula menyambung ke pelayan asal. Ini dua sambungan pengangkutan yang berasingan. Dokumentasi SSL/TLS Cloudflare menerangkan mod penyulitan serta mengesyorkan Full atau Full (strict) jika sesuai. Full (strict) mengesahkan sijil pelayan asal, manakala Full biasa tidak membuat pengesahan yang sama. Pelayan asal tetap memerlukan konfigurasi HTTPS serta sijil yang memenuhi mod dipilih. Simbol mangga pada pelayar sahaja tidak membuktikan sambungan ke pelayan asal disahkan dengan betul. Rancang pembaharuan sijil, liputan nama hos dan pengalihan URL bersama pentadbir hosting sebelum mengubah tetapan penyulitan.

CDN tidak membaiki aplikasi yang rosak

Cloudflare mungkin menyimpan aset dalam cache dan menyediakan kawalan rangkaian, tetapi ia tidak secara automatik membaiki pemalam rosak, sambungan pangkalan data yang kehabisan kapasiti, kod aplikasi salah atau fail terpadam pada pelayan asal. Mesej ralat juga boleh datang daripada lapisan berlainan. Kegagalan DNS, masalah rundingan TLS, tamat masa pelayan asal dan pengecualian aplikasi memerlukan siasatan berbeza. Apabila laman gagal, rekod URL, masa, status respons, sama ada permintaan diproksikan dan bukti log asal jika tersedia. Elakkan menukar beberapa tetapan DNS serta keselamatan serentak kerana punca menjadi sukar dikenal pasti. Pelan insiden yang boleh digunakan perlu menamakan pegawai bagi setiap lapisan.

Had proksi dan perkhidmatan yang tidak disokong

Proksi songsang Cloudflare yang biasa direka untuk trafik web dan port yang disokong, bukan semua protokol internet. Dokumentasi rasmi port rangkaian menyenaraikan port HTTP dan HTTPS yang dikendalikan secara lalai, dengan syarat cache berbeza bagi sesetengah port. Pentadbiran jauh, sambungan pangkalan data dan e-mel tidak boleh diandaikan berfungsi melalui proksi awan jingga. Permintaan berproksi juga tertakluk pada had saiz dan tamat masa yang bergantung pada produk serta pelan. Muat naik fail besar atau respons aplikasi perlahan mungkin memerlukan perubahan reka bentuk atau laluan lain. Sahkan had terkini untuk perkhidmatan sebenar, bukan bergantung pada tutorial lama.

Kawalan keselamatan bukan jaminan keselamatan

Cloudflare menawarkan kawalan perlindungan tertentu di pinggir rangkaian, tetapi ketersediaan dan kedalaman cirinya bergantung pada pelan serta konfigurasi semasa. Peraturan tembok api boleh mengurangkan sesetengah permintaan tidak diingini namun tidak menjamin pemalam yang lemah, kata laluan pentadbir yang mudah atau pelayan asal terdedah menjadi selamat. Kemas kini aplikasi dan pelayan, gunakan pengesahan sesuai, hadkan akses pentadbiran serta uji sandaran. Semak peristiwa keselamatan bagi mengenal pasti sekatan salah terhadap pelanggan sebenar. Papan pemuka penyedia ialah satu sumber bukti, bukan bukti audit keselamatan bebas telah selesai. Jangan gambarkan pelan Free sebagai menjadikan laman kebal.

Cloudflare Pages ialah produk berbeza

Ada pengecualian penting kepada kenyataan bahawa Cloudflare tidak pernah mengehos laman. Cloudflare Pages boleh menerbitkan aset laman statik, manakala Pages Functions menyediakan fungsi sisi pelayan tertentu; Cloudflare juga mengarahkan projek aplikasi baharu ke arah Workers. Produk ini tidak sama dengan sekadar meletakkan laman cPanel sedia ada di belakang DNS dan proksi Free. Aplikasi PHP yang bergantung pada pangkalan data serta sistem fail tradisional tidak bertukar menjadi projek Pages secara automatik apabila pelayan nama diubah. Nilai keserasian aplikasi, aliran penerbitan, keperluan storan dan syarat penyedia secara berasingan sebelum mempertimbangkan migrasi platform. Keupayaan produk bukan bukti perkhidmatan sudah diaktifkan.

Sediakan pertukaran pelayan nama dengan teliti

Bagi konfigurasi DNS penuh Cloudflare Free yang lazim, pelayan nama berautoriti domain diubah pada pendaftar selepas rekod zon disemak. Panduan rasmi Cloudflare memberi amaran bahawa delegasi DNSSEC sedia ada perlu dikendalikan dengan betul; rekod DS lama boleh menyebabkan domain tidak dapat dicapai. Sebelum menukar pelayan nama, eksport atau rekod A, AAAA, CNAME, MX, TXT dan rekod perkhidmatan berkaitan. Kenal pasti rekod pengesahan pihak ketiga serta subdomain yang didelegasikan. Rancang waktu perubahan yang boleh diundur, sahkan pemegang akses pendaftar dan ketahui cara menyemak delegasi selepas itu. Migrasi DNS ialah urusan kesinambungan perniagaan, bukan sekadar pilihan rupa papan pemuka.

Laman SaaS memerlukan semakan mengikut penyedia

Sesetengah pembina laman sudah mempunyai sistem penghantaran dan sijil mereka sendiri. Panduan kes penggunaan proksi DNS Cloudflare memberi amaran bahawa memproksikan nama hos yang menghala ke platform SaaS tertentu boleh menyebabkan konflik sijil, gelung pengalihan atau permintaan ditolak melainkan platform menyokong susunan tersebut. Jika perniagaan menggunakan pembina laman terurus, ikut konfigurasi DNS yang diwajibkan penyedia itu dan bukan arahan awan jingga secara umum. Kekalkan rekod CNAME pengesahan sebagai DNS-only apabila perkhidmatan memerlukan resolusi terus ke sasaran. Kejayaan pertanyaan DNS sahaja tidak membuktikan pembina laman telah menerima domain tersuai atau mengeluarkan sijil betul.

Ukur kelajuan, jangan membuat andaian

Imej yang berada dalam cache mungkin dihantar lebih cepat daripada lokasi pinggir rangkaian, tetapi pengalaman keseluruhan turut bergantung pada respons pelayan asal, saiz halaman, pelaksanaan JavaScript, skrip pihak ketiga dan peranti pelawat. Bandingkan ukuran masa muat dan respons pelayan sebelum serta selepas perubahan konfigurasi yang diluluskan dalam keadaan serupa. Semak sama ada aset statik mendapat cache hit, sama ada HTML masih mencapai pelayan asal dan sama ada laluan pengguna berdaftar berfungsi. Jika prestasi lemah, pemampatan imej, pengurangan sumber yang menghalang paparan dan pengoptimuman aplikasi mungkin lebih membantu daripada tetapan proksi DNS. Jangan janjikan peningkatan kedudukan carian atau masa muat tertentu.

Contoh kedai dengan e-mel sedia ada

Bayangkan sebuah kedai Malaysia yang laman web dan e-melnya menggunakan domain sama tetapi penyedia berbeza. Laman berjalan pada hosting berkongsi, manakala pekerja membaca mel melalui perkhidmatan e-mel perniagaan lain. Pemilik mahu Cloudflare untuk cache web dan kawalan keselamatan yang sesuai. Urutan perancangan selamat ialah mengenal pasti pelayan asal, memetakan semua rekod DNS, mengekalkan MX serta rekod pengesahan mel dan menyemak keserasian sijil. Proksikan hanya nama hos laman yang disokong; kekalkan nama hos mel sebagai DNS-only. Uji halaman web dan e-mel selepas sebarang pertukaran pelayan nama yang dibenarkan. Contoh ini menerangkan pembahagian tanggungjawab, bukan dakwaan bahawa konfigurasi pelanggan telah diubah.

Soalan sebelum memilih Free

Tanya ciri Cloudflare yang benar-benar termasuk dalam pelan Free semasa, had proksi serta cache, dan sama ada aplikasi memerlukan protokol atau port yang tidak disokong. Sahkan sijil pelayan asal, proses sandaran laman dan akses pentadbir. Ketahui siapa mengurus perubahan DNS, menyiasat sekatan keselamatan yang tersilap, membersihkan cache lapuk dan memperbaharui langganan hosting. Simpan rekod pembaharuan serta bil berasingan untuk domain, hos web dan perkhidmatan pilihan. Fungsi asas percuma mungkin berguna, tetapi ia tidak menghapuskan kos penyelenggaraan aplikasi atau mewujudkan perjanjian sokongan yang belum dibeli.

Selesaikan masalah mengikut lapisan dan simpan catatan undur

Jika laman gagal selepas perubahan DNS atau proksi, jangan terus menganggap pelayan hosting telah rosak. Tentukan dahulu sama ada pelayan nama berautoriti menjawab dengan betul, sama ada nama hos terjejas diproksikan dan sama ada pelayan asal menjawab melalui laluan diagnostik yang dibenarkan. Kemudian periksa ralat TLS, pengalihan URL, log aplikasi dan tingkah laku cache. Jika e-mel gagal, semak MX serta nama hos mel DNS-only secara berasingan. Catat setiap tetapan yang diubah bersama nilai terdahulu supaya pentadbir boleh mengundurkan konfigurasi salah. Jangan dedahkan kata laluan atau data pelanggan sulit dalam tangkap layar dan tiket sokongan. Perubahan produksi memerlukan pelan yang diluluskan secara berasingan.

Buat keputusan melalui peta perkhidmatan

Bagi laman perniagaan kecil sedia ada, lukis empat kotak: pendaftar, DNS berautoriti, pelayan asal web dan perkhidmatan e-mel. Letakkan proksi Cloudflare di antara pelawat dengan pelayan asal hanya bagi nama hos serta ciri yang sesuai. Nyatakan pihak pemilik setiap akaun, tetapan yang memerlukan kelulusan dan ujian yang membuktikan kejayaan. Jika keperluannya sekadar memastikan laman PHP berfungsi, hosting yang serasi masih diperlukan walaupun DNS domain menggunakan Cloudflare. Jika mahu mengehos laman statik baharu pada Pages atau Workers, nilai sebagai projek platform berasingan. Peta perkhidmatan yang jelas mengelakkan perbelanjaan berganda dan andaian yang berbahaya.

Laman web awan terurus dan CDN menyelesaikan masalah berbeza

Hosting awan terurus lazimnya menyediakan sumber aplikasi untuk permintaan PHP, pertanyaan pangkalan data dan tugasan belakang tabir. CDN boleh menyimpan aset awam yang sesuai lebih dekat kepada pengunjung dan menggunakan aturan rangkaian, tetapi tidak membaiki pangkalan data asal yang kehabisan sumber atau menjamin kejayaan pembayaran berlog masuk. Bandingkan had pekerja PHP, CPU, RAM dan dasar pangkalan data hosting dengan kesesakan aplikasi sebenar, kemudian nilai cache sebagai sokongan tambahan. Laporan pelajar, rekod HR dan respons pembayaran persendirian tidak patut dianggap selamat untuk cache awam.

Pelan tambahan memasukkan satu peruntukan domain layak dalam harga tahunan, tetapi tetap hosting web terurus dan bukannya VPS atau naik taraf storan e-mel automatik. Jika perniagaan menggunakan peti mel di platform lain, kekalkan rekod DNS e-mel ketika mengubah CDN atau hosting. Penyelenggaraan aplikasi dan kebenaran pengguna mesti dirancang secara berasingan daripada tanggungjawab rangkaian dan infrastruktur penyedia.

Sumber & bacaan lanjut

Jadikan panduan ini tindakan

E-mel & hosting Domain Reka bentuk web

Cloudflare Free vs Web Hosting: Apakah Fungsi Setiap Perkhidmatan?