在IIS7中实现网站防盗链是保护网站资源不被其他非法网站直接引用的重要手段,能有效节省服务器带宽、提升网站安全性及用户体验，防盗链的核心原理是通过验证请求来源的合法性（即HTTP请求头中的Referer字段），判断是否允许访问特定资源，以下从技术原理、配置步骤、高级优化及注意事项等方面详细说明。
防盗链技术原理
当用户通过浏览器访问网页时,浏览器会自动在HTTP请求头中携带Referer字段，标明请求来源页面的URL，用户从A网站点击链接访问B网站的图片时，请求头中Referer字段即为A网站的地址，防盗链技术即通过检查该字段是否属于本站域名或授权域名，决定是否返回资源，若Referer为空（如直接访问资源文件）或为非授权域名，则服务器拒绝返回资源，返回403 Forbidden错误或自定义提示页面。
IIS7防盗链配置步骤
安装URL重写模块
IIS7本身不直接支持防盗链功能,需借助URL重写模块（URL Rewrite Module），该模块是微软官方提供的免费工具，支持正则表达式及条件规则，是实现防盗链的基础。
- 安装步骤：下载URL Rewrite Module 2.1（适用于IIS7及以上版本），运行安装程序，完成后IIS管理器中会新增“URL重写”功能模块。
配置URL重写规则
以保护网站图片资源（.jpg、.png、.gif等）为例，具体操作如下：
- 进入配置界面：在IIS管理器中选中目标网站，双击“URL重写”，点击“添加规则”。
- 选择规则模板：选择“入站规则”中的“请求阻止”模板，点击“下一步”。
- 设置条件：
- 匹配URL：选择“匹配的URL”为“特定路径”，路径模式输入图片扩展名，如
.(jpg|png|gif)$（需勾选“使用通配符”）。 - 添加条件：点击“添加条件”，选择“请求头”作为变量名，输入“Referer”，选择“匹配模式”为“正则表达式”，输入条件表达式：
- 允许本站访问：
^http(s)?://(www\.)?yourdomain\.com/.*（将yourdomain.com替换为自身域名）。 - 允许授权域名访问：如需允许其他域名，可追加条件，如
|^http(s)?://(www\.)?alloweddomain\.net/.*。
- 允许本站访问：
- 操作设置：选择“将请求重定向到”，输入自定义错误页面路径（如
/error.html），或选择“响应状态代码”为403。
- 匹配URL：选择“匹配的URL”为“特定路径”，路径模式输入图片扩展名，如
- 保存规则：点击“应用”，规则立即生效。
验证防盗链效果
- 本站访问测试：通过本站页面访问图片资源，应正常显示。
- 外部站点测试：在其他网站页面中直接引用该图片资源，图片应无法加载，或显示自定义错误页面。
- 直接访问测试：在浏览器地址栏直接输入图片URL，若Referer为空，可根据需求是否阻止（上述规则中未处理空Referer，需额外添加条件）。
处理空Referer场景
部分浏览器或工具（如下载工具、微信内置浏览器）发送请求时可能不携带Referer字段，需根据业务需求决定是否允许：
- 允许空Referer：在条件规则中添加
OR {HTTP_REFERER} = ""。 - 阻止空Referer：在条件规则中添加
AND {HTTP_REFERER} != ""。
高级优化与注意事项
使用MIME类型限制
针对特定资源类型（如视频、音频文件），可在IIS中配置MIME类型，限制非授权请求的响应格式，增强安全性。
结合IP白名单
若需限制仅特定IP可访问资源,可在“IP地址和域限制”功能中配置IP白名单，与防盗链规则结合使用。
性能优化
URL重写规则依赖正则表达式,复杂规则可能影响服务器性能，建议：
- 规则按优先级排序,高频匹配的规则置于前。
- 避免使用过于复杂的正则表达式,如非贪婪匹配可能降低效率。
定期更新规则
网站域名变更或新增授权域名时,需及时更新Referer条件表达式，避免误拦截。
测试与监控
配置完成后,需进行全面测试，确保正常资源访问不受影响，同时通过IIS日志监控异常请求，及时调整规则。
相关问答FAQs
Q1：防盗链配置后，为何本站部分页面也无法加载资源？
A：通常因Referer条件规则配置错误导致，检查规则中的正则表达式是否正确匹配本站域名（如是否包含http://或https://，是否忽略www子域名），可通过浏览器开发者工具查看请求头中的Referer值，对比规则中的匹配模式，调整条件表达式。
Q2：如何允许特定移动端APP或小程序访问资源？
A：移动端APP或小程序发送的HTTP请求可能不携带Referer字段，或使用自定义请求头，解决方案：
- 方案1：在防盗链规则中添加允许空Referer的条件（
{HTTP_REFERER} = ""），但需注意安全风险，可能被恶意利用。 - 方案2：要求开发者在请求头中添加自定义标识（如
X-Client-Type: APP），在IIS规则中通过检查该请求头字段判断合法性，例如条件表达式为{HTTP_X_CLIENT_TYPE} = "APP"。
