SSD Nodes Learn Hosting plans →
Hướng dẫn Matt ConnorBởi Matt Connor · Cập nhật ngày 2026-11-06

Shared hosting hay VPS: Bạn nên chọn loại nào?

Chọn shared hosting nếu site chỉ có trang, ảnh và form. Chọn VPS khi cần root hoặc persistent service, nhưng bạn phải tự xử lý lỗi server lúc nửa đêm.

Shared hosting hay VPS: câu trả lời ngắn gọn

Shared hosting hay VPS không phải là câu hỏi về tốc độ. Với shared hosting, bạn thuê một account trên máy chủ do nhà cung cấp cấu hình, vá lỗi và dùng chung giữa nhiều khách hàng. Với VPS (virtual private server) không được quản lý, bạn thuê toàn bộ một hệ điều hành có quyền root. Bạn tự cài những gì cần dùng và cũng phải tự sửa những gì mình làm hỏng.

Có 3 điểm thực sự khác nhau. Bạn có quyền root hay không. Dung lượng memory và các cam kết dịch vụ phụ thuộc vào plan. Khi server ngừng phản hồi lúc nửa đêm, nhà cung cấp sẽ sửa hay bạn phải tự sửa. Mọi mục trên bảng so sánh tính năng đều bắt nguồn từ 3 điểm này.

Nếu site của bạn chỉ gồm các trang, hình ảnh và form liên hệ, shared hosting là lựa chọn phù hợp cho nhiều site. Nếu site cần một chương trình chạy liên tục ngay cả khi không có ai truy cập, hãy kiểm tra shared hosting có hỗ trợ persistent service hay không trước khi chọn VPS.

Shared hosting thực sự cung cấp gì

Một Linux server chạy đồng thời nhiều tài khoản khách hàng. Mỗi tài khoản có một thư mục home với document root, database và mailbox; một web server duy nhất, thường là Apache hoặc LiteSpeed, phục vụ tất cả website trên máy chủ. Bạn có control panel, và một số nhà cung cấp cũng cho phép dùng shell prompt. Bạn không có quyền root, nhưng một số nhà cung cấp cho phép cài software trong thư mục home, dùng các port được cho phép và chạy background service.

Nhiều shared host chạy CloudLinux. CloudLinux đặt mỗi tài khoản vào một container nhẹ riêng, đồng thời giới hạn thời gian CPU, memory, disk I/O, số process và số entry process. Mỗi giới hạn gây ra một kiểu lỗi riêng. Khi chạm giới hạn CPU hoặc I/O, website phản hồi chậm hơn nhưng không bị hỏng. Khi chạm giới hạn memory hoặc process, website thường trả về lỗi 500 và 503. Với Apache, trang lỗi có tiêu đề 508 Resource Limit Reached xuất hiện do chạm giới hạn entry process; LiteSpeed xử lý entry process theo cách khác. Trong mọi trường hợp, chính tài khoản của bạn đã chạm giới hạn của nó, không phải một tài khoản khác chiếm phần tài nguyên của bạn.

Đây là một đánh đổi có chủ ý. Bạn từ bỏ quyền kiểm soát, đổi lại nhà cung cấp patch kernel và duy trì software được hỗ trợ; việc gia hạn certificate và lịch backup phụ thuộc vào gói dịch vụ. Với rất nhiều website, đây là một đánh đổi hợp lý.

VPS thực sự cung cấp cho bạn những gì

VPS là một máy ảo chạy trên máy chủ vật lý. Với KVM, instance của bạn khởi động bằng kernel riêng, có IP riêng, firewall riêng và hệ thống init riêng. Trên một Linux VPS không được quản trị sẵn và có quyền root, sudo hoạt động. Trên bản cài đặt Debian hoặc Ubuntu, apt install hoạt động. Chương trình bạn khởi động bằng systemd tiếp tục chạy sau khi bạn đăng xuất. Với cấu hình restart và boot phù hợp, chương trình sẽ tự khởi động lại sau khi bị crash và chạy lại sau khi reboot.

