企业官网建设流程全解析

1. WAF到底是什么：先把它和"防火墙"的账算清楚

先说个最常见的误解。很多人一听到"WAF防火墙"，下意识就觉得：这不就是一台硬件防火墙吗？我公司机房已经扔着一台好几万的企业级防火墙了，为什么还要单独上一个WAF？这钱花得冤不冤？

冤枉，但方向反了。不是WAF贵，是你可能压根没搞清楚自己面对的是哪一层的攻击。

传统防火墙（Network Firewall）管的是网络层和传输层，它看的是IP、端口、协议。它的工作逻辑像小区门口的保安：看车牌号（源IP）、看你去几号楼几单元（目的端口），核对你刷的门禁卡（TCP握手状态），只要这辆车、这个卡没问题，人进去之后干什么，保安基本管不着。

WAF全称是Web Application Firewall，中文叫Web应用防火墙。它工作在应用层（HTTP/HTTPS这一层），管的是你的网站请求里"人"干了什么。同样是那个保安，WAF的逻辑是：你进了小区之后，我盯着你在里面的一举一动——你是不是在试图撬别人家的门（SQL注入）、是不是在偷翻邻居的窗户（XSS跨站脚本）、是不是在冒充物业人员挨家挨户敲门（CSRF）、是不是在门口堵着一遍遍按门铃（CC攻击）。

所以WAF和传统防火墙根本不是替代关系，而是分工关系。传统防火墙负责"谁能进来"，WAF负责"进来之后能干什么"。一个管交通，一个管行为。这是理解WAF一切功能的起点，也是我在实际项目中被客户追问最多的问题。

接着再往下拆一层。WAF防护的对象是Web应用，也就是跑在80/443端口上的那些业务系统——官网、商城、后台管理系统、API接口。今天绝大多数企业的核心业务都跑在Web上，而Web恰恰是攻击面最大、攻击成本最低的入口。传统防火墙对HTTP流量基本是"睁眼瞎"，因为它看不到请求体里的SQL语句、脚本代码和越权参数。WAF就是专门补这个盲区的。

我自己接手过一个案子：某客户的业务系统被黑，对方通过一个文件上传接口直接传了一个WebShell上去，整个服务器被人当自家后花园逛。翻日志的时候客户满脸困惑——"我们防火墙日志显示一切正常啊"。当然正常，防火墙看到的是一个再普通不过的POST请求，它根本不知道这个请求里带了木马。这就是典型的上WAF之前"裸奔"状态。

2. 网络上四处流传的那些WAF：从硬件到云WAF再到开源WAF

热搜词里出现了好几个具体名字——南墙WAF、堡塔云WAF、雷池WAF——说明大家对"市面上到底有什么WAF可选"非常关心。这一节我按落地形态把这些主流方案捋一遍，顺便说说各自的适用场景。

2.1 硬件WAF：花钱买省心，但别买成摆设

硬件WAF是早期最常见的形态，一台独立设备串在流量链路上，通常部署在负载均衡器或Web服务器前面，以串联（Inline）或者旁路（Mirror）方式接入。国内常见的有深信服、安恒、绿盟、启明星辰等厂商的产品。价格从十几万到上百万不等，一套完整方案还要算上规则库更新服务费。

硬件WAF最大的优势是性能稳定、延迟低，因为它是专用芯片处理，不像软件WAF那样跟业务抢CPU。而且硬件设备一般是"开箱即用"，厂商上门做初始化，出问题能直接找售后，对IT团队技术积累薄弱的中小企业来说最省心。

但硬件WAF有几个坑我要特别提醒。

第一，规则库如果不续费更新，半年后就是废铁。WAF的核心能力很大程度取决于规则库的时效性——新出的漏洞、新型绕过手法，规则库不更新根本拦不住。很多客户当初花大价钱买了设备，第二年就不舍得续服务费，结果WAF沦为一个"长得像防火墙的交换机"，流量照样过，攻击照样漏。

第二，串在链路里本身就是个风险点。硬件WAF一旦宕机，如果没配置Bypass，整个网站直接对外不可用。我见过不止一次"WAF挂了、网站也跟着挂了"的线上事故。所以采购硬件WAF时，务必确认设备是否支持故障自动旁路（Auto Bypass），并在运维手册里写明极端情况下的应急切换流程。

