模块2026-04-217 min
IP and DNS modules: turning raw lookup data into readable conclusions
The IP page confirms location and access context, while the DNS page cross-checks multiple resolvers.
This is the organized version on the main site. Use the article list below if you want to keep exploring.
Browse articlesAbout the article
This page is organized as a main-site article, keeping the key points and structure easy to read.
Article body
IP 页要先给“可用结论”
01IP 页的重点不是输出一大堆字段,而是先回答三个问题:我是谁、我从哪里来、我现在是不是在代理后面。为了做到这一点,页面优先展示地理位置、ASN、ISP、代理线索和当前连接来源。
当外部查询不可用时,页面也不会直接崩掉,而是返回结构化的部分结果。用户依然能继续往下看,也能知道哪些信息来自 Cloudflare Context,哪些信息来自外部回退。
Reference filessrc/app/api/ip/route.tssrc/app/tools/ip-lookup/IPLookupClient.tsxsrc/app/api/ip/__tests__/route.test.ts
DNS 页要做交叉验证,而不是单点查询
02DNS 工具最重要的不是“查得到”,而是“查得一致”。所以我给它接了多个 resolver,并且把本地联查和远端接口结果一起展示出来。这样用户就能一眼看出问题是出在解析本身,还是出在某个节点。
同时,A、AAAA、CNAME、MX、NS、TXT、CAA 都被纳入标准记录类型里,避免“DNS 查询”只剩一个粗糙的 A 记录结果。
Reference filessrc/app/api/dns/route.tssrc/app/tools/dns-lookup/DnsClient.tsxsrc/app/tools/dns-lookup/components/DnsBatchResult.tsx
统一输出格式,才能让 UI 真正变轻
03之前这两个模块最容易出问题的地方,是字段名和展示层口径不完全一致。后来我把 API 契约抽成了共享 schema,前端和后端都基于同一份类型来理解“结果应该长什么样”。
这样一来,页面上复制按钮、JSON 区、状态标签、提示语就能统一收口,不需要每个页面自己猜字段,也不会再出现同一项在不同页上叫法不同的情况。
Reference filessrc/lib/api-contracts.tssrc/app/tools/dns-lookup/components/DnsResultTable.tsxsrc/app/tools/dns-lookup/components/DnsHistory.tsx