Chính quyền root đó cũng khiến việc bảo mật máy chủ trở thành trách nhiệm của bạn. Không có ai khác theo dõi máy chủ này. Các loại dịch vụ có thể chạy trên VPS rất đa dạng cũng vì lý do đó: máy chủ có thể làm bất cứ việc gì mà một Linux server có thể làm.

Khác biệt 1: quyền root và những gì quyền này cho phép

Root cho phép bạn kiểm soát hệ điều hành. Với quyền này, bạn có thể cài bất kỳ package nào từ distribution, bind vào bất kỳ port nào, viết systemd unit, đọc mọi log trên máy và thay đổi thiết lập kernel bằng sysctl. Không có quyền root, panel không phải lúc nào cũng là giới hạn: alwaysdata hỗ trợ cài thêm PHP extension bằng ad_install_pecl.

Trên VPS, bạn luôn có thể yêu cầu máy chủ hiển thị các tiến trình đang listening:

ss -ltnp

Mỗi dòng socket cho biết một TCP listener. Thông tin process phụ thuộc vào quyền của bạn, vì vậy một service lẽ ra phải listen trên TCP nhưng khởi động thất bại sẽ xuất hiện dưới dạng một dòng bị thiếu. Trên shared hosting, quyền truy cập thông tin socket và quyền chạy listener của riêng bạn phụ thuộc vào provider, dù host vẫn kiểm soát các port 80 và 443.

Bức tranh 2: bộ nhớ được cấp so với bộ nhớ đi mượn

Shared hosting được bán dựa trên giả định rằng chỉ có một số ít account hoạt động nặng cùng lúc. Bộ nhớ trong máy là một pool, và phần bộ nhớ dành cho account của bạn là một giới hạn chứ không phải phần được đặt trước. Trên CloudLinux, khi chạm giới hạn bộ nhớ vật lý, các process sẽ bị kill và visitor có thể nhận lỗi 500 hoặc 503.

Trên VPS, free -m báo lượng bộ nhớ mà guest của bạn nhìn thấy, không chứng minh rằng bạn đã được đặt trước một lượng bộ nhớ vật lý không thể thu hồi. Host có thể thu hồi bộ nhớ của guest bằng ballooning; việc này có được phép hay không phụ thuộc vào các cam kết tài nguyên của provider trong plan của bạn.

Thời gian CPU cũng là một tài nguyên dùng chung trên các plan VPS dùng shared CPU, và bạn có thể tự đo steal time:

vmstat 1 5

Cột st là steal time: tỷ lệ thời gian processor ảo của bạn đã sẵn sàng chạy nhưng physical core lại được cấp cho guest khác. Không có một tỷ lệ hoặc ngưỡng bình thường chung nào chứng minh host bị oversubscription; steal time kéo dài là một số liệu bạn có thể đưa vào ticket hỗ trợ. vmstat cần quyền truy cập vào các file /proc tương ứng, nhưng không cần root cho các phép đọc thông thường, và shared host có thể hạn chế khả năng quan sát này. Storage cũng là một tài nguyên cần kiểm tra. Vì vậy, loại disk đứng sau một plan VPS rất quan trọng, và bạn nên tự đo một VPS mới trong tuần đầu tiên thay vì chỉ tin vào trang bán hàng.

Khác biệt 3: ai chịu trách nhiệm khi có sự cố

Với shared hosting, nhà cung cấp quản lý hệ điều hành, web server và các bản PHP được hỗ trợ; phạm vi cấp chứng chỉ và backup phụ thuộc vào gói dịch vụ. Khi máy chủ ngừng phản hồi, bạn mở một ticket; thời gian xử lý phụ thuộc vào chính sách hỗ trợ của nhà cung cấp. Mặt trái của nguyên tắc này là phần mềm nằm ngoài môi trường được hỗ trợ phải phù hợp với chính sách cài đặt và vận hành dịch vụ của nhà cung cấp.