第三，性能瓶颈要提前算。硬件WAF的吞吐量参数看着很吓人（动不动标称10Gbps），但那是在理想流量模型下测的。真实业务里的HTTPS解密、HTTP头大小、URL长度、并发连接数都会大幅拉低实际吞吐。我一般建议选型时按标称值的40%-60%去估算实际能力，留出足够冗余。

2.2 云WAF：SaaS化部署，最省事的选项

云WAF的典型代表是阿里云WAF、腾讯云WAF、华为云WAF，以及热搜词里提到的堡塔云WAF。这类产品的部署模式是：把域名解析到WAF厂商的CNAME地址，流量先经过云端清洗，再回源到你的服务器。对用户来说，本机几乎不用动，只需要在DNS层面做一次解析切换，然后在云控制台上配置防护域名和回源地址。

云WAF的核心优势有三点：

• 零运维：规则库由厂商统一维护，永远是最新的，你不必操心规则更新这回事。
• 弹性抗D：遇到大流量攻击（尤其是CC攻击、HTTP Flood），云WAF可以调度云端资源来扛，你的源站服务器几乎无感。这个能力是硬件WAF无法比拟的——硬件设备性能是固定的，扛不住就是扛不住。
• 成本门槛低：按域名/按QPS计费，一个小站一个月几百块就能搞定，适合中小站点和创业项目。

云WAF的短板也很明确：流量要绕一圈，延迟会略有增加。跨地域访问时尤其明显，原来直连源站延迟20ms，走了云WAF中转后可能变成40-50ms。对延迟极度敏感的业务（比如实时对战游戏、高频交易接口），需要谨慎评估。

另外还有一点隐蔽的坑：云WAF的回源IP要加白名单。很多客户配完云WAF，发现源站经常遭"穿透攻击"——攻击者不直接打域名，而是通过扫描历史DNS记录找到源站真实IP，绕过WAF直捣黄龙。所以配置云WAF时，一定要在源站服务器上把防火墙策略改成"仅允许WAF回源IP访问80/443端口"，这是云WAF方案里最常见的疏漏。

2.3 开源WAF：雷池、南墙与自建之路

热搜词里的雷池WAF和南墙WAF就是开源/免费WAF的代表。国内近几年开源WAF生态进步很快，我实测过的几款已经具备相当不错的防护能力。

雷池WAF（SafeLine）是长亭科技开源的一款社区版WAF，基于容器化部署，使用非常轻量。它的检测引擎用的是长亭在攻防对抗中积累的语义分析技术，对SQL注入、XSS的识别率相当高，而且误报率控制得比传统正则规则好很多。我拿它跑过一套真实业务流量，误报率大约在1%-3%之间，对于开源产品来说相当能打。

南墙WAF（OpenWAF）是国内另一个活跃的开源项目，主打高性能和多检测引擎协同。它把ModSecurity规则引擎、OpenResty、自研检测逻辑整合在一起，支持虚拟主机粒度配置、IP黑白名单、人机验证、频率限制等常见功能，部署方式灵活，可以以网关模式、旁路模式或SDK模式接入。

自建开源WAF的优点是成本几乎为零、可控性强、数据不出本地（这点对数据敏感型企业和政企项目很重要）。缺点是一切靠自己：规则要自己维护、误报要自己调、性能要自己测、出了问题要自己扛。如果团队里没有专门的Web安全人员，我不太建议走这条路——半吊子的自建WAF可能比没有WAF更危险，因为它会给你一种"我安全了"的错觉。

说实话，我自己的态度是：中小站点、个人项目、内部系统，优先考虑开源WAF或云WAF入门；上了规模、有合规要求的业务，果断上商业硬件或商业云WAF。预算和技术实力不同，没有绝对的"最好"，只有"最适合"。

3. WAF的看家本领：从SQL注入到CC攻击的拦截逻辑拆解

这一节是本文最核心的部分。我挑几个WAF最拿手的攻击类型，逐个拆一下WAF到底用什么逻辑拦截它们、拦截不住是什么原因、以及绕过WAF的常见手法又是什么。理解这些，比背十遍"WAF能防什么"有用得多。

3.1 SQL注入防护：正则、语义分析与参数化校验

