在同一台Windows服务器上同时部署Apache和IIS是很多开发测试环境的常见需求。IIS作为系统自带的Web服务组件，常用来运行ASP或ASP.NET应用；而Apache凭借丰富的模块生态，成为PHP、Python等项目的首选。两者默认都监听TCP 80端口，直接启动必然引发绑定失败。要解决这个问题，需要先理解操作系统对端口的分配规则，再通过合理的网络配置让它们各司其职。
端口冲突的底层原理与诊断方法
在TCP/IP协议栈中，一个套接字（socket）由“协议、本地IP、本地端口”三元组唯一确定。当IIS先启动并调用bind()函数占用0.0.0.0:80时，它表示监听本机所有网卡的80端口。此时Apache若也尝试绑定同样的地址和端口，系统会返回WSAEADDRINUSE错误，也就是常说的地址已被使用。这种冲突不是软件之间的排斥，而是操作系统网络栈的基本约束。
要确认到底是谁占用了目标端口，可以使用Windows内置的命令行工具。以管理员身份运行cmd，执行netstat -ano | findstr :80，能从输出中找到占用80端口的进程PID，再配合任务管理器或tasklist命令即可定位到是inetinfo.exe（IIS）还是httpd.exe（Apache）。有时系统自身的HTTP服务（如WinHTTP或SQL Reporting Service）也会抢占80，需要在服务管理器中手动停止相关依赖。
除了查看端口，还应检查两者配置文件中监听指令的差异。IIS通过“绑定”功能设置站点监听的IP和端口，而Apache在httpd.conf中使用Listen指令。只有明确双方当前绑定的具体三元组，才能制定无交叉的分配方案。很多初学者误以为改了Apache的端口就万事大吉，却忽略了IIS默认站点仍开着80，导致访问异常，这正是没有从底层理清绑定关系所致。
修改监听端口实现基础共存
最直接的解决思路是让其中一个服务改用非80端口。通常建议保留IIS的80端口，因为企业内部系统往往硬编码了标准HTTP地址，修改成本高；将Apache改为8080或88等端口更为现实。打开Apache的conf/httpd.conf，找到Listen 80这一行，修改为Listen 8080，同时确认虚拟主机配置中没有再次写死80端口。
修改后重启Apache服务，通过http://localhost:8080即可访问Apache下的站点。这种方案的优点是实现简单、不需要额外网络组件，适合本机开发或内网测试。缺点是外部用户访问时需显式带上端口号，不够友好；若Apache上部署的是正式对外项目，带端口的URL可能影响SEO和用户体验。此时可以结合路由器端口映射或反向代理来弥补。
如果选择修改IIS端口，则需进入IIS管理器，在“网站”节点下右键默认站点，编辑绑定，将http类型对应的端口由80改为8081。注意IIS 10之后引入了共享监听模式，若启用了“HTTP Server API”的全局监听，单改站点绑定可能不生效，还需用netsh http add urlacl调整URL保留项。因此改IIS端口往往比改Apache更繁琐，这也是推荐优先动Apache的原因。
# Apache httpd.conf 片段
# 原配置
# Listen 80
# 修改为监听8080
Listen 8080
<VirtualHost *:8080>
DocumentRoot "C:/Apache24/htdocs"
ServerName localhost
</VirtualHost>
基于IP绑定的多网卡隔离方案
当服务器配备多块网卡或配置了多个IP地址时，可以让IIS绑定到192.168.1.10:80，Apache绑定到192.168.1.11:80，从逻辑上彻底分开。Windows允许单网卡绑定多个IP，在网络适配器属性中手动添加即可。这样两个服务都使用标准80端口，只是服务的目标地址不同，对外看起来像两台独立Web服务器。
在Apache中通过Listen 192.168.1.11:80指定监听IP，IIS则在绑定设置里将主机名留空、IP地址选为192.168.1.10。这种方案对用户最透明，访问时无需记端口，也不需代理。但它要求网络环境支持多IP分配，且DNS或hosts文件需将不同域名指向对应IP。对于云服务器通常只给一个公网IP的场景，此方案适用性受限。
需要警惕的是，若Apache写成Listen 80而未指定IP，它会覆盖所有地址包括已被IIS占用的那个，冲突依旧。因此IP绑定方案的核心在于配置文件的精确性。下表对比了三种常见共存方式的基本特征：
| 方案 | 改动点 | 用户访问体验 | 适用环境 |
|---|---|---|---|
| 改Apache端口 | Apache Listen指令 | 需带端口号 | 单机开发、内网 |
| 改IIS端口 | IIS站点绑定 | 需带端口号 | 旧版IIS兼容 |
| 多IP绑定 | 双方均绑特定IP | 标准80无端口 | 多IP服务器 |
利用反向代理统一入口
更优雅的做法是在前端只用其中一个服务做代理，将特定路径或域名转发给另一个。例如保留IIS在80端口，安装Application Request Routing模块，把/php路径反向代理到Apache的8080端口。这样用户始终访问80，后台分工却清晰。Apache侧同样可用mod_proxy模块将某些请求转给IIS，取决于你更熟悉哪边。
以Apache开启代理为例，先在httpd.conf加载mod_proxy和mod_proxy_http，再写如下配置：将域名iis.site.com的请求全部转发到本地IIS的80端口。这种架构下，Apache成为流量调度层，特别适合需要统一HTTPS证书管理的场景。所有外部请求走标准443或80，内部转发用内网端口，安全性与可维护性都更高。
反向代理的代价是引入了额外网络跳转，微量增加延迟，且代理配置错误容易导致循环转发或报502。调试时应先确保后端服务在直连端口可访问，再逐步打开代理规则。对于高并发生产环境，还需调整代理模块的超时与连接池参数，避免成为瓶颈。总体而言，代理方案虽稍复杂，却是解决端口冲突同时兼顾体验的最佳实践。
# Apache 反向代理至 IIS 配置示例
LoadModule proxy_module modules/mod_proxy.so
LoadModule proxy_http_module modules/mod_proxy_http.so
<VirtualHost *:80>
ServerName iis.site.com
ProxyPass / http://127.0.0.1:80/
ProxyPassReverse / http://127.0.0.1:80/
</VirtualHost>
综合来看，Apache与IIS的端口冲突并非不可调和。从理解bind机制出发，依据服务器实际网络条件选用改端口、分IP或加代理，都能达成稳定共存。部署后建议用telnet或浏览器分别验证各入口，并养成修改配置前备份的习惯，便能轻松驾驭双Web服务环境。