Với VPS không được quản lý, nhà cung cấp chịu trách nhiệm về hypervisor, network và nguồn điện. Mọi thứ từ kernel trở lên đều thuộc trách nhiệm của bạn. Cập nhật bảo mật, firewall, backup, gia hạn chứng chỉ và monitoring đều do bạn thực hiện, còn bộ phận hỗ trợ sẽ không đăng nhập để debug cấu hình web server của bạn. Hãy chuẩn bị ngay từ ngày đầu: mười phút đầu tiên trên một VPS mới, sau đó là một firewall mà bạn hiểu rõ, cập nhật bảo mật tự động và backup mà bạn đã khôi phục thành công ít nhất một lần.

Khi shared hosting là lựa chọn phù hợp

Website giới thiệu là trường hợp rõ nhất: một số trang, hình ảnh, form liên hệ, có thể thêm WordPress với plugin cache, và lưu lượng nằm trong giới hạn tài nguyên của gói. Không có background job. Không có runtime bất thường. Không có dữ liệu nào cần được giữ trong bộ nhớ giữa các request. Shared hosting đáp ứng tốt cho website đó và giao việc bảo trì server cho đội ngũ làm việc này toàn thời gian; hãy so sánh giá vì shared hosting không phải lúc nào cũng rẻ hơn mọi VPS. Chuyển website sang VPS không mang lại lợi ích gì mà còn thêm một việc bạn chưa từng phải làm.

Có một trường hợp khác ít được chú ý hơn. Nếu không ai trong đội ngũ của bạn muốn đọc log hoặc chạy apt upgrade, shared hosting là lựa chọn an toàn hơn. Một VPS chưa được cập nhật bản vá và để mở cổng database sẽ có hậu quả nghiêm trọng hơn một tài khoản shared hosting được chuyên gia duy trì cập nhật. Quyền kiểm soát chỉ là lợi thế khi có người sử dụng nó.

Dấu hiệu 1: bạn cần một chương trình chạy liên tục

Daemon là chương trình luôn nằm trong bộ nhớ và chờ công việc: API, chatbot, queue worker hoặc game server. Quy định của shared hosting khác nhau: DreamHost cấm các tiến trình chạy liên tục trên gói shared, còn alwaysdata cung cấp dịch vụ tùy chỉnh được giám sát trên các gói trả phí.

Trên VPS, chương trình này trở thành một systemd unit:

sudo systemctl enable --now myapp
systemctl status myapp

systemctl status phải in ra Active: active (running) cùng với process ID. Nếu in ra Active: failed (Result: exit-code), lý do nằm trong journalctl -u myapp -n 50, nơi hiển thị output của chính chương trình tại thời điểm chương trình dừng. Restart=always trong unit file sẽ khởi động lại chương trình sau khi crash, còn enable sẽ khởi động lại chương trình sau reboot. Viết systemd service và timer là kỹ năng VPS đầu tiên bạn nên học cho đúng.

Dấu hiệu 2: bạn cần runtime mà panel không cung cấp

Panel cung cấp một danh sách. Nếu ứng dụng của bạn cần phiên bản ngôn ngữ nằm ngoài danh sách đó, một library phải compile, ffmpeg, trình duyệt headless hoặc database mà panel không cung cấp (cPanel hỗ trợ MySQL và PostgreSQL nếu nhà cung cấp bật tính năng này), hãy kiểm tra quy định cài đặt của nhà cung cấp. Việc cài software trong thư mục home không phải lúc nào cũng cần root: DreamHost có tài liệu hướng dẫn compile zlib và cài phiên bản Python tùy chỉnh trên shared server.

Trên VPS, bạn cài bằng apt install hoặc chạy trong container để giữ host sạch. Docker Compose trên VPS là cách thường dùng khi ứng dụng có nhiều hơn một thành phần cần vận hành.

