内容摘要：我见过太多人把IIS当成一个“装完就忘”的东西。默认安装，默认设置，然后网站跑起来就再也不管了。直到某天凌晨三点，日志文件撑爆C盘，或者某个漏洞被扫到，才慌慌张张去查。 IIS的全称是Internet

我见过太多人把IIS当成一个“装完就忘”的东西。默认安装，默认设置，然后网站跑起来就再也不管了。直到某天凌晨三点，日志文件撑爆C盘，或者某个漏洞被扫到，才慌慌张张去查。

IIS的全称是Internet Information Services，Windows自带的Web服务器。它不像Nginx那样轻巧，也不像Apache那样遍地都是，但它在Windows生态里的地位无可替代。尤其是配合ASP.NET，那叫一个顺滑——你不需要折腾各种兼容性问题，微软把一切都给你焊死了。

去年我给一家制造业客户做内部系统迁移，他们的IT主管一脸嫌弃地说“IIS太老了”。结果呢？我打开他们的服务器一看，IIS版本还停留在6.0，跑在Windows Server 2003上。这不是IIS的问题，这是人的问题。你拿二十年前的版本说事，那当然又老又慢又危险。换成IIS 10，跑在Server 2019上，性能差距肉眼可见。

说个具体的坑。很多人配置IIS站点时，喜欢把应用程序池的“回收时间”设成默认的1740分钟——也就是29小时。听起来挺合理对吧？但如果你跑的是长时间运行的任务，比如报表生成、批量邮件发送，到了第29小时整，进程被强制回收，所有状态全没了。用户那边看到的就是“操作失败，请重试”。我见过不止一个项目栽在这上面。解决办法很简单：把回收时间设成凌晨三点，或者干脆禁用定期回收，改成内存阈值触发。

另一个容易忽略的是IIS的日志。默认配置下，日志文件按天切割，但不会自动清理。跑个三五年，你磁盘上会躺着几十GB的日志垃圾。更麻烦的是，日志里记录了所有请求的URL，包括查询字符串。如果你的网站有敏感参数，比如用户ID或者订单号，这些信息就赤裸裸地躺在文本文件里。懂行的人拿到服务器权限，翻日志就能摸清你的业务逻辑。我建议至少做两件事：一是把日志切割周期改成按小时，二是用脚本定期压缩归档，超过三十天的直接删除。

还有那个经典的“503 Service Unavailable”错误。新手看到这个就懵了，以为是代码问题，其实八成是应用程序池崩了。你打开事件查看器，会看到一堆“Faulting application name: w3wp.exe”的报错。这种时候别急着改代码，先看看是不是内存溢出，或者有没有死循环把CPU吃满。有一次我排查了半天，最后发现是某个第三方DLL在特定条件下抛异常，导致整个池子崩溃。换成独立应用程序池隔离那个站点，问题立刻消失。

IIS的管理界面其实挺直观的，但真正的高手都在用命令行。比如appcmd list sites能快速列出所有站点状态，appcmd recycle apppool /apppool.name:你的池名可以随时回收池子，不用点鼠标点半天。Windows的PowerShell也能干这事，但appcmd更直接，尤其适合写进自动化脚本里。

别被“微软的东西都很笨重”这种偏见带跑偏。IIS的模块化架构其实很灵活，你想砍掉哪些功能，直接在“服务器管理器”里去掉勾选就行。我见过有人把IIS精简到只剩静态文件服务和反向代理模块，跑起来比Nginx还省内存。当然，默认安装确实塞了一堆用不上的东西，比如FTP、WebDAV、CGI——这些留着就是给攻击者递刀子。

最后说个冷知识：IIS的默认站点路径是C:\inetpub\wwwroot，但很少有人会告诉你，这个目录的NTFS权限默认是“Users”组可读。也就是说，任何能登录这台机器的普通用户，都能直接读取你网站目录下的文件。如果你放了配置文件或者备份文件在下面，那就等于公开了。我每次部署都会把这个目录的权限改成只有“IIS_IUSRS”和“SYSTEM”可访问，其他一律拒绝。

IIS不性感，但它稳定、可靠、跟Windows深度集成。你只要花半天时间把配置调好，它能安安静静跑几年不出幺蛾子。怕就怕那种“能用就行”的心态，等到出了事才后悔当初没多看一眼设置。技术这东西，从来不亏待认真对待它的人。