1. 项目概述：当IndexTTS2 WebUI遇上CC攻击

最近在折腾一个文本转语音（TTS）的WebUI项目，用的是开源的IndexTTS2。这东西效果确实不错，本地部署后，无论是生成有声书还是做点创意内容，都挺方便的。但问题很快就来了——我把WebUI的地址分享给几个朋友一起用，没过多久，服务器就卡得不行，CPU和内存直接拉满，页面根本打不开。一查日志，好家伙，全是来自不同IP的、高频的、针对登录接口和合成接口的请求。典型的CC攻击（Challenge Collapsar，挑战黑洞，一种通过大量合法请求耗尽服务器资源的攻击方式）找上门了。

对于一个部署在公网、资源有限（比如我用的2核4G云服务器）的AI应用来说，这种攻击简直是灾难。IndexTTS2本身是个计算密集型应用，一次语音合成就会消耗不少CPU和内存。攻击者不需要攻破你的系统，只需要用脚本模拟大量用户同时请求合成，就能轻松让你的服务瘫痪，真正的用户反而用不了。

手动写Nginx规则、用iptables封IP？太麻烦，而且攻击IP经常变，防不胜防。这时候，专业的事情就得交给专业的工具。我第一时间想到了360网站卫士（现在也叫360云防护或360网站安全防护）。它本质上是一个SaaS化的Web应用防火墙（WAF），提供包括CC防护在内的多种安全能力，最关键的是，对于个人站长或小规模应用，它有免费套餐，足够应对一般的恶意流量。

所以，这个项目的核心就是：如何将开源的IndexTTS2 WebUI服务，通过配置360网站卫士，构建起一道有效抵御CC攻击的防线，确保服务的稳定性和可用性。这不仅仅是加个“盾牌”，更涉及到对Web应用流量特点的理解、防护策略的精细化调优，以及防护效果的真实验证。下面，我就把这次完整的配置、踩坑和优化过程分享出来。

2. 防护体系设计与核心思路拆解

在动手配置之前，我们必须先理清防御的逻辑。盲目开启所有防护可能会误杀正常用户，或者影响WebUI的功能。我们的目标是精准防护，既拦住恶意流量，又不妨碍正常使用。

2.1 理解攻击目标：IndexTTS2 WebUI的脆弱点

IndexTTS2的WebUI，无论是Gradio还是自定义的Flask/FastAPI界面，通常有几个关键接口：

1. 根路径（/）：前端页面入口。
2. API合成接口（如/api/tts或/run/predict）：这是核心，接收文本参数并返回音频，计算开销最大。
3. 静态资源路径（/static/,/file=等）：加载JS、CSS、模型文件等。
4. WebSocket连接（如果有实时流式输出）：用于推送合成进度或结果。

CC攻击者最可能攻击的就是第2点——合成接口。通过高频、并发的请求，直接冲击服务器的计算资源。其次，攻击根路径和静态资源，虽然消耗带宽和连接数，但不如攻击计算接口致命。

2.2 360网站卫士的防护逻辑

360网站卫士的CC防护，核心是基于“频率”和“特征”的智能识别与拦截：

• 频率控制：在特定时间窗口内（如10秒、1分钟），如果来自同一IP（或会话）对某一URL的请求次数超过阈值，则将该IP加入黑名单一段时间（如5分钟、1小时）。
• 人机验证：对于可疑流量，可以弹出验证码（如滑动拼图、点选文字），真人用户可以通过，而脚本程序则难以绕过。
• 会话验证：检查请求是否携带合法的Cookie或会话标识，缺乏有效会话的请求可能被直接拦截。
• 智能引擎：基于360的安全大数据，识别已知的攻击工具、代理IP池和恶意行为模式。

我们的策略就是利用这些能力，为IndexTTS2 WebUI量身定制防护规则。

2.3 整体防护架构

最终的防护架构非常简单清晰：

用户浏览器 <---> [360网站卫士防护节点] <---> [你的云服务器（运行IndexTTS2 WebUI）]

1. 你将你的域名（例如tts.yourdomain.com）的DNS解析指向360网站卫士提供的CNAME地址。
2. 所有用户访问流量首先到达360的全球加速和清洗中心。
3. 360的防护引擎根据你设定的规则，对流量进行实时检测和过滤。
4. 只有被判定为“合法”或“安全”的流量才会被转发到你真实的服务器IP。
5. 被判定为恶意的请求（如CC攻击）会在360的节点上被拦截或挑战，根本不会到达你的服务器。

这种方式的优点是“零部署”，无需在你的服务器上安装任何代理或模块，不消耗服务器自身资源进行防护。