Dấu hiệu 3: cron job phải chạy đúng giờ

Shared host nhận cron job thông qua biểu mẫu và có thể tự đặt khoảng thời gian tối thiểu giữa các lần chạy. Trên CloudLinux, job chạm giới hạn CPU của account sẽ bị làm chậm thay vì bị dừng, nên một job chạy lâu vẫn có thể đang chạy khi lần chạy tiếp theo đến hạn. Nếu account đã chạm giới hạn số process, job hoàn toàn không thể khởi chạy process mới. Bạn có thể xem được một phần thông tin này: cài đặt Cron Email của cPanel sẽ gửi output của từng job qua email. Trên các CloudLinux host có hỗ trợ tính năng này, trang Resource Usage trong panel cho biết account đã chạm giới hạn nào và đếm số lần vi phạm. Host vẫn giữ quyền truy cập system log và quyền tăng giới hạn, nhưng một số provider cung cấp task log có thời gian bắt đầu và kết thúc.

Trên VPS crontab -e chấp nhận các lịch được cron implementation đã cài đặt hỗ trợ. systemd timer còn phù hợp hơn:

systemctl list-timers
journalctl -u cron -n 20

list-timers in thời gian trigger tiếp theo và gần nhất của các timer hiện đang nằm trong memory, không in kết quả exit của service tương ứng. Cron journal phụ thuộc vào cron service đã cài đặt và cấu hình logging. Khi một job không chạy, hãy kiểm tra status và log của service để xác định job chưa từng khởi động hay đã khởi động rồi fail. Phần lớn việc debug scheduled task là phân biệt hai trường hợp này.

Dấu hiệu 4: các tài khoản dùng chung đang làm tăng thời gian phản hồi của bạn

Triệu chứng này rất cụ thể. Cùng một trang, không thay đổi code, phản hồi nhanh vào ban đêm nhưng chậm vào 7 giờ tối. Hãy đo từ chính máy của bạn trước khi quy trách nhiệm cho bất kỳ ai:

for i in $(seq 1 20); do curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/; sleep 5; done

time_starttransfer là thời gian đến byte đầu tiên của response, tính bằng giây. Nếu 20 giá trị nằm gần nhau, điều đó cho thấy thời gian phản hồi ổn định, nhưng không cho biết nguyên nhân nằm ở server, code hay database. Nếu các giá trị ổn định lúc 3am nhưng dao động vài trăm mili giây vào giờ cao điểm, hãy so sánh mức sử dụng tài nguyên của account, lưu lượng request và log của server trước khi quy trách nhiệm cho các account lân cận. Các phép đo này bao gồm thời gian thiết lập kết nối và thời gian server xử lý, nên tự chúng không xác định được nguyên nhân.

Chi phí thực tế khi chuyển sang VPS

Đây là các mức giá được công bố và kiểm tra vào ngày 4 tháng 11 năm 2026, không phải mức trung bình của cả danh mục hay các gói rẻ nhất hiện có. Các ví dụ về shared hosting, VPS 4 GB và dịch vụ managed lần lượt là Web Hosting Launch, Stack 4 và Managed VPS Business của DreamHost với hình thức thanh toán hằng năm; VPS 1 GiB là Basic Droplet thông thường của DigitalOcean ở mức giá tối đa theo tháng. Hãy kiểm tra giá hiện tại trước khi mua.

Biểu đồAdvertised monthly price examples in US dollars, November 4, 2026
Dữ liệu đằng sau biểu đồ này
[
  {
    "plan": "Shared hosting, DreamHost",
    "first_term_usd": 2.89,
    "renewal_usd": 10.99
  },
  {
    "plan": "VPS, 1 vCPU 1 GiB, DigitalOcean",
    "first_term_usd": 6,
    "renewal_usd": 6
  },
  {
    "plan": "VPS, 2 vCPU 4 GB, DreamHost",
    "first_term_usd": 6.99,
    "renewal_usd": 11.99
  },
  {
    "plan": "Managed VPS, 2 cores 2 GB, DreamHost",
    "first_term_usd": 13.75,
    "renewal_usd": 31.99
  }
]