SQL注入是WAF最经典的应用场景。它的攻击原理是：开发人员把用户输入直接拼进SQL语句，攻击者在输入框里塞一段精心构造的SQL片段，让数据库执行攻击者想要的查询或操作。

传统WAF拦截SQL注入主要靠正则表达式匹配。规则库里存着一堆特征字符串，比如union select、' or '1'='1、sleep(5)、load_file()等，请求参数里一旦匹配到这些特征，直接拦截。

正则在防小学生水平的注入时效果极好，但问题也很明显：攻击者会变形绕过。大小写混淆（UnIoN SeLeCt）、中间夹注释（uni/**/on sel/**/ect）、用编码替代（%27代替单引号）、用等价函数替换（SUBSTR代替MID）……只要规则库没覆盖到其中一种变形，攻击就能漏过去。

这就是为什么现在主流WAF都在往语义分析方向走。雷池WAF用的就是这类技术：它不靠死板的特征匹配，而是对SQL语句做词法分析、语法分析，判断这个输入在语义上是否构成了一条"完整的攻击性SQL语句"。哪怕攻击者把union select写成UNION%0aSELECT，经过解码、去注释、归一化处理后，语义分析引擎照样能识别出来。这个思路和我以前用AST（抽象语法树）做代码审计的思路很像——不看长相，看意图。

除了检测端的技术演进，我特别想强调一点：WAF是最后一道防线，不是唯一的防线。在应用开发层做参数化查询（PreparedStatement），从根上杜绝SQL拼接，才是治本。WAF的意义在于：当代码里因为历史包袱、开发水平参差等原因存在漏洞时，它能在外面兜住。所以我的安全建设建议永远是"纵深防御"——开发层做好输入校验，WAF在外面兜底，两者互不替代。

3.2 XSS防护：不只是"过滤script标签"那么简单

XSS（跨站脚本攻击）是另一种高频Web攻击。攻击者在输入框提交一段JavaScript脚本，如果网站没有过滤就直接渲染到页面上，其他用户访问这个页面时脚本就会执行，达到窃取Cookie、劫持会话、钓鱼的目的。

WAF拦截XSS的基本思路同样是先正则后语义：检测请求中是否包含<script>、onerror=、javascript:、<iframe>等特征。但XSS的变形比SQL注入更天马行空：

• 事件属性变形：<img src=x onerror=alert(1)>可以写成<img src=x onerror=alert（1）>（全角括号）、<img src=x onerror=alert\1`>`（反引号）……
• 编码绕过：把包裹脚本用j等HTML实体编码打散，浏览器渲染时解码成可执行脚本。
• 协议绕过：javascript:alert(1)可以写成java%0Ascirpt:alert(1)、JaVaScRiPt:alert(1)等变形。

所以WAF对XSS的检测，同样要依赖归一化和语义分析。归一化就是把各种编码形式先解码到统一形态，再交给检测引擎判断；语义分析则要回答一个问题：这段输入在浏览器环境里最终会不会被当作可执行代码渲染？

另外有个细节容易被忽略：存储型XSS比反射型XSS更隐蔽。反射型XSS是攻击者的输入直接回显在当前响应里，属于"射出即走"，WAF在请求入口拦一次就够了。存储型XSS是攻击者的脚本先存进数据库，之后任何用户访问某个页面都会触发。这种情况下，WAF不仅要在写入时拦截，还要在输出时检测——很多WAF为此专门做"响应体检测"，检查返回页面里是否混入了可疑脚本。选WAF的时候，可以重点关注产品是否支持双向检测（请求+响应），只做请求侧检测的WAF在存储型XSS场景下会漏掉一半。

3.3 CC攻击与DDoS防护：WAF的"限流"姿态

CC攻击（Challenge Collapsar）和DDoS（分布式拒绝服务）攻击是当下网站最"疼"的攻击形式。攻击者不搞复杂的注入和脚本，就是调集大量傀儡机/肉鸡，对你的网站发起洪水般的合法请求，把你的CPU、带宽、连接数打满，让正常用户访问不了。

这类攻击的难点在于：流量看起来全都是"合法"的——不是注入、不是XSS，就是正常的GET/POST请求，频率高一点而已。所以WAF的防护思路从"检测恶意特征"转向了"识别异常行为"。

常见手段包括：

