fscan 图形化 Web 管理平台从零到可用：关键步骤与实战-育师

fscan 图形化 Web 管理平台从零到可用：关键步骤与实战

【免费下载链接】fscan一款内网综合扫描工具，方便一键自动化、全方位漏扫扫描。(An intranet comprehensive scanning tool, enabling one-click automated, all-round vulnerability scanning)项目地址: https://gitcode.com/GitHub_Trending/fs/fscan

下午三点，你盯着终端里fscan -h 10.10.0.0/16的输出发呆。扫描还在跑，进度到哪一步？中间有没有爆出高价值端口？没人知道，只能等。这就是纯命令行工具的宿命：任务跑起来之后，你和它之间只剩一根不断刷新的日志流。fscan 图形化 Web 管理平台要解决的，就是这个问题——把 fscan 这台内网综合扫描引擎装进浏览器，进度、结果、控制全变成可视化界面。

fscan 的定位没变：一键自动化、全方位内网扫描，从 ICMP 存活探测、多协议端口扫描到服务爆破、Web 漏洞探测一条链走完。变的只是操作入口：不再是敲-h -p -m拼参数，而是打开页面，填目标，点开始。

fscan 内网扫描命令行运行效果，展示端口开放与服务爆破结果

图形化平台由哪些部分组成

别被"Web 平台"吓到，它不是另起炉灶，而是在 fscan 现有扫描核心上包了一层 HTTP 服务。相关代码集中在三个位置：

main_web.go：带web构建标签的独立入口，和命令行入口平级，只多了一个-port参数；
web/：HTTP 服务本体。web/server.go 里负责启动监听、注册 API 路由、挂上 WebSocket，并把前端静态文件一并服务出去；
web-ui/：React + Vite 前端工程，编译产物会被嵌入 Go 二进制，浏览器打开即是完整界面。

核心扫描引擎 core/ 和插件系统 plugins/ 完全没动。Web 层做的事就三件：把表单参数翻译成扫描配置、把扫描结果接出来、把状态实时推给浏览器。理解了这三件事，后面的一切都是细节。

Web 模式与 CLI 模式的区别

两者走同一条扫描链路。Web 请求进来后，web/api/scan.go 把表单字段填入common.FlagVars，再经过 common/config_builder.go 构建成与命令行完全一致的 Config，随后交给core.RunScan执行。换句话说，你在页面上看到的每个选项，背后都有对应的 CLI 参数，行为不会漂移。

代码里保留了一个"过渡桥"：运行期间会同步写一份全局配置，方便复用那些直接读全局状态的模块，注释里标明后续版本会移除。这个细节不用关心，但它解释了为什么 Web 版不需要重写任何扫描逻辑。

一条命令完成 fscan 部署与启动

部署是最简单的一步。本地需要有 Go 和 Node.js 环境，然后在仓库根目录执行：

make build-web

这条命令先跑build-ui：进入 web-ui/ 执行npm install和npm run build，把产物拷到web/dist/；随后带web构建标签编译 Go 代码。web/server.go 里的//go:embed dist/*会把前端文件直接烧进二进制。最终产出一个fscan-web可执行文件，拷到任何机器都能跑。

启动默认监听 10240 端口，浏览器访问http://localhost:10240就能看到界面。想换端口，加一个-port参数即可。

扫描任务如何下发、停止与查进度

任务管理围绕三个接口展开，前端的开始、停止、刷新按钮都对应它们：

curl -X POST http://localhost:10240/api/scan/start \ -d '{"host":"10.10.0.0/24","ports":"1-1000"}' curl -X POST http://localhost:10240/api/scan/stop curl http://localhost:10240/api/scan/status

第一个请求体就是全部参数：host必填，ports留空时默认扫一份常用端口清单；线程数、超时、扫描模式不填都有兜底值（默认 600 线程、3 秒超时、all全量模式）。想跳过凭据爆破或只探存活，对应传disable_brute、alive_only布尔开关即可。另外两个接口一个负责取消正在跑的任务，一个返回当前状态。

状态接口返回什么

/api/scan/status的响应里包含状态（idle/running/stopping）、进度百分比，以及扫了多少主机、多少个端口、发现多少服务和漏洞四个计数。前端进度条和统计卡片就是靠它驱动的。

注意当前实现同时只跑一个扫描任务：已有任务在运行时再次调用 start，会直接收到 409 Conflict。这是有意为之的资源保护，不是 bug。Web 模式下结果只保存在内存中，不写本地文件，需要留存就走结果导出接口。

扫描结果如何实时可视化

结果推送走 WebSocket，而不是轮询。服务启动时初始化了一个 Hub（见 web/ws/hub.go），所有打开页面的浏览器都挂在这条长连接上：扫描启动时广播一条开始消息；每产生一条结果（开放端口、服务指纹、弱口令、POC 命中）就即时广播；结束时广播总耗时和最终统计。前端不用定时发请求，延迟低，也省流量。

WebSocket 万一断了，还有兜底：结果列表接口可以按条件全量拉取，支持筛选与导出。

还有一个隐藏能力值得一提：项目缓存。启动扫描时带上project_id，系统会把该项目历史扫过的 host:port 组合预注入本次扫描目标，省掉重复的存活探测和端口重扫，专治"每次从 1280 个端口重新问一遍"的浪费。扫描结束后，本轮新发现会自动合并回项目缓存，下次接着用。