Khoảng chênh lệch được quảng cáo là từ 2.89 đến 6 đô la Mỹ mỗi tháng, nhưng đây không phải con số quyết định. Gói shared hosting yêu cầu thanh toán trước cho cả năm và gia hạn ở mức 10.99 đô la mỗi tháng. Nếu so sánh giá gia hạn với giá gia hạn, bức tranh sẽ khác: 10.99 đô la cho tài khoản shared hosting so với 6 đô la cho một VPS cấp cơ bản. Hai mức giá của DigitalOcean bằng nhau vì ví dụ này không có ưu đãi cho kỳ đầu.

Hãy thận trọng khi so sánh, vì cấu hình không tương đương. VPS 1 vCPU, 1 GB chạy web server và database trên cùng một máy nhỏ, nên sẽ nhanh chạm giới hạn khi WordPress có traffic thực tế. Ví dụ 2 vCPU, 4 GB có giá gia hạn 11.99 đô la mỗi tháng, nhưng giới hạn của shared hosting và năng lực của VPS không thể quy đổi trực tiếp cho nhau. Trong các ví dụ này, phần chênh lệch giá gia hạn so với shared hosting là 1 đô la mỗi tháng.

Chi phí lớn hơn không bao giờ xuất hiện trên hóa đơn. VPS cần thêm một giờ để setup, vài phút mỗi tháng cho việc update, và một buổi tối mà bạn sẽ phải dành ra khi có sự cố lần đầu. Hãy tính phần thời gian đó theo mức phí mỗi giờ của bạn; khoảng chênh lệch sẽ nhanh chóng thu hẹp. Chi phí thực tế của VPS phân tích chi tiết hơn theo từng cấu hình.

Chuyển website khỏi shared hosting mà không làm mất traffic

  1. Trước một ngày, giảm DNS (domain name system) TTL (time to live) của domain xuống 300 giây và chờ TTL cũ hết hạn trước khi chuyển đổi; cache cục bộ vẫn có thể mất nhiều thời gian hơn để cập nhật.
  2. Dựng server mới và bảo đảm website hoạt động trên địa chỉ IP của server trước khi thay đổi DNS.
  3. Sao chép các file, sau đó dump database và restore trên server mới.
  4. Kiểm tra bằng file hosts trên laptop. File này chỉ trỏ domain đến IP mới trên máy của bạn.
  5. Cấp chứng chỉ TLS (transport layer security) trên server mới bằng DNS validation hoặc dùng chứng chỉ hiện có còn hiệu lực trước khi thay đổi bản ghi A. Giữ account dùng chung hoạt động trong một tuần.
dig example.com A +noall +answer
rsync -avz ~/public_html/ deploy@203.0.113.10:/srv/www/example.com/
mysqldump --single-transaction -u dbuser -p dbname > site.sql

dig in TTL ở cột thứ hai trong kết quả trả về, vì vậy bạn có thể xác nhận giá trị thấp hơn đang có hiệu lực trước khi chuyển đổi. --single-transaction tạo snapshot nhất quán của các bảng InnoDB mà không khóa chúng; các bảng không hỗ trợ transaction và thay đổi schema đồng thời cần được xử lý riêng, đồng thời các order phát sinh sau đó không nằm trong snapshot này. Trên server mới, hãy cấu hình chứng chỉ ngay trong ngày: Cấu hình Let's Encrypt trên Ubuntu với nginx chỉ mất vài phút sau khi bản ghi DNS trỏ đến server.

Tài nguyên mà không phải tự chịu trách nhiệm