• 频率限制（Rate Limiting）：对单IP、单会话、单用户设定单位时间内的最大请求数，超过阈值就触发告警或拦截。比如同一IP每分钟超过120次请求，直接返回验证码挑战。
• 人机验证（CAPTCHA/JS Challenge）：对可疑请求返回一个需要执行JavaScript才能通过的验证页面。正常浏览器自动执行JS后静默通过，攻击脚本如果没有JS引擎就会卡在验证页。
• 指纹识别（Bot Detection）：通过TLS指纹（JA3）、HTTP头顺序、Cookie一致性、鼠标轨迹等维度判断请求方是真实浏览器还是自动化工具。
• IP黑白名单与地域封禁：把攻击源IP加入黑名单，或者封禁攻击来源集中地区。热搜词里提到的"防火墙黑白名单"就是这个能力。

说句实话，WAF抗CC攻击的下限很高，上限看资源。WAF靠限流和验证，能把单个源头的CC攻击压制住；但如果遇到的是真正的大流量DDoS（比如几百Gbps的带宽洪水），那已经不是应用层WAF能独立解决的范畴了，需要配合高防IP、CDN清洗等更大规模的流量调度方案。WAF在这场攻防里扮演的角色更像是"筛子"，把混在流量里的恶意请求筛掉，让有限的应用资源服务好真实用户。

3.4 其他高频攻击类型与WAF的对应能力

除了上面三类，WAF在企业日常防护里还会覆盖这些攻击（我做了一个速查表，方便大家对照检查自己的WAF策略有没有配全）：

这里尤其要提醒一下SSRF。最近几年SSRF漏洞被利用的频率很高，攻击逻辑是利用服务器自身的请求功能去访问内网资源。WAF在检测SSRF时，要看请求里携带的URL参数是否指向了内网IP（如http://192.168.x.x）、特殊协议（如file://、gopher://）等。但SSRF的绕过手段极多（短链接、DNS重绑定、IPv6映射等），纯靠WAF规则很难全堵。SSRF的根治还是要靠代码层的URL校验和网络层的内网访问隔离。

4. 典型案例复盘：恶意域名背后的黑产团伙反复攻击处置全记录

热搜词里有一条特别具体的案例："如何分步骤彻底处置恶意域名 jjiiee.com 引发的黑产团伙反复攻击：含网络层阻断、DNS过滤、日志溯源、主机加固、WAF/IDS规则配置及长期监控方案"。这是非常典型的一条真实处置链路，我把它完整复盘一遍。整个案例里，WAF是其中的一环，但绝对不是唯一的一环——全套组合拳打下来，才能建立相对稳固的防线。

4.1 攻击场景还原：黑产团伙的"反复横跳"战术

这类攻击的典型特征我总结为"三反复"：

• 域名反复换：黑产团伙会注册大量廉价域名（jjiiee.com就是其中之一），一个被拉黑就换下一个，域名生命周期可能只有几天。
• 入口反复换：攻击者不只打一个URL，他们会轮换扫描不同的目录、接口和参数，寻找弱点和突破口。
• 时间反复换：攻击不一定集中在某个时段，而是不定期地"来一波"，目的可能是持续试探（盯上你了）或者配合业务攻击节奏（比如从站数据爬取、薅羊毛、撞库）。

对这类攻击，头痛之处在于：单独封一个IP、关一个域名，效果只能维持几小时。黑产团伙的集群规模远大于你的手动黑名单，没有自动化联动，就只能被对方拖着走。

4.2 处置第一步：网络层阻断与DNS过滤，先把"路"封死

处置恶意域名的第一优先级，是让攻击流量"根本到不了你的服务器"。这里分两道关卡：网络层阻断和DNS过滤。

网络层阻断：在防火墙（传统防火墙或云安全组）上，将已确认的攻击源IP段加入黑名单，阻断入向连接。但要注意，黑产IP往往分布在多个C段、多个地区，手动添加效率低且容易误伤（比如共享IP出口）。我当时的做法是：先分析攻击日志，提取高频源IP和所属地域，在防火墙上做"地域级+IP级"的双层阻断——高频攻击来源地区直接在地域策略里封禁，具体攻击IP走IP黑名单，两者叠加。

DNS过滤：在DNS层（自建DNS或云解析服务）将 jjiiee.com 及其关联域名的解析请求强制指向黑洞地址（比如0.0.0.0或127.0.0.1）。这样即使内网有机器被植入了恶意外联逻辑，它解析这个域名时也会得到一个无效IP，无法建立连接。这一步针对的是出向流量，也就是防止内网主机被黑产控制后主动回连C2服务器。

