---
title: "采集器 SSRF 防护：为什么不能直接请求客户注册的 URL？"
slug: "crawler-ssrf-boundary"
language: "zh-cn"
tags: ["ssrf 방어","아키텍처 노트","sag 기술","수집 아키텍처"]
created: "2026-10-06T08:00:00.000Z"
published: "2026-10-08T10:17:44.829Z"
updated: "2026-10-08T10:17:44.829Z"
sample: false
---

# 采集器 SSRF 防护：为什么不能直接请求客户注册的 URL？

## 什么是 SSRF 防护？

**这是一项防护措施，旨在防止用户提供的地址将请求引向内部服务或不允许访问的网络。** 本文将 SSRF 防护视为输入、转换和输出各自承担的责任，而不只是一个功能名称。要让分析结果值得信赖，必须明确资料的来源、已进行的检查，以及结论的适用范围。

## 为什么需要这项技术？

看似正常的地址也可能在重定向或名称解析后指向内部地址。为了分析便利而开放网络边界，会动摇整个租户的信任基础。

## 设计原则与数据流

在每个请求阶段检查 URL 规范化、允许的协议和主机、重定向目标，以及对内部地址的阻止情况。仅凭一次字符串检查，不能认为策略已执行完毕。

> **已注册 URL** → **网络边界验证** → **获准的 HTTP 请求**

每个阶段都不应把前一阶段的成功称作下一阶段的成果。连续记录资料标识符、时间范围和验证状态，有助于定位遗漏和错误发生的位置，并确定需要重新检查的范围。

## 与 SAG 架构的关联

SAG 的域名注册与采集以获准来源为基准。本文的扩展指南是：设计额外的采集适配器时，也应维持相同的网络边界。

SAG 的运营价值在于将这种关系与页面、问题、比较结果和改进工作联系起来。客户不必只查看数字，还可以一并审查需要补充完善的对象及其判断依据。需要额外应用的模式，应以相应段落的范围为准来理解。

## 说明性示例与判断标准

作为说明，如果外部产品地址重定向到内部管理地址，就不能只因为外部地址通过了初始验证便放行。必须验证下一个目标，或中止请求。

上述示例用于说明结构和计算，并非特定客户的实测成果。实际报告应关联所选时间范围、对象、观测条件和原始记录，才能再次核实相同的判断。

## 实务验证清单

| 流程阶段 | 检查项目 |
| --- | --- |
| 已注册 URL | 每次重定向都重新验证目标 |
| 网络边界验证 | 确认内部地址和环回地址已被阻止 |
| 获准的 HTTP 请求 | 限制超时时间和响应大小 |

请确认在正常输入之外，对于空资料、重复资料以及条件不同的资料，是否仍能保持相同含义。将验证项目纳入工作完成标准，可以缩小功能说明与实际运营之间的差距。

## 局限性与应用注意事项

阻止策略必须结合实际托管网络和 DNS 环境进行验证。本文提供的是防护设计标准，并不表示已获得适用于所有环境的安全认证。

## 研究资料与官方文档

- [OWASP SSRF 防护指南](https://cheatsheetseries.owasp.org/cheatsheets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet.html) — 用于审查用户输入所触发的服务器请求的信任边界。

外部资料是上述设计主题的背景材料，并不认证 SAG 的所有实现或客户成果。本文的应用解读和说明性示例依据 SAG 的运营架构整理。资料核验日期：2026-10-06。

## 延伸阅读与功能确认

- [相关架构笔记](/ko/blog/secret-handling-integration-metadata)
- [体验与 SSRF 防护相关的服务](/ko/preview/domain?scenario=cream)
- [按功能分类的 FAQ](/zh-cn/faq)
- [咨询导入范围](/ko#inquiry)


## 如何继续了解这项技术

沿着 HTML ZIP·站点地图 → 规范化 → 页面版本 → 依据记录的流程阅读。

- [数据成为依据的过程](/ko/blog?tag=%EC%88%98%EC%A7%91%20%EC%95%84%ED%82%A4%ED%85%8D%EC%B2%98)
- [功能说明 FAQ](/zh-cn/faq)