SSRF漏洞的漏洞防御，本质上是防御一场关于“信任边界”的博弈。攻击者利用服务端发起请求的漏洞功能，把目标指向内网、防御云元数据或本机回环地址，漏洞穿透了开发者预设的防御“外部不可达”假设。最典型的漏洞案例是2019年Capital One数据泄露，攻击者通过SSRF访问了AWS的防御元数据服务（169.254.169.254），拿到了高权限角色的漏洞临时凭证，最终盗取1.06亿用户数据。防御这不是漏洞代码写得不够好，而是防御信任模型出了问题——服务器天然信任自己所在的网络环境。

防御的漏洞第一道闸门是校验URL本身。别只做黑名单过滤，防御那玩意儿形同虚设。漏洞攻击者用十进制IP（2130706433）、十六进制（0x7f000001）、短域名解析，甚至重定向跳转就能轻松绕过。更靠谱的做法是解析URL后，提取host字段，用DNS解析结果逐一比对——如果目标IP落在内网段（10.0.0.0/8、172.16.0.0/12、192.168.0.0/16）、回环地址（127.0.0.0/8）、链路本地地址（169.254.0.0/16）或者IPv6的::1，直接拒绝。但注意，DNS重绑定攻击能让你第一次解析通过校验，第二次解析却指向内网。所以光校验一次不够，要在实际发起连接时再解析一次，然后对比两次结果是否一致。不一致就阻断。

第二道闸门是限制协议和端口。SSRF不光是HTTP，还能用file://、gopher://、dict://等协议读取本地文件或打内网Redis。如果业务只需要HTTP，就在代码层面强制只允许http和https协议，其他一律抛异常。端口方面，别默认开放所有端口。有些业务确实需要访问外部服务的特定端口，那就白名单化——只允许80、443，最多加个8080。曾经有团队允许任意端口，结果攻击者用SSRF打内网未授权访问的Elasticsearch，9200端口上数据被拖了个干净。

第三道闸门是网络层面的隔离。这是最容易被忽视的。即便代码层校验全做了，攻击者仍然可能找到你没想到的绕过路径。所以干脆在架构上把应用服务器和内部敏感资源彻底隔开——用防火墙规则禁止应用服务器主动访问内网IP段，或者部署在独立的VPC子网里，安全组只放行必要的出站流量。云环境里，给ECS实例的IAM角色配上最小权限，别让元数据服务的临时凭证能访问太多资源。就算SSRF打穿了元数据，拿到的凭证也只能访问一个没用的S3桶，那损失就小多了。

还有个实战细节：重定向处理。很多开发者校验完初始URL就放心了，结果服务器跟着302跳转去了内网。所以每次重定向都要重新执行一遍校验逻辑，不能只校验第一次。另外，响应内容别直接回显给用户。有些场景确实需要展示远程内容（比如图片抓取），那就把响应先存到本地，再通过代理输出，别把原始响应体直接透传，否则攻击者能用它探测内网端口开放情况——响应时间、状态码、响应体差异都是信息。

最后说点主观判断。很多SSRF漏洞的根因不是技术，而是产品经理拍脑袋要功能——让用户输入URL去抓取页面、做网站截图、或者验证链接有效性。这些功能天生就是SSRF的温床。如果业务非要这么做，别自己造轮子，用现成的、经过安全验证的库，比如Google的safe-url或专门的SSRF防护中间件。实在不行，把请求转发到一个独立的代理服务上，这个代理部署在完全隔离的网络里，就算被攻破，影响面也有限。防御SSRF没有银弹，每一层都能被单独绕过，但叠加起来，攻击成本就高到他们放弃。