IIS (Internet Information Services) là web server do Microsoft phát triển cho Windows và Windows Server. Nhiều đội kỹ thuật đánh giá IIS như một web server “chung”, rồi so hiệu năng thuần túy với Apache hay Nginx. Cách so đó bỏ lỡ điểm quan trọng nhất. IIS được thiết kế để chạy tốt nhất […]
IIS (Internet Information Services) là web server do Microsoft phát triển cho Windows và Windows Server. Nhiều đội kỹ thuật đánh giá IIS như một web server “chung”, rồi so hiệu năng thuần túy với Apache hay Nginx. Cách so đó bỏ lỡ điểm quan trọng nhất. IIS được thiết kế để chạy tốt nhất trong hệ sinh thái Windows Server, ASP.NET và Active Directory (dịch vụ quản lý tài khoản và phân quyền của Microsoft), không phải để cạnh tranh hiệu năng thuần trên mọi hạ tầng.
Theo W3Techs (dữ liệu tháng 7/2026), IIS hiện chỉ chiếm khoảng 3,1% thị phần web server toàn cầu và tiếp tục giảm, vì phần lớn thị trường web server là Linux. Con số đó không có nghĩa IIS kém. Nó cho thấy IIS phục vụ một ngách cụ thể: hệ thống đã sống trong hạ tầng Microsoft. Bài này giải thích cơ chế hoạt động của IIS, so sánh với Apache/Nginx theo đúng ngữ cảnh đó, và hướng dẫn cài đặt cơ bản.
Contents
Như đã giải thích ở trên, IIS là viết tắt của Internet Information Services, web server do Microsoft phát triển và cung cấp dưới dạng Windows Feature (trên máy trạm) hoặc Server Role (trên Windows Server). Nhiệm vụ chính của IIS gồm: nhận HTTP/HTTPS request, phục vụ file tĩnh, chuyển request đến ứng dụng web, quản lý website/domain/port/SSL, và xử lý authentication (xác thực người dùng), authorization (phân quyền truy cập) cùng logging (ghi log).
IIS không phải công cụ viết code, không phải dịch vụ hosting, cũng không phải hệ điều hành. Nó là lớp trung gian, nhận request từ Internet hoặc mạng nội bộ rồi giao cho đúng ứng dụng xử lý. IIS tích hợp tốt với Windows Server, ASP.NET Framework, ASP.NET Core, Active Directory và PowerShell (công cụ dòng lệnh quản trị của Windows). Vì vậy phần lớn giá trị của IIS nằm ở mức độ gắn kết với các thành phần này, không phải ở việc phục vụ HTTP thuần túy nhanh hơn đối thủ.
Điểm hay bị hiểu sai: IIS không chỉ chạy được ASP.NET. Khi cấu hình đúng module, IIS vẫn phục vụ được static content, API hoặc tích hợp với runtime khác. Nhưng cấu hình đó là công việc bổ sung, trong khi với ASP.NET, mọi thứ đã sẵn sàng gần như ngay khi cài đặt. Đó là lý do IIS thường xuất hiện mặc định trong hệ thống .NET, chứ hiếm khi được chọn cho một stack hoàn toàn Linux/PHP.
Tình huống sử dụng IIS gần như luôn xoay quanh một điều kiện: hệ thống đã hoặc sẽ chạy trên Windows Server. Ngoài điều kiện đó, các lựa chọn khác thường được cân nhắc trước.
IIS phục vụ website ASP.NET Framework, ứng dụng ASP.NET Core, REST API (giao diện lập trình cho ứng dụng khác gọi vào), portal doanh nghiệp, website thương mại điện tử và backend service chạy trên Windows Server. Đây là nhóm tình huống IIS mạnh nhất. Runtime .NET và IIS được Microsoft phát triển song song, nên tích hợp sẵn mà không cần cấu hình thêm nhiều.
Cổng thông tin nội bộ, CRM, ERP, dashboard, hệ thống nhân sự và ứng dụng quản lý tài liệu là nhóm tình huống thứ hai. Với intranet, IIS tích hợp Windows Authentication (cơ chế xác thực bằng tài khoản Windows có sẵn) và phân quyền theo user hoặc group trong Active Directory. Nhờ vậy nhân viên đăng nhập bằng tài khoản domain có sẵn, không cần hệ thống tài khoản riêng.
Mỗi website trên IIS có Binding riêng, có thể phân biệt bằng domain, subdomain hoặc port khác nhau. Mỗi ứng dụng chạy trong một Application Pool riêng, nên khi một ứng dụng gặp sự cố, các ứng dụng khác trên cùng máy vẫn tiếp tục chạy. Đây là cơ chế cô lập, không phải tính năng phụ. Nó là lý do IIS xử lý tốt việc gộp nhiều ứng dụng nội bộ lên một máy chủ.
IIS phục vụ HTML, CSS, JavaScript, hình ảnh và REST API, đồng thời có thể proxy request tới ứng dụng backend (chuyển tiếp request sang một server phía sau, cơ chế gọi là reverse proxy) khi cài thêm module như Application Request Routing (module định tuyến request của Microsoft). Tuy nhiên đây không phải thế mạnh chính của IIS so với Nginx, vốn được thiết kế riêng cho reverse proxy và static content với chi phí tài nguyên thấp hơn.
IIS có thể cung cấp dịch vụ FTP/FTPS khi cài thêm FTP Server Role, nhưng đây không phải chức năng mặc định của toàn bộ cài đặt IIS. Không nên nhầm việc bật IIS đồng nghĩa với có sẵn FTP.
Một request tới IIS đi qua năm bước: trình duyệt gửi HTTP/HTTPS request, HTTP.sys tiếp nhận, Binding xác định website, Application Pool xử lý qua Worker Process, rồi IIS trả response về trình duyệt. Trong năm bước này, bước Application Pool là nơi tạo ra khác biệt vận hành thực sự so với các web server khác.
HTTP.sys là HTTP listener (thành phần lắng nghe và tiếp nhận kết nối HTTP) hoạt động ở Kernel Mode, tức lớp lõi của hệ điều hành Windows có quyền truy cập phần cứng trực tiếp. Nó tiếp nhận mọi request gửi đến server rồi đưa vào hàng đợi (queue) tương ứng, trước khi chuyển đến tiến trình ứng dụng. Việc xử lý ở Kernel Mode giúp IIS tiếp nhận kết nối hiệu quả mà không cần mỗi ứng dụng tự lo quản lý hàng đợi request.
IIS dùng Binding để tìm website phù hợp dựa trên giao thức (HTTP hoặc HTTPS), địa chỉ IP, port và host name. Ví dụ một Binding cụ thể: giao thức HTTPS, port 443, host name example.com. Nếu nhiều website dùng chung một IP, IIS phân biệt chúng bằng host name hoặc port khác nhau.
Mỗi website hoặc ứng dụng được liên kết với một Application Pool, và pool tạo môi trường chạy riêng cho ứng dụng đó. Mỗi pool có identity (tài khoản chạy tiến trình) riêng, runtime riêng, cấu hình recycling (khởi động lại định kỳ) riêng và giới hạn tài nguyên riêng. Đây chính là cơ chế cô lập nhắc ở phần tình huống sử dụng: một pool gặp lỗi không kéo theo pool khác.
Worker Process là tiến trình thực thi request bên trong Application Pool, thường mang tên tiến trình w3wp.exe. Request đi qua HTTP pipeline (chuỗi các bước xử lý tuần tự), trong đó Module (thành phần tham gia từng giai đoạn xử lý) và Handler (thành phần xử lý một loại request cụ thể) tham gia vào authentication, authorization, request filtering và compression. Static content có thể được trả trực tiếp, còn dynamic request được chuyển tới framework hoặc runtime ứng dụng.
Một quy tắc vận hành đáng lưu ý: nên đặt số worker process tối đa qua cấu hình Web Garden (cơ chế cho phép một Application Pool chạy nhiều worker process song song) tương ứng với số CPU core của server. Đây là khuyến nghị trong hướng dẫn cấu hình IIS Application Pool của CLIMB. Đặt cao hơn không giúp xử lý nhanh hơn, chỉ tạo thêm tranh chấp tài nguyên giữa các tiến trình.
IIS trả status code, header và response body về client. Nếu logging được bật, IIS ghi lại URL, HTTP method, status code, client IP, response time và user agent. Log này là nguồn dữ liệu chính khi troubleshooting lỗi 401, 403 hoặc 500.19 nhắc ở phần cài đặt bên dưới.
Bảng dưới tóm tắt các thành phần cấu hình IIS theo vai trò, không lặp lại luồng request đã nêu ở trên:
|
Thành phần |
Vai trò |
|
IIS Manager |
Giao diện quản trị IIS |
|
Website |
Đơn vị cấu hình đại diện cho một website |
|
Application |
Ứng dụng nằm trong website |
|
Virtual Directory |
Ánh xạ URL đến một thư mục vật lý |
|
Binding |
Xác định website theo protocol, IP, port và hostname |
|
Application Pool |
Cô lập môi trường chạy của ứng dụng |
|
Worker Process |
Tiến trình xử lý request |
|
w3wp.exe |
Tên tiến trình thường thấy của IIS Worker Process |
|
web.config |
File cấu hình website hoặc ứng dụng |
|
Module |
Thành phần tham gia từng giai đoạn trong HTTP pipeline |
|
Handler |
Thành phần xử lý một loại request cụ thể |
|
Log |
Ghi lại request và kết quả xử lý |
Trong số này, ba khái niệm quyết định phần lớn cách bạn vận hành IIS hằng ngày là Binding, Application Pool và Worker Process.
Binding quyết định request nào thuộc về website nào. Một website có thể có nhiều Binding cùng lúc, ví dụ HTTP port 80 cho domain chính và HTTPS port 443 cho một subdomain khác. Cấu hình sai Binding là nguyên nhân phổ biến khiến hai website “giẫm” lên nhau hoặc một site không truy cập được dù server vẫn chạy bình thường.
Application Pool tạo ranh giới cô lập giữa các ứng dụng, và một pool có thể chứa một hoặc nhiều ứng dụng. Với hệ thống quan trọng, bạn nên tách pool riêng cho từng ứng dụng để dễ quản lý và giảm ảnh hưởng chéo khi một ứng dụng gặp sự cố hoặc cần restart riêng.
Worker Process là tiến trình thực thi request trong Application Pool, và một server có thể chạy nhiều w3wp.exe cùng lúc. Số lượng tiến trình phụ thuộc vào số pool đang chạy và cấu hình Web Garden đã nhắc ở phần trên.
Mức độ IIS “bắt buộc” hay chỉ “hữu ích” phụ thuộc vào việc ứng dụng chạy ASP.NET Framework hay ASP.NET Core. Đây là điểm nhiều đội kỹ thuật nhầm lẫn khi chuyển đổi giữa hai nền tảng.
ASP.NET Framework tích hợp sâu với IIS. Request đi qua cả IIS pipeline và ASP.NET pipeline, còn IIS quản lý Worker Process, authentication, Application Pool, runtime settings và recycling. Mô hình này phổ biến trong các hệ thống doanh nghiệp chạy .NET Framework, nơi IIS gần như là lựa chọn mặc định chứ không phải một trong nhiều phương án.
ASP.NET Core thường chạy bằng Kestrel, một web server nhẹ tích hợp sẵn trong runtime .NET, còn IIS đứng phía trước để nhận HTTP/HTTPS request. ASP.NET Core Module (thành phần kết nối IIS với runtime .NET Core) nối IIS với ứng dụng theo hai mô hình: in-process hosting, tức ứng dụng chạy chung tiến trình với IIS worker process để giảm độ trễ, hoặc out-of-process hosting, tức ứng dụng chạy trong một tiến trình Kestrel riêng còn IIS chỉ chuyển tiếp request. Khi đứng trước Kestrel, IIS đảm nhiệm process management, port sharing, Windows Authentication, SSL termination (giải mã kết nối HTTPS), request filtering và logging, còn Kestrel đảm nhiệm việc chạy ứng dụng.
ASP.NET Core không bắt buộc phải chạy sau IIS. Ứng dụng có thể chạy sau Nginx, Apache, load balancer (thiết bị/phần mềm phân phối tải giữa nhiều server) hoặc trực tiếp bằng Kestrel trong môi trường phù hợp. Đây là điểm củng cố luận điểm ở đầu bài. Quyết định dùng IIS cho ASP.NET Core nên dựa vào việc server có phải Windows hay không, và đội vận hành có quen Windows Authentication/Active Directory hay không. Đó không phải vì “ASP.NET Core cần IIS”.
Các tính năng dưới đây chỉ thực sự phát huy giá trị khi đội vận hành đã quen với công cụ quản trị Windows. Nếu không, chúng chỉ là danh sách tính năng không tạo khác biệt thực tế.
IIS Manager, PowerShell và command line cho phép cấu hình website, pool, binding, certificate và log từ một nơi, và có thể quản lý từ xa khi được cấu hình đúng. Với đội đã quen PowerShell trong hệ sinh thái Windows, đây là lợi thế rõ so với việc học thêm công cụ quản trị mới.
Mỗi pool có identity riêng, runtime riêng, cấu hình recycling, idle timeout (thời gian chờ trước khi tắt tiến trình không hoạt động) và resource control riêng. Nhờ vậy tác động giữa các ứng dụng chạy chung server giảm đáng kể. Theo hướng dẫn best practice của LeanSentry, cơ chế overlapped recycling mặc định giữ worker process cũ chạy tới khi worker process mới sẵn sàng nhận request. Nhờ đó việc recycle định kỳ không gây gián đoạn dịch vụ cho client.
IIS hỗ trợ nhiều cơ chế xác thực: Anonymous Authentication, Basic Authentication, Windows Authentication, Digest Authentication, Client Certificate Authentication và Authorization Rules (quy tắc phân quyền truy cập). Trong đó Windows Authentication là tính năng khó thay thế nhất nếu hệ thống của bạn đã gắn với Active Directory. Nó cho phép đăng nhập bằng tài khoản domain có sẵn mà không cần xây hệ thống xác thực riêng.
Request Filtering, IP Address Restrictions, SSL/TLS, Dynamic IP Restrictions, Hidden Segments và Request size limit là các lớp kiểm soát request trước khi tới ứng dụng. Đây là các tính năng tiêu chuẩn mà hầu hết web server hiện đại đều có, không riêng gì IIS.
IIS Access Log, Failed Request Tracing (công cụ theo dõi request bị lỗi theo từng bước xử lý), HTTP status/substatus, tích hợp Event Viewer (công cụ xem log hệ thống của Windows) và log theo từng website là bộ công cụ chẩn đoán khi hệ thống gặp sự cố. Failed Request Tracing đặc biệt hữu ích khi cần biết chính xác request bị chặn ở bước nào trong pipeline, ví dụ ở authentication, một module cụ thể, hay một handler cụ thể.
IIS có thể bổ sung URL Rewrite (module viết lại đường dẫn URL), Application Request Routing, Compression, Output Caching (lưu tạm kết quả xử lý để trả nhanh hơn cho request sau), WebSocket (giao thức kết nối hai chiều liên tục) và FTP Server. Các module này giúp IIS đảm nhiệm thêm vai trò reverse proxy hoặc cache, nhưng đều là tính năng cài thêm, không phải mặc định như ở Nginx.
|
Ưu điểm |
Hạn chế |
|
Tích hợp sâu với Windows Server |
Chủ yếu phù hợp với Windows |
|
Hỗ trợ tốt ASP.NET và .NET |
Có thể phát sinh chi phí license Windows Server |
|
Tích hợp Windows Authentication và Active Directory |
Không phải lựa chọn tự nhiên cho Linux stack |
|
IIS Manager trực quan |
Một số module cần cài thêm |
|
Quản lý tốt bằng PowerShell |
Cấu hình nâng cao vẫn đòi hỏi kiến thức hệ thống |
|
Application Pool giúp cô lập ứng dụng |
Có thể tốn nhiều tài nguyên hơn reverse proxy nhẹ trong một số workload |
|
Có sẵn logging, authentication và filtering |
Ít phổ biến hơn trong hệ sinh thái Linux container |
|
Quản lý nhiều website thuận tiện |
Cấp sai permission hoặc identity dễ gây lỗi vận hành |
|
Phù hợp hệ thống doanh nghiệp Microsoft |
Khó di chuyển sang hệ điều hành khác nếu phụ thuộc sâu vào Windows |
Bảng trên cho thấy một mẫu hình rõ ràng: mọi ưu điểm của IIS đều gắn với hệ sinh thái Microsoft, còn mọi hạn chế đều xuất hiện khi bạn cố dùng IIS ngoài hệ sinh thái đó. Đây không phải trùng hợp, mà là bản chất thiết kế của IIS.
Về bảo mật, không nên khẳng định IIS an toàn hơn hoặc kém hơn Apache/Nginx một cách tuyệt đối. Mức độ bảo mật thực tế phụ thuộc vào phiên bản, mức độ cập nhật patch, cấu hình, chính bản thân ứng dụng, quyền hệ thống được cấp và quy trình vận hành của đội ngũ.
|
Tiêu chí |
IIS |
Apache |
Nginx |
|
Nhà phát triển |
Microsoft |
Apache Software Foundation |
F5/NGINX |
|
Hệ điều hành thế mạnh |
Windows |
Linux và nhiều nền tảng |
Linux và nhiều nền tảng |
|
Quản lý |
IIS Manager, PowerShell, web.config |
File config, module, .htaccess |
File config |
|
Thế mạnh |
.NET, Windows Authentication, Active Directory |
PHP, shared hosting, module |
Reverse proxy, static content, concurrency |
|
Cô lập ứng dụng |
Application Pool |
Process/thread và OS-level isolation |
Phụ thuộc upstream application |
|
Reverse proxy |
Có qua ARR/URL Rewrite |
Có qua module |
Là thế mạnh chính |
|
Static content |
Tốt |
Tốt |
Rất mạnh |
|
Dynamic application |
Tốt với Microsoft stack |
Tốt với nhiều runtime |
Thường proxy đến backend |
|
Chi phí OS |
Có thể cần Windows Server |
Thường dùng Linux |
Thường dùng Linux |
|
Môi trường phổ biến |
Enterprise Microsoft |
PHP, CMS, shared hosting |
API, microservices, cloud-native |
Bảng so sánh trên lý giải vì sao IIS chỉ chiếm khoảng 3,1% thị phần web server toàn cầu theo số liệu W3Techs đã dẫn ở trên, trong khi Nginx và Apache cộng lại chiếm hơn một nửa thị trường. Thị trường web server phần lớn là Linux, còn IIS giữ một ngách riêng: hệ thống doanh nghiệp đã cam kết với Windows Server và .NET. Trong ngách đó, IIS không có đối thủ tương đương về mức độ tích hợp. Ngoài ngách đó, Apache và Nginx thường thắng về chi phí hạ tầng và hiệu năng thuần cho reverse proxy hay static content.
Vậy nên chọn web server nào? Chọn IIS khi hệ thống dùng Windows Server, cần Active Directory, hoặc chạy ASP.NET Framework. Chọn Apache khi cần .htaccess, chạy PHP/shared hosting, hoặc cần hệ sinh thái module rộng. Chọn Nginx khi cần reverse proxy, phục vụ static content, xử lý nhiều kết nối đồng thời, hoặc vận hành microservices trên Linux. Trong hệ thống thực tế, nhiều đội kết hợp cả hai, ví dụ đặt Nginx làm reverse proxy phía trước IIS, thay vì ép buộc chỉ chọn một.
Bảng quyết định dưới đây tránh lặp lại phần tình huống sử dụng đã nêu, tập trung vào mức độ phù hợp theo từng bối cảnh hạ tầng:
|
Bối cảnh |
Mức độ phù hợp |
|
Ứng dụng chạy trên Windows Server |
Rất phù hợp |
|
Hệ thống dùng ASP.NET Framework |
Rất phù hợp |
|
Cần Windows Authentication |
Rất phù hợp |
|
Tích hợp Active Directory |
Rất phù hợp |
|
Đội vận hành quen IIS Manager và PowerShell |
Phù hợp |
|
Chạy ASP.NET Core trên Windows |
Phù hợp |
|
Hosting nhiều ứng dụng nội bộ |
Phù hợp |
|
Hạ tầng chủ yếu chạy Linux |
Bạn nên cân nhắc lựa chọn khác |
|
Dùng Linux container hoặc Kubernetes |
Bạn nên cân nhắc giải pháp khác |
|
Chỉ cần reverse proxy nhẹ |
Bạn có thể cân nhắc Nginx |
|
Stack chủ yếu PHP hoặc WordPress |
Bạn có thể cân nhắc Apache/Nginx |
|
Muốn giảm chi phí license hệ điều hành |
Bạn nên cân nhắc chuyển sang Linux |
IIS phù hợp nhất khi ứng dụng, hệ điều hành và đội vận hành đều thuộc hệ sinh thái Microsoft. Nếu chỉ một trong ba yếu tố đó lệch khỏi Microsoft, ví dụ ứng dụng .NET Core nhưng đội vận hành quen Linux hoặc ngược lại, câu hỏi đáng đặt ra không phải “IIS có tốt không”. Câu hỏi đúng là “chi phí duy trì Windows Server có xứng với lợi ích tích hợp không”.
Ba khái niệm này thường bị dùng lẫn, dù mỗi cái phục vụ một mục đích khác nhau:
|
Khái niệm |
Ý nghĩa |
Môi trường phù hợp |
|
IIS |
Web server đầy đủ của Windows |
Staging và production |
|
IIS Manager |
Công cụ giao diện để quản trị IIS |
Administrator và developer |
|
IIS Express |
Phiên bản nhẹ phục vụ development |
Máy developer và Visual Studio |
IIS Manager không phải một web server độc lập. Nó chỉ là công cụ giao diện để bạn quản trị IIS đang chạy. IIS Express thường được Visual Studio dùng để chạy ứng dụng ở máy local. Phiên bản này nhẹ hơn IIS đầy đủ và ít yêu cầu quyền quản trị hơn, nên phù hợp cho phát triển và kiểm thử. Bạn không nên xem IIS Express là lựa chọn thay thế đầy đủ cho IIS production. Bản production mới có quản lý Application Pool đầy đủ, cấu hình tập trung, xác thực nâng cao, logging, quản trị từ xa và các cài đặt bảo mật cấp server.
Bạn mở Control Panel, chọn Programs, rồi chọn Turn Windows features on or off. Tích chọn Internet Information Services, mở rộng mục đó và chọn các thành phần cần thiết:
Bạn nhấn OK để cài đặt, khởi động lại máy nếu được yêu cầu, rồi truy cập http://localhost để kiểm tra.
Bạn chỉ nên bật các feature thực sự cần, không chọn toàn bộ Role Services (các vai trò/dịch vụ con có thể cài thêm cho IIS) theo thói quen. Các tính năng như CGI (giao diện chạy chương trình ngoài để xử lý request), FTP, WebSocket hoặc Windows Authentication chỉ nên bật khi ứng dụng thực sự yêu cầu. Mỗi feature bật thêm là một bề mặt tấn công (attack surface) tiềm năng cần vá và giám sát.
Bạn mở Server Manager, chọn Add Roles and Features, rồi chọn Role-based or feature-based installation. Chọn server cần cài, chọn Web Server (IIS), thêm Management Tools, chọn các Role Services cần thiết rồi nhấn Install. Sau khi hoàn tất, bạn nên kiểm tra Default Web Site để xác nhận cài đặt thành công.
Bạn cũng có thể cài bằng PowerShell với một lệnh duy nhất:
Install-WindowsFeature Web-Server -IncludeManagementTools
Bạn truy cập http://localhost để xác nhận trang mặc định hiển thị, hoặc mở IIS Manager bằng lệnh inetmgr. Trong IIS Manager, bạn kiểm tra bốn điểm sau:
Bạn tạo một thư mục, ví dụ C:\Sites\demo, rồi tạo file index.html bên trong với nội dung tối thiểu:
<!DOCTYPE html>
<html lang=”vi”>
<head>
<meta charset=”UTF-8″>
<title>IIS Demo</title>
</head>
<body>
<h1>Website đang chạy trên IIS</h1>
</body>
</html>
Bạn mở IIS Manager, chọn Application Pools, rồi chọn Add Application Pool. Nhập tên pool và chọn runtime phù hợp. Với ứng dụng ASP.NET Core, bạn thường chọn No Managed Code vì runtime đã được Kestrel xử lý riêng. Bạn không nên dùng chung một pool cho tất cả ứng dụng quan trọng nếu không thực sự cần thiết, để giữ được lợi ích cô lập đã nói ở phần Application Pool.
Trong IIS Manager, bạn nhấp chuột phải vào Sites rồi chọn Add Website. Nhập site name, Application Pool, physical path, protocol, IP address, port và host name, rồi nhấn OK.
Với môi trường local, bạn có thể dùng protocol HTTP, port 8080, để trống host name. Nếu muốn dùng hostname riêng, ví dụ protocol HTTP, port 80, host name demo.local, bạn cần thêm dòng tương ứng vào hosts file của máy trước khi truy cập được.
Bạn cấp quyền Read and Execute cho identity phù hợp, không cấp Full Control cho Everyone. Chỉ cấp thêm quyền Write khi ứng dụng thực sự cần upload hoặc ghi file. Nếu gặp lỗi 401, 403 hoặc 500.19 khi truy cập, bạn nên kiểm tra Application Pool Identity trước tiên, vì đây là nguyên nhân phổ biến nhất của nhóm lỗi này.
Bạn truy cập http://localhost:8080 hoặc domain đã cấu hình để xác nhận website chạy đúng. Lưu ý rằng hai website không thể dùng cùng lúc protocol, IP, port và hostname nếu toàn bộ Binding giống nhau. Bạn cần thay đổi ít nhất một trong bốn yếu tố này.
Sau khi website chạy ổn định, bạn nên rà qua các điểm bảo mật cơ bản sau:
Đây là checklist cơ bản; nội dung hardening chuyên sâu cho môi trường doanh nghiệp lớn nên tách thành một bài riêng, vì mỗi mục ở trên còn nhiều lớp cấu hình chi tiết hơn tùy quy mô hệ thống.
Trần Đức Tâm là chuyên gia về hạ tầng Internet, Domain, Hosting, Cloud và chuyển đổi số, với nhiều năm kinh nghiệm phát triển các dịch vụ Internet tại Việt Nam và Nhật Bản. Ông hiện là Giám đốc Khối Kinh doanh Hạ tầng Internet tại GMO-Z.com RUNSYSTEM, từng giữ các vị trí lãnh đạo tại Onamae.com, Tenten.vn và Z.com Việt Nam. Các bài viết của ông tập trung vào tên miền, hosting, VPS, email doanh nghiệp, SSL và hạ tầng Internet.
Lỗi 502 Bad Gateway là một trong những sự cố HTTP phổ biến khiến website không thể truy cập được, gây ảnh hưởng trực tiếp đến trải nghiệm người dùng và uy tín của website. Bài viết dưới đây của Tenten sẽ giải thích rõ 502 Bad Gateway là gì, phân tích các nguyên nhân […]
IPv4 là giao thức mạng cốt lõi giúp định danh và kết nối các thiết bị trên môi trường Internet. Dù thế giới đang dần chuyển sang IPv6, IPv4 vẫn đóng vai trò nền tảng, quyết định cách dữ liệu được truyền tải chính xác giữa các thiết bị. Bài viết dưới đây của Tenten […]
Unlimited hosting là dịch vụ lưu trữ web không giới hạn dung lượng và băng thông. Bài viết dưới đây của Tenten sẽ giải thích chi tiết Unlimited hosting là gì và giới thiệu đến bạn top 7 nhà cung cấp hosting không giới hạn tốt nhất hiện nay. ContentsUnlimited hosting là gì?Những yếu tố […]
AppServ là gói cài đặt mã nguồn mở, gộp sẵn Apache (web server), PHP (ngôn ngữ lập trình phía server), MySQL (hệ quản trị cơ sở dữ liệu) và phpMyAdmin (giao diện quản lý MySQL) thành một trình cài đặt duy nhất cho Windows. Công cụ này giúp bạn dựng máy chủ localhost (máy chủ […]
DNS đóng vai trò như cuốn “danh bạ” giúp máy tính dịch địa chỉ trang web thành dãy số IP để kết nối Internet. Nếu muốn sử dụng một máy chủ DNS khác hoặc thử khắc phục một số vấn đề về kết nối, bạn có thể chủ động đổi DNS trên Windows 11. Bài […]
Database Hosting là dịch vụ lưu trữ cơ sở dữ liệu chuyên dụng giúp tối ưu tốc độ truy xuất, bảo mật và khả năng mở rộng dữ liệu. Bài viết dưới đây của Tenten sẽ giúp bạn hiểu rõ hơn Database Hosting là gì và tại sao mọi website hiện đại đều cần Database […]
OSPF (Open Shortest Path First) là giao thức định tuyến link-state được sử dụng phổ biến trong các hệ thống mạng doanh nghiệp quy mô lớn. Vậy OSPF là gì, hoạt động như thế nào và có những ưu, nhược điểm gì? Bài viết dưới đây của Tenten sẽ giúp bạn có cái nhìn tổng […]
Gặp lỗi 504 Gateway Time-out trên Nginx, hầu hết mọi người phản xạ tăng thời gian chờ (timeout) trong file cấu hình. Cách này chỉ đúng trong một trường hợp: khi máy chủ xử lý phía sau (backend) thật sự cần nhiều thời gian hơn mức bạn đang cho phép. Ba trường hợp còn lại, […]
Website được tạo bằng AI không đồng nghĩa với việc bạn phải sử dụng AI hosting. Nhiều người vẫn nhầm lẫn giữa hosting cho website có tích hợp AI và hạ tầng dùng để trực tiếp chạy mô hình AI, dẫn đến lựa chọn sai loại máy chủ và phát sinh chi phí không cần […]
Google Cloud Hosting là giải pháp lưu trữ website trên nền tảng điện toán đám mây của Google, mang đến khả năng mở rộng linh hoạt, hiệu suất ổn định và tính bảo mật cao. bài viết dưới đây của Tenten sẽ giúp bạn hiểu rõ hơn Google Cloud Hosting là gì cũng như những […]