使用IIS搭建Web服务器实训报告

把一台普通Windows电脑变成能对外提供网页服务的使用服务器，这事儿听起来挺唬人，服务但真上手做，器实核心就三步：装IIS、训报配站点、使用调权限。服务我这次实训用的器实是一台WinServer2019虚拟机，IP设的训报是192.168.1.88，全程没碰命令行，使用全靠图形界面点鼠标，服务倒是器实把IIS的脾气摸了个大概。

装IIS比我想象中快。训报打开“服务器管理器”，使用点“添加角色和功能”，服务一路下一步，器实勾上“Web服务器(IIS)”，系统自动把常用组件带上了。这里有个坑——默认只装静态网页支持，要是想跑ASP或PHP，得在角色服务里额外勾选“应用程序开发”下的对应项。我一开始没勾CGI，结果放了个PHP探针上去，浏览器直接给我吐源码，那叫一个尴尬。装完重启，浏览器敲http://localhost，看到那个标准的IIS欢迎页，才算松了口气。

真正动手配站点，才觉得IIS的逻辑有点像“先圈地，再开门”。左侧栏“网站”右键选“添加网站”，站点名称我填了“TestSite”，物理路径指向D:\webroot——特意没放C盘，免得系统盘被日志塞满。绑定类型选HTTP，端口默认80，主机名留空，意味着这台机器上所有指向80端口的请求都归这个站点管。这里有个细节：如果服务器上已经有个默认站点占着80端口，新站点起不来，得先把默认站点停掉。我当时没停，启动新站时直接报“另一个网站正在使用此端口”，折腾了五分钟才反应过来。

静态页面跑通后，我试着往里丢了个带表单的HTML，提交按钮点了没反应。查了一圈，发现是权限问题。IIS默认的应用程序池身份是“ApplicationPoolIdentity”，它对D:\webroot只有只读权限，而表单要写数据到同目录下的txt文件，写不进去。解决办法有两种：要么给该身份加“修改”权限，要么把应用程序池的高级设置里“进程模型”的标识改成“LocalSystem”。我选了后者，省事，但心里清楚这样不安全——万一站点被注入恶意脚本，攻击者直接拿到系统级权限。实训嘛，图个通，但老师后来强调生产环境必须用最小权限原则。

最让我意外的是日志分析。IIS每处理一个请求，都会在C:\inetpub\logs\LogFiles\W3SVC1\目录下记一条。我翻了下自己刚才的访问记录，发现IE浏览器连发了好几个请求，除了GET /index.html，还有GET /favicon.ico——那是我没做的小图标，404了。这种细节，不亲眼看日志根本想不到。流量小的时候日志文件一天也就几十KB，但要是被扫描器盯上，每秒几十个探测请求，日志文件能涨到几百MB，磁盘很快就满。所以生产环境的IIS通常要配日志滚动策略，按天或按大小切割。

实训最后一步是测外网访问。我把虚拟机网络调成桥接模式，然后拿手机连同一个Wi-Fi，浏览器输入http://192.168.1.88，居然真出来了页面。那一刻的成就感，比写代码跑通还强。但紧接着就发现，防火墙拦住了80端口——Windows自带的防火墙默认不放行HTTP入站。在“高级安全Windows Defender防火墙”里新建一条入站规则，允许TCP 80，手机再刷，通了。这让我意识到，IIS本身只是软件，真正决定它能不能被外面访问的，往往是操作系统层面的网络策略。

整个实训下来，最大的体会是：IIS不像Apache或Nginx那样配置文件一写一大串，它把大部分设置都画成了图形界面，上手门槛低，但代价是“隐藏的坑”不少。比如默认文档里没加index.php，你放个PHP首页进去，直接访问域名会报403；又比如应用程序池的“启用32位应用程序”选项，在64位系统上跑老版ASP组件时死活不生效，后来发现得手动把池的“常规”里的“启用32位应用程序”设为True，再重启池。这些坑不踩一遍，光看文档根本记不住。

现在回想，搭建过程其实只占三成时间，剩下七成都花在排错和调权限上。IIS就像个老实的管家，你把它该管的目录、端口、身份交代清楚，它就稳稳当当干活，但你要是漏了一句交代，它就板着脸给你报错。这次实训让我摸清了它的脾气，下次再配服务器，心里就有底了。