[toc]
记一次 Windows Server IIS HTTPS/远程桌面同时不通的排查与复盘
一个 WAS 服务停止，连锁引爆火绒主动防御 + Windows 防火墙内置规则失效，最终靠手动添加入站规则解决。
通用排查方法论可以参考其他笔记
一、故障快照
| 维度 | 现象 |
|---|---|
| 核心故障 | 本地无法访问 HTTPS（443），远程桌面（3389）连接失败 |
| 可用的 | HTTP（80）、ping 正常 |
| 对比测试 | 手机流量同样无法访问 HTTPS → 排除本机 IP 封禁 |
| 触发节点 | 本地尝试直连线上 SQL Server（1433）后 |
| 最终解决 | Windows 高级防火墙手动添加 443、3389 TCP 入站允许规则 |
| 类别 | 详情 |
|---|---|
| 云服务器 | 阿里云 ECS，Windows Server 2012 |
| Web 服务 | IIS + WAS |
| 数据库 | SQL Server 2012 |
| 安全软件 | 火绒安全（全防护模块开启） |
| 云安全组 | 已放行 80 / 443 / 3389 |
二、故障时间线
T0 正常状态
├─ HTTP/HTTPS/RDP 全部正常
├─ 火绒联网控制处于"自动信任"状态
└─ Windows 防火墙依赖安装 IIS/远程桌面时自动生成的内置规则
T1 触发：WAS 服务异常停止
└─ 原因未明确（内存不足 / 系统更新 / 火绒干预 之一）
T2 连锁反应
├─ IIS 工作进程 (w3wp.exe) 被回收
├─ http.sys 内核层 SSL 证书绑定被清除
└─ 443 端口虽在监听，但无有效证书
T3 策略突变
├─ 火绒检测到进程状态异常 → 收紧联网控制策略 → 清除自动放行
└─ IIS/WAS 重启触发系统防火墙重载 → 内置入站规则被禁用/覆盖
T4 全面拦截：443、3389 入站被拦截，故障显现
T5 排查（约 2 小时）
├─ ✅ 检查阿里云安全组 → 正常
├─ ✅ 发现 WAS 停止 → 启动 + iisreset
├─ ✅ 发现 SSL 证书绑定丢失 → 重新导入证书 + IIS 配置 HTTPS 绑定
├─ ❌ 以上操作均未恢复（流量在防火墙层就被拦截）
└─ ✅ 手动添加防火墙入站规则 → 问题解决二点五、根因分析：真正的导火索
为什么本地远程连接线上数据库会引发这场故障？
表面看是 WAS 服务停止，但更深层的原因是：本地电脑通过公网直连服务器的 SQL Server 1433 端口。
这个操作在本案例中制造了双重风险：
本地电脑 → 公网 → 服务器 1433 端口 → SQL Server
↓
1. 大量数据库流量冲击服务器，可能触发 WAS 内存压力
2. 来自外部的高频 1433 连接被火绒判定为"可疑行为"
→ 火绒主动防御介入 → 检测到系统状态异常 → 收紧安全策略为什么直连线上数据库是危险操作：
| 风险 | 说明 |
|---|---|
| 安全软件误判 | 外部 IP 大量连接数据库端口，容易被火绒/360 等判定为暴力破解或入侵行为，触发自动防御 |
| 性能冲击 | 本地查询可能产生大量结果集，通过公网传输挤占服务器带宽和内存，间接导致 WAS 等关键服务资源不足 |
| 防火墙状态变更 | 高频连接可能触发系统防火墙的连接跟踪表溢出，或触发安全软件的动态端口封禁 |
| IP 被拉黑 | 本地公网 IP 可能被安全软件加入临时黑名单——这解释了为什么故障后连远程桌面也连不上 |
核心教训：本地开发/测试绝不应直连线上数据库。应通过 VPN/堡垒机/SSH 隧道等安全通道访问，或在本地搭建测试库。
三、核心疑问
Q1：为什么之前无需手动配置也能正常访问？
Windows Server 安装 IIS 角色时自动创建了「万维网服务(HTTP 流入量)」「万维网服务(HTTPS 流入量)」内置入站规则；开启远程桌面时自动创建「远程桌面连接」规则。火绒联网控制也对系统服务自动建立信任。所以看不到手动规则，但一直在被自动放行。
Q2：为什么会突然出现端口拦截？
WAS 停止 → IIS 进程回收
→ 火绒检测到异常 → 清除自动信任
→ IIS/WAS 重启触发防火墙重载 → 内置规则失效
→ 443 + 3389 同时被拦截Q3：为什么只加防火墙入站规则就解决了？
手动添加的是显式永久规则，优先级高于系统内置规则，不受火绒策略变更影响。
Q4：SSL 证书、IIS HTTPS 绑定是不是多余操作？
不多余。故障分两层：网络层（防火墙拦截，本次故障点）和应用层（证书/绑定）。流量在网络层就被拦截所以证书操作看不到效果，但网络层通了之后缺证书浏览器照样报错。两者的修复都必要，只是顺序错了。
Q5：火绒到底有没有影响？
火绒是触发诱因。直接拦截发生在系统防火墙，但系统内置规则是火绒主动防御检测到异常后才失效的。不对火绒配置优化，后续服务重启大概率复现。
关于"学习模式"
本文中"学习模式"是通俗叫法，火绒界面里对应的实际功能是联网控制——对已知程序自动放行，进程变化后重新判定。WAS 停止后 w3wp.exe 被回收重建，火绒不认识"新的"w3wp.exe，默认策略可能是"阻止"。
火绒验证四步法
第 1 步 [10 秒]：系统托盘 → 右键火绒图标 → "暂停保护" → 选 10 分钟 → 测试
→ 通了 = 火绒拦截；不通 = 与火绒无关
第 2 步 [1 分钟]：火绒主界面 → ☰ → "安全日志" → "网络防护"
→ 查找 443 / 3389 拦截记录
第 3 步 [1 分钟]：火绒主界面 → "防护中心" → 看 "联网控制" 是否开启
第 4 步 [1 分钟]：火绒主界面 → "防护中心" → "IP 黑名单"
→ 查看办公公网 IP 是否被加入四、排查过程中的操作有效性
| 序号 | 操作 | 效果 |
|---|---|---|
| 1 | 检查阿里云安全组 | ✅ 排除云平台拦截 |
| 2 | netstat 查端口监听 | ✅ 确认 443 在 LISTENING |
| 3 | telnet 测试端口可达性 | ✅ 精准定位：网络层拦截 |
| 4 | 启动 WAS + iisreset | ⚠️ 恢复进程，解不了网络层 |
| 5 | 导入 SSL 证书 + IIS HTTPS 绑定 | ⚠️ 修复应用层，流量被拦截无法生效 |
| 6 | 临时关闭防火墙测试 | ⚠️ 验证用（本次无效） |
| 7 | 手动添加防火墙入站规则 | ✅✅ 核心解决 |
教训：应 L1→L2→L3→L4 逐层排查，本次在 L4（证书/IIS）花了大量时间，真正问题在 L2。
五、火绒配置修复（具体操作）
以下操作均在 VNC/远程桌面图形界面中完成。
方案一：关闭联网控制（推荐）
火绒主界面 → "防护中心" → "联网控制" → 关闭关闭后火绒仍保留病毒查杀等核心防护。
方案二：添加信任程序
火绒主界面 → ☰ → "安全设置" → "系统防护" → "联网控制"
→ 将以下程序设为 "自动允许"：
- C:\Windows\System32\inetsrv\w3wp.exe
- C:\Windows\System32\svchost.exe清空 IP 黑名单
火绒主界面 → "防护中心" → "IP 黑名单" → 删除办公 IP导出配置备份
火绒主界面 → ☰ → "安全设置" → "导出配置" → 保存 .json 文件六、防火墙规则持久化
在 PowerShell（管理员）中执行：
powershell
New-NetFirewallRule -DisplayName "Allow HTTP 80" -Direction Inbound -Protocol TCP -LocalPort 80 -Action Allow
New-NetFirewallRule -DisplayName "Allow HTTPS 443" -Direction Inbound -Protocol TCP -LocalPort 443 -Action Allow
New-NetFirewallRule -DisplayName "Allow RDP 3389" -Direction Inbound -Protocol TCP -LocalPort 3389 -Action Allow七、WAS 服务自动恢复
cmd
sc config WAS start= auto
sc config W3SVC start= auto
sc failure WAS reset= 300 restart= 60000 actions= restart/5000/restart/20000/restart/60000
sc failure W3SVC reset= 300 restart= 60000 actions= restart/5000/restart/20000/restart/60000八、常用命令速查（本案例相关）
powershell
# 端口监听
netstat -ano | findstr ":443"
# 服务状态
sc query WAS
sc query W3SVC
# 重启 IIS
iisreset
# SSL 证书绑定
netsh http show sslcert
# 导入证书
Import-PfxCertificate -FilePath "证书.pfx" -CertStoreLocation Cert:\LocalMachine\My -Password (ConvertTo-SecureString "密码" -AsPlainText -Force)| 用途 | 路径/命令 |
|---|---|
| 高级防火墙 | wf.msc |
| IIS 管理器 | inetmgr |
| 证书管理器 | certlm.msc |
| IIS 日志 | C:\inetpub\logs\LogFiles\ |
九、防范注意事项
9.1 绝对不要做的事
| 危险操作 | 后果 | 替代方案 |
|---|---|---|
| 本地直连线上数据库 | 触发安全软件误判、IP 被拉黑、性能冲击，可导致大面积服务中断 | 通过 VPN 连接内网后访问；或使用 SSH 隧道；或本地搭建测试库 |
| 随意重启 WAS/IIS 服务 | 可能丢失 SSL 证书绑定、触发防火墙规则重载、引发安全软件重新判定 | 先备份证书绑定信息（执行 netsh http show sslcert > backup.txt），再操作 |
| 在生产服务器上临时关闭防火墙/安全软件后忘记恢复 | 服务器长时间暴露在无防护状态 | 关闭时设定时器，确认恢复后检查规则完整性 |
| 凭感觉跳层排查（如直奔应用层调证书） | 浪费时间，问题在别层根本看不到效果 | 严格按 L1→L2→L3→L4→L5 顺序排查 |
9.2 日常维护清单
| 频率 | 检查项 | 操作 |
|---|---|---|
| 每日 | WAS/W3SVC 服务状态 | 任务计划程序执行健康检查脚本 |
| 每周 | 火绒安全日志 | 查看网络防护拦截记录，清理误拦 |
| 每月 | SSL 证书到期时间 | 执行 certutil -store my 查看，提前 30 天续期 |
| 每月 | 防火墙入站规则完整性 | wf.msc 确认 80/443/3389 规则存在且启用 |
| 每次变更前 | 配置备份 | 防火墙规则导出、证书备份、火绒配置导出 |
9.3 安全访问线上数据库的正确方式
错误做法：
本地 Navicat/SSMS → 公网 → 服务器 1433 端口 → 直接连接
正确做法（按推荐优先级）：
1. 阿里云 VPN 网关 → 内网 IP 连接（最稳定）
2. 服务器安装 OpenVPN/WireGuard → 隧道内连接（免费）
3. SSH 端口转发：执行 ssh -L 1433:127.0.0.1:1433 user@server
→ 本地连 127.0.0.1:1433（临时方案）
4. 本地搭建相同结构的测试库（开发阶段推荐）