如果你的网站是用 Vue.js 或 React 构建的单页应用（SPA），域名防红的策略与传统的多页面网站有很大不同。SPA 的内容是通过前端 JavaScript 动态渲染的，这与传统 PHP 网站的服务端渲染完全不同，这给安全检测爬虫的识别带来了特殊挑战。无相盾团队在这篇文章中分享 SPA 防红的实战策略。

SPA 的防红难点

问题一：爬虫看到的是空壳

传统的 SPA 在服务端返回的 HTML 只是一个空壳——真正的内容是通过 JavaScript 在浏览器中渲染的。一些简单的爬虫可能只抓取到这个空壳 HTML，根本看不到你的营销内容，这种情况下反而不容易被标红。

但问题是：Google Safe Browsing 的爬虫具备 JavaScript 渲染能力。它可以像真实浏览器一样执行 JS 并看到完整的页面内容。所以不要指望「SPA 就不会被标红」。

问题二：路由完全在前端

SPA 使用前端路由（Vue Router、React Router），URL 的变化不会触发服务器请求。这意味着你无法在服务端根据 URL 来做分流——因为所有页面请求最终都指向同一个 index.html。

问题三：API 请求暴露

SPA 的数据通常通过 API 接口获取。即使你在页面层面做了防红，API 返回的数据也可能被安全系统检测到。

SPA 防红的解决方案

方案一：SSR 预渲染 + 服务端过滤（推荐）

最彻底的方案是将 SPA 升级为 SSR（服务端渲染）或使用预渲染。

Vue.js 可以使用 Nuxt.js，React 可以使用 Next.js。在 SSR 模式下，页面在服务端渲染后返回完整的 HTML，你可以在服务端的渲染环节中加入无相盾的过滤逻辑。

这种方案的好处是：

方案二：反向代理层过滤

如果你不想改动 SPA 的代码，可以在反向代理（Nginx）层面加入过滤逻辑：

# Nginx 配置示例
server {
    listen 443 ssl;
    server_name yourdomain.com;
    
    # 无相盾过滤层
    location / {
        # 先经过无相盾的过滤判断
        set $target "spa";
        
        # 如果是安全检测机器人，返回安全页面
        if ($http_user_agent ~* "Googlebot|bingbot|SafeBrowsing") {
            set $target "safe";
        }
        
        # 根据判断结果代理到不同的后端
        proxy_pass http://127.0.0.1:3000/$target;
    }
}

注意：上面的 Nginx 配置只是一个简化示例。实际部署中，仅靠 User-Agent 匹配是远远不够的，你需要无相盾完整的三层验证。

方案三：Cloudflare Workers

如果你使用 Cloudflare CDN，可以通过 Cloudflare Workers 在边缘节点实现过滤。Workers 可以在请求到达你的源站之前进行 Bot 检测，并根据结果返回不同的内容。

Vue.js 项目的具体实施

以 Vue 3 + Vite 项目为例：

如果使用 Nuxt 3（推荐）

在 server/middleware/ 目录下创建防红中间件，这样所有请求都会先经过过滤层。具体的中间件代码参考本系列中的 Node.js 域名防红方案文章。

如果保持纯 SPA

纯 SPA 无法在前端做有效的防红（因为前端代码对所有人都是透明的）。你必须在服务端或反向代理层面实现过滤。最简单的方式是在托管 SPA 静态文件的服务器（Nginx、Apache）前面加一层无相盾的过滤。

React 项目的具体实施

如果使用 Next.js（推荐）

Next.js 的 middleware.ts 文件可以在边缘运行，是做防红过滤的理想位置。具体的实现方式参考前文。

如果使用 Create React App

CRA 构建的纯 SPA 同样需要在服务端层面解决。将构建产物部署到一个带有无相盾过滤层的 Node.js 或 Nginx 服务器上。

API 请求的防护

别忘了保护你的 API 接口。安全检测爬虫可能会直接请求你的 API 端点。解决方案：

SPA 的域名防红比传统网站更复杂，但有了正确的策略和工具，同样可以实现有效的防护。更多技术方案，欢迎访问无相盾官网。