这里有个操作细节要提醒：不要只封一个域名，要用威胁情报去扩展关联域名。黑产团伙注册域名是有规律的——同样的注册邮箱、同样的DNS服务器、相似的域名命名习惯。我当时通过被动DNS（Passive DNS）和威胁情报平台，把 jjiiee.com 扩展到了一整组关联域名（大约十几条），一次性全部加入DNS黑洞和WAF黑名单。单独封一个，黑产换一个马甲就能继续打；封一批，才能有效抬升对方的攻击成本。

4.3 处置第二步：日志溯源与主机加固，搞清楚对方是怎么进来的

封完网络层，最要紧的是搞清楚：这个恶意域名到底通过什么途径进来的？如果攻击已经成功渗透了某台主机，你不把它揪出来，封多少域名都没用——它随时可以换个域名继续外联。

日志溯源我一般按这个顺序排查：

1. Web访问日志：重点查访问 jjiiee.com 相关IP段的历史请求，看有没有命中异常URL（上传接口、后台入口、扫描特征路径）。
2. DNS解析日志：内网DNS上查询哪些主机曾经解析过 jjiiee.com 及其关联域名。中招主机必然在这里留下痕迹。
3. 主机进程与网络连接：登录疑似中招主机，用netstat -ano（Windows）或ss -antp（Linux）查看当前外联连接，配合tasklist/ps aux找异常进程。
4. 计划任务与启动项：黑产常常通过计划任务实现持久化，把恶意脚本设定为定时执行。务必检查cron、/etc/rc.local、Windows计划任务和注册表Run键。

主机加固的重点，在溯源确认没发现"明显后门"的情况下，仍然要把这些基础工作做扎实：

• 账号排查：清理异常账号、禁用无用的高权限账号、强制弱口令账号改密。
• 补丁加固：重要系统补丁、中间件补丁（Nginx/Apache/Tomcat）、数据库补丁全部更新到最新。
• 最小化服务：关闭不用的端口和服务（最常见的是开着 3306、6379 暴露到公网），修改默认端口（这是暴力破解的重灾区）。
• 日志保留策略：配置日志远端归档，确保即使主机被清日志，也有异地副本可查。

4.4 处置第三步：WAF/IDS规则配置，建立应用层拦截基线

网络层封了路、主机层清了毒，接下来要在应用层把拦截能力建立起来。这一步的核心是：让WAF和IDS理解"这个团伙长什么样"，然后自动化拦截。

我当时在WAF上做了这几类规则：

• 恶意域名黑名单：把 jjiiee.com 及其关联域名写入WAF的URL黑名单，一旦请求中携带这些域名（URL、Referer、Cookie、POST体里的回调地址），直接拦截并告警。
• Bot特征封禁：把黑产常用UA（User-Agent）特征、无头浏览器特征、缺省Accept头等特征录入Bot检测引擎，识别后返回403或JS挑战。
• 路径访问管控：对后台登录路径、上传接口、API未授权路径做细粒度访问控制，要求来源IP白名单或额外认证，压缩攻击面。
• 频率限制策略：对登录接口、上传接口、查询接口设置单IP频率阈值，超过即触发验证码或临时阻断，抑制CC和撞库。

IDS层面则紧盯南北向流量里的恶意域名通信特征——当内网主机尝试访问已标记恶意域名的DNS请求或HTTPS连接时，产生告警并联动防火墙做会话阻断。

这里特别想分享一个实战经验：WAF规则配置完之后，一定要做误报验证。很多人配完WAF发现业务挂了，第一反应是WAF坏了，其实绝大多数是误报——比如把正常业务里含select字样的商品关键词、含onerror的用户昵称给拦了。我处理误报的习惯是：先让WAF跑一段时间"仅告警模式"（观察模式），看看它对真实业务流量的命中情况，再决定哪些规则可以切换到"拦截模式"。直接上来就开拦截，往往会误伤线上业务，得不偿失。

4.5 处置第四步：长期监控方案，防止"野火吹又生"

处置完成不等于结束。黑产团伙攻击的"反复性"决定了你必须有长期监控方案，否则下一次攻击会在你放松警惕时卷土重来。我建议的长期监控机制分三层：