3. 核心配置解析与实操要点

接下来，我们进入具体的配置环节。假设你已经拥有一个域名，并且IndexTTS2 WebUI已经成功部署在服务器上，可以通过http://你的服务器IP:端口访问。

3.1 接入360网站卫士

1. 注册与添加站点：

   • 访问360网站卫士官网，用手机号注册并登录。
   • 在控制台找到“添加网站”或“站点管理”，输入你的完整域名（如tts.yourdomain.com）。
   • 选择套餐。对于个人项目，“免费版”通常足够，它提供了基础的CC防护、Web攻击防护和加速功能。

2. DNS解析配置（关键步骤）：

   • 添加站点后，360会为你分配一个CNAME记录值，形如xxxxx.s.360wzb.com。
   • 你需要登录你的域名注册商或DNS服务商（如阿里云万网、腾讯云DNSPod等）的管理后台。
   • 找到你域名的解析设置，将原来指向你服务器IP的A记录删除或暂停。
   • 新增一条CNAME记录：
     • 主机记录：tts（如果你要用tts.yourdomain.com）或@（如果你要用根域名yourdomain.com）
     • 记录类型：CNAME
     • 记录值：粘贴360提供的那个CNAME地址。
   • 保存设置。DNS生效需要时间，通常几分钟到几小时不等。

3. 验证与等待生效：

   • 在360控制台，站点状态会显示“待生效”。等DNS完全生效后，状态会变为“正常”或“已防护”。
   • 此时，访问你的域名tts.yourdomain.com，流量已经过360节点。你可以通过在线工具（如ping或dig）查询你的域名，确认解析到的IP是360的节点IP，而非你的服务器IP。

注意：在DNS切换期间，你的WebUI服务会短暂不可用（直到360解析生效）。建议在业务低峰期操作。生效后，务必通过域名访问来测试WebUI功能是否正常。

3.2 CC防护策略精细化配置

接入只是第一步，精细化的策略才是防护效果的关键。进入360控制台，找到“安全防护”或“CC防护”设置模块。

3.2.1 开启基础CC防护

一般会有一个总开关，先把它打开。免费版通常提供“标准”或“宽松”模式。初期可以选择“标准模式”。

3.2.2 自定义防护规则（重中之重）

这是针对IndexTTS2 WebUI进行“精准防护”的核心。我们需要创建针对性的规则，而不是全局一刀切。

1. 创建规则：在CC防护设置里，找到“自定义规则”或“精准防护”。

2. 规则配置示例：

   • 规则名称：防护-IndexTTS2-API接口
   • 匹配条件：
     • URL路径：选择“包含”或“正则匹配”。例如，如果你的合成接口是/api/tts，就填/api/tts；如果是Gradio默认的/run/predict，就填/run/predict。这是最关键的过滤条件。
   • 防护动作：
     • 检查周期：10秒（这是一个合理的观察窗口）
     • 访问次数阈值：15次（这意味着10秒内同一会话/IP访问该接口超过15次，即触发防护）
     • 防护动作：选择“人机验证（验证码）”。这是首选！对于API接口，单纯的“拦截”可能会误伤一些正常但稍快的用户（比如快速测试）。验证码可以很好地识别真人。
     • 惩罚时间：300秒（触发后，该会话/IP在5分钟内访问此路径都需要验证码）
   • 高级设置（可选但建议）：
     • 匹配范围：选择“全局生效”。
     • 优先级：设置为“高”。确保这条规则优先于其他通用规则。

3. 创建第二条规则（防护静态资源）：

   • 规则名称：防护-静态资源
   • 匹配条件：URL路径“包含”/static/或/file=。
   • 防护动作：检查周期60秒，访问阈值100次，动作可选择“拦截”。因为静态资源请求频率本应较低，高频请求很可能是攻击或爬虫，直接拦截影响不大。
   • 惩罚时间：600秒。

3.2.3 会话设置优化

IndexTTS2的WebUI通常依赖会话（Session）来维持状态。为了让人机验证和频率统计更准确，需要在360控制台确认或设置“会话设置”。

• 会话识别方式：确保360能正确识别你WebUI框架的会话Cookie。通常是sessionid、gradio_session_id等。如果360自动识别不准，可以手动添加Cookie名称。
• 会话超时时间：可以设置为与你的WebUI会话超时时间一致，例如1800秒（30分钟）。

3.3 其他辅助安全设置

