先说结论：fscanx 想解决什么问题？
如果你用过原版 fscan（以及一堆同类扫描器），你大概率踩过这些坑：
- 代理模式下端口误报 ：通过 socks5 扫描时，很多工具会把“代理连通”当成“目标端口开放”，结果全是 open。
- icmp 扫描太猛 ：速率不可控，ping 一开把路由器/网络打崩，自己先断网。
- 信息收集割裂 ：ip、网段、域名、url、masscan 输出，各扫各的，手工处理很麻烦。
- 指纹识别/WEB 信息提取不够“一步到位” ：端口都扫了，不如顺便把协议、Web 产品、标题、证书等都提出来。
- VPN 场景错扫本地网段 ：探测流量走错网卡，把本地上游网络当成目标内网，误判、误打。
fscanx 的定位很明确：内外兼修、轻车重炮 。
“车”是能直接落地内网的快侦察（icmp/端口/指纹）；“炮”是通过代理 远程打一整个内网（重点是：在代理环境下尽量不误报、插件可用）。
2026.02.07 修复要点
- gonmap 超时误判端口关闭 ：此前在某些端口上，多个探针都识别不到协议，达到单端口探测总超时后会直接判定“关闭”。
现在的修复策略是：超时后再用一次 TCP 连接校验真实开放状态 （后续仍可进一步优化为“拿到中间探测结果”减少最后一次连接开销）。 - 协程池调用健壮性修复 ：提升高并发任务调度稳定性。
1）大网段智能探测：先筛活段，再深扫
面对 /8、/16 这种大网段，fscanx 新增了“智能预扫描”（-auto）：
- 按 C 段为单位 做筛选
- 默认对每个 C 段的
1,2,253,254这四个 IP 位进行 tcp+icmp 验活 - tcp 默认打
80（网关/管理面板概率高） - 命中则认为该 C 段“存活”，再进入后续常规扫描流程
参数一览（智能预扫描阶段）：
| 参数 | 含义 | 示例 |
|---|---|---|
-auto |
开启智能预扫描 | -auto |
-am |
使用哪些验活方式：tcp,icmp |
-am tcp,icmp |
-ap |
tcp 验活端口列表 | -ap 22,80 |
-ai |
每个 C 段探测哪些 IP 位 | -ai 253,128 |
-atime |
tcp 建连超时（秒） | -atime 2 |
支持的 -h 输入（智能扫描仅支持这些形态）： |
-h 10 -auto（等同 10.0.0.0/8）-h 172 -auto（等同 172.16.0.0/12）-h 192 -auto（等同 192.168.0.0/16）-h 43.1.1.1/16 -auto-h 83.1.1.1/8 -auto
2）内存优化：1000 并发不再轻易起飞
作者给的优化路径非常“工程化”，核心思路是：能流式就流式、能复用就复用、能少读就少读、能预编译就预编译 ：
- tcp dialer / timeout / keepalive 策略调整
- http 只读取前 192KB 报文（避免大响应拖垮内存/带宽）
- gonmap 探针与正则优选（保留主流协议）
- 指纹引擎切换为
chainreactors/fingers（Web 指纹更现代） - 生产者/消费者通道化（ip 生成、ip:port 生成、icmp->端口扫描衔接）
- icmp 使用布隆过滤器过滤杂包
- 正则预编译、sync.Pool 降低对象分配
两类典型压测：
- 端口扫描 1000 并发 ：不启用 nmap 指纹时内存约 89MB ；启用
-nmap后约 154MB （资产少时）。 - URL 扫描 1000 并发 ：大量存活 URL 时，峰值约 450MB-620MB （与 httpx 类似量级，明显优于某些“连接复用失控”的实现）。
3）指纹体系重构：协议指纹 + Web 指纹
协议指纹（-nmap）
对 gonmap 做了优化并优选探针/指纹，保留常用协议：
http/https/ssl、smb、rdp、snmp、socks5、mssql、redis、ftp、ssh、telnet、ldap、imap/smtp/pop3、oracle、mongodb、mysql、vnc、svn、rsync、rpc、netbios…
若要扩展协议探针，可改
mylib/gonmap/nmap-service-probes.go；注意作者限制了每端口探测的探针数量以控时延。
Web 指纹（fingers + goby）
默认加载 fingers、goby 两套（goby 存在部分误报，已清理一部分“垃圾指纹”）。
4）-hf 增强：一份 target.txt 解决“信息收集碎片化”
-hf 支持混合输入（每行一种，统统喂进去）：
ipip:portcidrcidr:porturl- 纯域名
- masscan 重定向输出文本（
>保存的内容）
更关键的是：新增 -pd，控制是否把 url/域名解析出的 IP 转 C 段 加入端口扫描：
- 只做 Web 探测 ：不加
-pd - 做信息收集（域名- >ip->同 C 段扩展）：加
-pd
推荐命令（信息收集常用）：
fscanx -hf target.txt -pd -nmap -np
5）IP 归属地：qqwry.dat 即插即用
把 qqwry.dat 放到 fscanx 同目录即可启用（纯真 IP 库）：
下载：https://github.com/metowolf/qqwry.dat
6）选项变动：默认更“克制”，按需开启
去掉了 -nopoc、-nobr，改为：
-poc：启用 POC 扫描（默认不扫）-br：启用弱口令爆破（默认不爆）
目的很现实：很多人日常只做资产探测/指纹，不想每次都写“禁用”参数。
7）代理模式的端口误报：为什么会发生？怎么解决？
误报的典型来源：以 clash/v2ray 这类“本地 socks5 + 远端节点”架构为例，本地 socks5 服务并不一定知道目标端口是否真实建立连接 ，它可能先回复“连接成功”（例如 05 00），让后续数据自己去碰壁。
fscanx 的策略：
- 启动时检测 socks5 服务是否“标准”
- 若不标准：socks5 建立后先发一个极简探针（如
GET / HTTP/1.0\r\n\r\n）并尝试读取响应 - 只要能读到 1 个字节，就能确认目标端口真实开放
- 再建立“干净的新连接”交给后续协议识别/插件
一句话：用“真实收包”来为“端口开放”背书 ，避免把代理连通当成端口开放。
8）常用命令集
大网段快速扫描（建议）
fscanx -h 192.168.0.0/16 -auto -nmap -t 1000 -np
新目标公网信息收集（ip/段/域名/url 混合）
fscanx -hf target.txt -pd -nmap -np
批量 URL Web 扫描
fscanx -hf url.txt -tn 200
联动 masscan（-std）
masscan --rate 200 -p 80,443 192.168.0.0/16 | fscanx -std -nmap -t 200
代理模式远程扫内网（“高架炮”）
fscanx -socks5 socks5://127.0.0.1:1080 -h 192.168.1.1/16 -auto
-socks5：端口扫描 + URL 扫描都支持
-proxy：是 HTTP 代理，仅对 URL 目标生效（不用于端口扫描）
漏洞扫描（按需开启）
fscanx -socks5 socks5://127.0.0.1:1080 -h 192.168.1.1/24 -poc -p 80,443,8080
弱口令爆破（按需开启）
fscanx -socks5 socks5://127.0.0.1:1080 -h 192.168.1.1/24 -br -p 21,22,445,3306,6379
9）写在最后：一把更“适合实战习惯”的 fscan
这次更新里，我认为最值钱的并不是“又多支持了一个协议”，而是这几件事：
- 代理扫描不再轻易误报 （这是远程内网测绘的生命线）
- 大网段先筛活再深扫 （大幅降低无效扫描成本）
- -hf + -pd 把信息收集流程串起来 （减少手工处理目标的时间）
- 内存/IO/并发策略更像“能在垃圾 VPS 上跑”的工程实现
如果你把它当“车”，它能更快地把内网资产轮廓扫出来；
如果你把它当“炮”，它也更像一门能在代理条件下可靠命中的炮。
免责声明
1.一般免责声明：本文所提供的技术信息仅供参考，不构成任何专业建议。读者应根据自身情况谨慎使用且应遵守《中华人民共和国网络安全法》，作者及发布平台不对因使用本文信息而导致的任何直接或间接责任或损失负责。
2. 适用性声明：文中技术内容可能不适用于所有情况或系统，在实际应用前请充分测试和评估。若因使用不当造成的任何问题，相关方不承担责任。
3. 更新声明：技术发展迅速，文章内容可能存在滞后性。读者需自行判断信息的时效性，因依据过时内容产生的后果，作者及发布平台不承担责任。
本文为 独立观点，未经授权禁止转载。
如需授权、对文章有疑问或需删除稿件，请联系 FreeBuf
客服小蜜蜂（微信：freebee1024）