第一层：域名与IP情报监控。定期拉取威胁情报（自有或商业情报源），重点监控与 jjiiee.com 关联的新域名新IP。黑产团伙换皮后，新域名往往和旧域名存在注册信息、解析记录、SSL证书指纹等关联关系，情报平台能自动捕捉。一旦发现新关联域名，自动同步到DNS黑洞和WAF黑名单。

第二层：日志基线监控。把WAF、防火墙、DNS解析日志接入集中日志平台（ELK/Splunk或云日志服务），建立"正常访问基线"。我通常关注这几个指标：单日攻击拦截数量、高频攻击源IP Top10、异常UA分布、404错误比例突变、凌晨时段访问量异常爬升。任何一个指标偏离基线，都值得人工复查。

第三层：周期性渗透验证。每季度对核心业务做一次轻量级渗透测试（自测或外包），重点验证WAF规则是否还能拦住最新变种、上传接口是否存在新的绕过路径、后台是否存在弱口令。安全建设不是一次性的工程，而是持续对抗的过程。

5. WAF的实战选型建议：别让钱白花，也别让安全成摆设

最后聊点实在的——WAF到底怎么选，才能既满足安全需求，又不沦为"花钱买心安"的摆设。

5.1 先想清楚三个问题再选型

• 你的业务是公网暴露还是内网系统？公网站点面对的是全网攻击，必须上WAF；纯内网系统风险较低，可以评估是否只需基础防火墙+访问控制。
• 你的团队有没有专人维护？有人维护，开源WAF可以作为主力或补充；没人维护，宁可买云WAF/商业WAF让厂商兜底，也不要自建半吊子系统。
• 你的业务对延迟敏感吗？延迟敏感业务慎选云WAF，优先考虑硬件WAF或透明代理部署的开源WAF；普通Web业务，云WAF的延迟增加在大部分场景下可接受。

5.2 部署模式对比速查表

5.3 选型之外的三个锦囊

第一，WAF不是万能药。别以为装了WAF就能高枕无忧。我在实战中见过太多"WAF装了，但WebShell照样被传上来"的案例——原因往往是WAF规则没覆盖上传接口、或者攻击者用分块传输绕过了检测。安全建设永远是螺旋式上升的过程，WAF只是其中一环。

第二，日志比拦截更重要。WAF最大的隐性价值不是拦住了多少攻击，而是留下了详尽的攻击日志。这些日志是事后溯源、威胁建模、规则调优的第一手素材。所以我建议在条件允许的情况下，WAF日志至少保留90天，并且要能与外部日志平台对接。

第三，定期做红队演练。每年自己人打自己人一次，用攻击者的视角审视WAF规则的有效性。我经历过一次红队演练，队友用分块传输+编码混淆绕过了当时所有WAF规则，给业务系统塞进了一个测试用WebShell。那次演练直接推动我们把WAF的检测引擎升级到了语义分析版本。真实攻击是最好的规则优化器，虚拟演练是次好的。

回到热搜词里那些具体问题——"防火墙关闭有影响吗"、"防火墙关了还是提示服务异常"、"win11防火墙错误代码0x800706d9"——这些其实反映了一个很普遍的现实：很多人至今连"防火墙"和"WAF"都还没完全分清，就开始纠结关闭防火墙的影响了。

我的回答是：默认情况下，请保持防火墙开启。无论是系统自带防火墙还是硬件防火墙，关闭意味着把"谁能进来"的管理权交给了互联网上的任何人。至于Windows防火墙报错（比如0x800706d9，往往是Windows Defender Firewall服务异常或依赖服务被禁用导致），优先检查MpsSvc（Windows Defender Firewall Service）和Base Filtering Engine服务是否正常运行，而不是一关了之。同样的道理，当WAF规则导致业务异常时，优先做白名单规则和误报调优，而不是粗暴地"先关掉看看"。

最后分享一个我踩过几次坑之后形成的习惯：无论选择哪类WAF，上线前一定要做三件事——先跑观察模式、先做回源验证、先写应急手册。观察模式确认无误报，回源验证确保流量链路正确，应急手册保证出故障时团队知道怎么快速切走。安全建设不是装个设备就完事，而是从部署那一刻开始，进入持续运营的状态。