1. Web应用防火墙（WAF）：开启基础的WAF防护，可以防御SQL注入、XSS等常见Web攻击。虽然IndexTTS2的输入可能相对简单，但开启无害。
2. IP黑白名单：如果你有固定的合作IP或已知的攻击IP段，可以在这里设置。例如，你可以将你自己的办公网络IP加入白名单，确保自己永远不会被拦截。
3. 访问日志：开启日志功能。当遇到攻击或误拦截时，日志是排查问题的唯一依据。你可以看到每个被拦截或验证的请求详情，包括IP、URL、动作和原因。

4. 实操过程与核心环节实现

配置完成后，真正的考验在于测试和调优。防护策略不是设完就一劳永逸的。

4.1 防护效果验证测试

我们不能等真的被攻击了才看效果。需要主动进行“友好”的压测来验证。

1. 工具准备：使用Apache Bench (ab)或wrk这类轻量级HTTP压测工具。在另一台机器上运行。
2. 模拟CC攻击：针对你的合成接口进行高频并发请求。

   # 示例：10个并发，总共发送1000个请求到合成接口 ab -n 1000 -c 10 -H "Content-Type: application/json" -p post_data.json http://tts.yourdomain.com/api/tts

   post_data.json文件里需要包含你API所需的JSON参数。
3. 观察现象：
   • 在压测过程中：迅速刷新360网站卫士的控制台“安全报表”或“CC防护”页面，你应该能看到触发的防护事件数量急剧上升。
   • 在压测机器上：很快，ab命令的返回结果中，会出现大量的非200状态码。如果是“验证码”动作，可能会返回一个包含验证码页面的HTTP 200响应（但内容不是音频）；如果是“拦截”，则会返回403或405等错误。
   • 在你的服务器上：通过top或htop命令查看，CPU和内存的使用率应该保持平稳，不会因为压测而飙升。这才是防护成功的直接证据——攻击流量被挡在了门外。

4.2 误拦截排查与策略调优

防护太严会误伤正常用户。你需要模拟正常用户的行为进行测试。

1. 正常操作流程测试：
   • 用浏览器正常访问WebUI页面。
   • 输入文本，点击“合成”按钮。观察是否弹出验证码。对于低频的、手动的用户操作，绝对不应该弹出验证码。
   • 连续快速点击几次合成按钮（模拟用户急躁的操作）。根据你设置的阈值（如10秒15次），可能在点击第5、6次时触发验证。这时需要判断：这个阈值对真实用户是否合理？
2. 调优策略：
   • 如果正常操作频繁触发验证：说明阈值设得太低。可以尝试将“检查周期”从10秒延长到30秒，或将“访问次数阈值”从15次提高到25次。核心原则是：阈值要高于正常用户的最高可能操作频率，但要低于自动化脚本的最低攻击频率。
   • 区分API和页面：确保你的防护规则只针对耗资源的API（/api/tts），而不要应用到前端页面（/）。否则用户连页面都打不开。
   • 利用“白名单”或“宽松模式”：360通常提供“搜索引擎IP白名单”、“CDN IP白名单”等，确保这些基础设施的访问不受限。对于已知的、可信的API调用来源（比如你自己的另一个服务），可以将其IP加入白名单。

4.3 监控与告警设置

防护生效后，需要建立监控机制。

1. 利用360控制台仪表盘：定期查看“攻击概览”、“CC攻击拦截TOP”等图表，了解攻击趋势和主要攻击源。
2. 设置告警（如果免费版支持）：在控制台找到告警设置，可以设置当CC攻击拦截次数在短时间内超过某个数值时，通过邮件、短信或微信通知你。这样你就能第一时间感知到攻击事件。
3. 服务器基础监控：在你的云服务商控制台（如阿里云云监控、腾讯云云监控），为你的服务器设置CPU使用率、内存使用率、网络流入流出的告警。即使360拦住了大部分攻击，监控服务器自身状态也是双重保险。

5. 常见问题与排查技巧实录

在实际配置和使用过程中，我遇到了不少坑。这里总结一下，希望能帮你省点时间。

5.1 问题一：配置后网站无法访问或显示“连接被重置”

• 可能原因：
  1. DNS未生效或生效错误：你的本地DNS缓存未更新，或者域名解析未正确指向360的CNAME。用nslookup tts.yourdomain.com或dig tts.yourdomain.com命令检查解析结果。
  2. 360节点回源失败：360无法连接到你的真实服务器。检查你的服务器防火墙（如iptables、firewalld或云服务商安全组）是否放行了360的回源IP段。你需要在360网站卫士的控制台找到“回源设置”或“源站配置”，里面会列出它们使用的IP段，务必在你的服务器防火墙中允许这些IP访问你的WebUI端口（如7860）。
  3. SSL/TLS证书问题：如果你在360侧开启了HTTPS（强制跳转），但你的源站IndexTTS2 WebUI只支持HTTP，会导致回源失败。在360的“SSL证书”设置中，选择“HTTP回源”模式。