Nếu bốn dấu hiệu này mô tả đúng website của bạn nhưng bạn không muốn tự bảo trì, lựa chọn ở giữa là VPS managed. Nhà cung cấp sẽ xử lý phần bảo trì đã thỏa thuận, nhưng quyền root và phạm vi hỗ trợ quản trị phụ thuộc vào gói dịch vụ; VPS managed của DreamHost không có quyền root. Bảng trên đưa ví dụ VPS managed 2 GB ở mức 31.99 đô la, so với 11.99 cho ví dụ VPS unmanaged 4 GB, nên đây không phải là so sánh giữa hai cấu hình cùng kích thước. Khoản chênh lệch này trả cho việc có người khác xử lý khi máy chủ ngừng phản hồi vào ban đêm.

Quyết định chọn VPS managed hay unmanaged là phần bạn nên đọc tiếp nếu tình huống này đúng với bạn. Nếu bạn đã vận hành một VPS bận rộn nhưng việc nó chiếm thời gian vẫn là vấn đề nghiêm trọng vào giờ cao điểm, bước tiếp theo là một máy chủ dedicated hoàn toàn không có máy lân cận.

FAQ

VPS có nhanh hơn shared hosting không?

Không phải lúc nào cũng vậy. Một shared server ít tải có thể nhanh hơn VPS 1 vCPU khi tải một trang WordPress đơn lẻ. Việc được cấp riêng memory không loại bỏ tranh chấp CPU: trên VPS dùng shared CPU, các instance lân cận vẫn có thể ảnh hưởng đến response time, còn mức memory được bảo đảm phụ thuộc vào provider. Nếu trang của bạn chậm cả lúc 3am lẫn 7pm, hãy kiểm tra code, các truy vấn database và giới hạn tài nguyên của hosting; thời điểm trong ngày không xác định được nguyên nhân.

Tôi có thể chạy app Node.js hoặc Python trên shared hosting không?

Đôi khi có, trong giới hạn của provider. Một số panel khởi chạy application giúp bạn thông qua Passenger, và application chỉ chạy khi có request đến. Việc host sở hữu các port 80 và 443 không ngăn các listener khác được phép sử dụng: alwaysdata cho phép custom service dùng các port từ 8300 đến 8499 qua IPv6 trên Public Cloud của họ. Quy định về process chạy liên tục cũng khác nhau giữa các host, vì vậy bot, queue worker hoặc websocket server cần một plan nêu rõ là có hỗ trợ, chứ không phải mặc định phải dùng VPS.

Tôi có cần biết Linux để chạy VPS không?

Nếu là VPS không được quản lý thì có. Bạn cần SSH keys, firewall, cập nhật, backup và thói quen đọc log. Hãy dành 1 giờ cho lần thiết lập ban đầu, sau đó vài phút mỗi tháng. Nếu bạn không muốn tự làm những việc này, managed plan sẽ chuyển phần bảo trì đã thỏa thuận lại cho provider. Đây là sự đánh đổi được đề cập trong hosting VPS managed và unmanaged.

Website của tôi có bị downtime khi chuyển từ shared hosting sang VPS không?

Giảm DNS TTL và duy trì cả hai account đang hoạt động giúp tránh downtime, nhưng không bảo đảm quá trình chuyển đổi liền mạch. Đặt TTL thành 300 giây trước 1 ngày và chờ TTL cũ hết hiệu lực, sao chép các file và database, kiểm tra server mới qua hosts file trên laptop, rồi thay đổi A record. Trong lúc thay đổi, một số visitor sẽ truy cập server cũ và một số truy cập server mới. Cache cũng có thể mất hơn 5 phút để cập nhật, vì vậy hãy duy trì shared account trong 1 tuần. Tạm dừng các thao tác ghi khi dump và restore database lần cuối. Giữ site cũ ở chế độ chỉ đọc hoặc chuyển các request của nó đến server mới để không làm mất các thao tác ghi phát sinh sau đó.

Bài viết này có hữu ích không?

#vps#shared-hosting#hosting-comparison#beginners