• 排查步骤：
  1. 首先确认DNS解析正确。
  2. 在服务器上使用netstat -tunlp | grep :端口号确认WebUI进程在监听。
  3. 临时关闭服务器防火墙进行测试（仅用于排查，测试后立即恢复）。如果关闭后能访问，问题就在防火墙规则。
  4. 查看360控制台的“访问日志”或“事件日志”，看是否有回源失败的记录。

5.2 问题二：防护规则导致WebUI功能异常（如音频无法播放、进度不更新）

• 可能原因：
  1. WebSocket连接被阻断：一些WebUI（如Gradio的流式输出）会使用WebSocket (ws://或wss://)。如果你的防护规则过于严格，可能会阻断WebSocket握手包或数据帧。
  2. 静态资源加载被拦截：规则误伤了JS、CSS或字体文件的加载。
  3. API路径匹配过宽：你的防护规则URL路径可能匹配了不止一个接口，例如/api/匹配了所有/api/开头的请求，包括一些用于查询状态的非计算密集型接口。
• 解决方案：
  1. 针对WebSocket：在360的CC防护或WAF规则中，找到关于WebSocket的选项，通常可以设置为“放行”或“不检查”。如果找不到，尝试将WebSocket的连接路径（如/queue/join对于Gradio）加入CC防护的“URL白名单”。
  2. 精确匹配URL：将防护规则的URL条件设置得尽可能精确。使用“等于”而非“包含”，或者使用更精确的正则表达式。
  3. 分路径设置策略：为计算密集型接口（合成）设置严格的验证码策略；为查询类接口（如/api/status）设置更宽松的频率限制或直接放行。

5.3 问题三：攻击依然有效，服务器负载仍高

• 可能原因：
  1. 攻击绕过了CC防护：攻击者可能使用了低频率、慢速但持久的攻击，或者使用了大量不同的IP（IP池），使得单一IP的频率规则失效。
  2. 防护规则未生效或优先级错误：你创建的规则可能因为优先级低于其他“放行”规则而未执行。
  3. 攻击的不是你防护的接口：攻击者可能转向攻击你未防护的其他接口或路径。
• 应对策略：
  1. 启用“智能CC防护”：360的付费高级功能通常包含基于AI行为的智能识别，能更好地应对慢速攻击和IP池攻击。免费版用户可以考虑升级。
  2. 组合使用“人机验证”和“拦截”：对于核心API，坚持使用验证码。对于其他疑似攻击的路径，可以直接拦截。
  3. 分析日志，调整策略：仔细研究360拦截日志和服务器访问日志（如Nginx日志），找出攻击的真实模式。他们可能在攻击/首页，消耗你的连接数。这时你需要为根路径也添加一条频率限制规则（阈值可以设高一些）。
  4. 考虑启用“区域封禁”：如果攻击流量大量来自某个特定国家或地区，而你的用户不在那里，可以直接在360控制台封禁该地区的IP访问。

5.4 一个重要的实操心得：关于验证码与API的兼容性

这是最大的一个坑。IndexTTS2的WebUI API通常是程序调用的（比如你自己写的脚本、其他应用集成）。如果你对API接口设置了“人机验证”，那么程序调用就会失败，因为程序无法自动完成滑动拼图。

解决方案是“双轨制”：

1. 对公网WebUI的API路径（如/api/tts）启用严格的“人机验证”防护。这是给未知的、可能恶意的浏览器用户使用的。
2. 为你自己的程序调用，创建一个单独的、隐秘的API路径。例如，在WebUI的配置中，再开一个服务端口或路径，比如:7861端口下的/internal/api/tts。这个端不经过360网站卫士（可以通过防火墙只允许你自己的服务器IP或内部网络IP访问），或者即使经过360，也为这个特定路径设置一条“白名单”规则，放行来自你信任IP的请求。

这样，既保证了公开服务的抗攻击能力，又不影响你自己的自动化流程。安全性和便利性得到了平衡。

防护配置从来不是一次性的工作。随着你的WebUI用户增多，或者攻击手段变化，你需要定期回顾日志，微调防护策略。360网站卫士提供的免费基础防护，对于个人项目和小型IndexTTS2服务来说，已经是一道非常坚固且省心的防线。它把复杂的流量清洗工作从你宝贵的计算资源上剥离出去，让你能更专注于TTS模型本身的优化和应用。