◈ netchecks.org

17 项检测 · 无需账号 · 自托管

一键测试您的网络

17 款免费网络诊断工具,集成于同一面板。

常见问题

0 跟踪器 · 14 种语言 · 明暗双模式 · 自托管

← 所有文章

Network history

The Rise of the VPN: From Dial-Up Tunnels to WireGuard and Zero Trust

A VPN's core idea has not changed since the mid-1990s: wrap traffic in an encrypted tunnel so it can cross a network you do not trust - typically the public Internet - while behaving as if it were still on the private network at the other end. What has changed dramatically, generation after generation, is how that tunnel is built, how strong its encryption is, how fast it runs, and eventually, whether the whole concept of a single trusted 'inside' the tunnel still makes sense at all.

That evolution tracks almost exactly against the Internet's own growth from a curiosity to critical infrastructure: each new protocol generation exists because the previous one's weaknesses became too expensive, too slow, or too insecure to keep tolerating at the new scale.

  1. 1996

    PPTP is developed

    Microsoft and a consortium of vendors create the Point-to-Point Tunneling Protocol, the first widely deployed consumer/enterprise VPN protocol, built into Windows 95's OSR2 update.

  2. 1999

    L2TP is standardized

    Layer 2 Tunneling Protocol (RFC 2661) combines the best ideas of PPTP and Cisco's L2F, but has no built-in encryption of its own - it is almost always paired with IPsec.

  3. 1998-2005

    IPsec matures

    The IPsec suite (RFC 2401 and successors) becomes the enterprise standard for site-to-site VPNs, providing strong, standardized encryption and authentication at the network layer.

  4. 2001

    OpenVPN is released

    James Yonan releases OpenVPN, an open-source SSL/TLS-based VPN that runs over standard UDP or TCP - easy to firewall-traverse and free from any single vendor's control.

  5. 2002-2003

    SSL VPNs go mainstream

    SSL/TLS-based 'clientless' VPNs (accessible from a browser) emerge as a lighter alternative to IPsec for remote-access use cases, avoiding IPsec's notorious firewall/NAT traversal headaches.

  6. 2005

    IKEv2 is published

    RFC 4306 (later RFC 7296) modernizes IPsec's key exchange, adding fast reconnection after a dropped connection - the feature that made IPsec genuinely usable on mobile devices switching between WiFi and cellular.

  7. 2012

    WireGuard development begins

    Jason A. Donenfeld starts designing WireGuard around a radical goal: a fraction of the code size of IPsec or OpenVPN, using a small, fixed set of modern cryptographic primitives instead of dozens of negotiable, sometimes-outdated options.

  8. 2018

    Linus Torvalds merges WireGuard into Linux

    WireGuard enters the Linux kernel mainline, a strong technical endorsement, and rapidly becomes the reference implementation for a new generation of fast, minimal VPN protocols.

  9. 2020

    Zero Trust goes mainstream

    NIST publishes SP 800-207, formalizing the Zero Trust Architecture model: verify every request individually regardless of network location, rather than trusting anything already 'inside' a VPN tunnel.

  10. 2020-2024

    SASE and ZTNA displace classic remote-access VPN

    Secure Access Service Edge and Zero Trust Network Access platforms increasingly replace always-on, full-network VPN access with per-application, continuously verified access - the direct architectural response to VPN's long-standing 'once you're in, you're trusted everywhere' weakness.

Why VPNs exist at all

Before broadband and cloud services, reaching a corporate file server or mainframe from outside the office meant a direct dial-up modem connection into a bank of remote-access servers - reliable but expensive to scale and entirely dependent on phone infrastructure. As the public Internet became cheap and ubiquitous in the mid-1990s, the obvious next step was to reuse it as the transport, but that only works if the traffic crossing it is protected from the untrusted networks in between - which is exactly the problem PPTP was built to solve in 1996.

Every VPN protocol since has been solving some combination of the same three problems: how to build the tunnel, how to prove both ends are who they claim to be, and how to encrypt what flows through it - with each generation making different tradeoffs between security strength, connection speed, and how well it survives firewalls, NAT, and unreliable networks.

A VPN wraps a client's traffic in an encrypted tunnel across an untrusted network (typically the public Internet) to a gateway, which then forwards it onto the private network as if the client were directly attached.

The first generation: PPTP, L2TP, and IPsec

PPTP was fast and simple to set up - genuinely groundbreaking for 1996 - but its encryption (Microsoft's MS-CHAP-based scheme) was progressively broken by researchers over the following decade and is now considered insecure for anything sensitive. L2TP, standardized in 1999, fixed PPTP's tunneling design but deliberately left out encryption entirely, on the assumption it would always be paired with a separate encryption layer.

That layer was IPsec, and the combination of L2TP for tunneling plus IPsec for encryption became the de facto enterprise standard through the 2000s. IPsec's strength was operating at the network layer, meaning it could secure any IP traffic transparently without any application even being aware of it - but that same low-level design made it notoriously difficult to get through firewalls and NAT devices, a persistent operational headache for anyone deploying it at scale.

SSL VPNs and OpenVPN: solving the firewall problem

The mid-2000s answer to IPsec's traversal problems was to build VPNs on top of SSL/TLS instead - the same protocol securing HTTPS traffic, which every firewall on Earth already had to let through on port 443. 'Clientless' SSL VPNs, accessible straight from a browser, made remote access dramatically simpler to deploy for basic use cases, while OpenVPN (released in 2001, but reaching wide enterprise adoption through this period) offered the same SSL/TLS-based approach as a full, flexible, open-source tunnel that could run over either UDP or TCP.

OpenVPN's open-source nature mattered as much as its technical design: unlike IPsec's dozens of vendor implementations with inconsistent interoperability, or PPTP's Microsoft-controlled evolution, anyone could audit, extend, or embed OpenVPN, and it became the default choice for consumer VPN services and self-hosted deployments alike for the better part of two decades.

WireGuard and the move toward radical simplicity

By the 2010s, IPsec and OpenVPN both carried real technical debt: large codebases (tens of thousands of lines), dozens of negotiable cryptographic algorithms (several since deprecated as insecure), and correspondingly large attack surfaces. WireGuard's answer, starting in 2012, was almost the opposite design philosophy: roughly 4,000 lines of code, a single fixed, modern cryptographic suite with no negotiation, and a connectionless design built around the same principles as SSH's key-based authentication rather than certificate hierarchies.

The result measurably outperforms both predecessors on speed and battery life on mobile devices, while its small codebase is genuinely auditable in a way IPsec's implementations never realistically were - which is exactly why Linus Torvalds merged it directly into the Linux kernel in 2018, an endorsement almost no other VPN protocol has received.

The next shift: from VPN to Zero Trust

Every protocol generation up to this point solved how to build a better tunnel. The most recent shift questions the tunnel model itself: a classic VPN grants broad access to an entire private network once a user authenticates, which means a single compromised laptop or stolen credential can move laterally across everything that network reaches - a weakness behind a long list of major breaches.

NIST's 2020 Zero Trust Architecture framework (SP 800-207) reframes the problem: instead of one strong perimeter check followed by implicit trust, verify every single request independently, regardless of whether it originates 'inside' or 'outside' any tunnel. Zero Trust Network Access (ZTNA) and Secure Access Service Edge (SASE) platforms implement that model in practice, granting access per application rather than to the whole network - not a replacement for the encryption VPNs pioneered, but a fundamentally different answer to the access-control question a VPN alone was never actually designed to solve.

要点总结

Encryption strength was never really the bottleneck in this history - AES has been considered sound for decades. What actually changed, generation after generation, was operational reality: making tunnels traverse real-world firewalls and NAT (SSL VPN, OpenVPN), making reconnection survivable on flaky mobile networks (IKEv2), making the whole implementation small enough to actually audit (WireGuard), and finally questioning whether 'inside the tunnel' should ever again mean 'implicitly trusted' (Zero Trust). Each generation is a direct answer to the previous one's most painful real-world limitation, not a purely academic improvement.

← 所有文章

我的 IP 检测

自动检测您的公网 IP 地址和网络位置。

打开 NetChecks 时自动加载,无需输入。切换网络或重新连接 VPN 后,点击刷新按钮重新检测。

您的浏览器

一键全面扫描

对一个 IP 或主机名一次性运行所有相关检测:DNS、whois、ping、traceroute、知名端口扫描 (1-1024)、HTTP 头信息和 SSL 证书。

输入域名或 IP 地址并运行,一次性检查 DNS、whois、ping、traceroute、常用端口、HTTP 响应头和 SSL 证书。

大多数检查并行执行,通常在约30秒内完成,若目标响应缓慢或无法访问则更久。

只有在上方的同意复选框被勾选后,端口扫描步骤才会执行——其他所有检查照常执行。

Ping

向主机发送 ICMP 回显请求,以检测其可达性和延迟。

输入主机名或 IP 地址,点击 Ping 发送 ICMP 回显请求并测量往返延迟。

You Host ICMP Echo Request (type 8) ICMP Echo Reply (type 0) measures: RTT · TTL · packet loss

      

深入了解 Ping

定义

Ping通过向目标主机发送ICMP回显请求(Echo Request)报文,并测量ICMP回显应答(Echo Reply)返回所需的时间,来完成最基础的网络连通性测试。它只回答一个问题:"这台设备是否可达,响应速度如何?"ICMP协议(RFC 792)早在1981年就被设计用来在IP网络上承载控制与诊断信息,独立于应用层流量之外——Ping正是它最广为人知、也是普及程度最高的实现,几乎所有操作系统和网络设备从最初版本起就自带这一功能。

工作原理

每个ICMP报文都携带一个TTL(生存时间)字段,每经过一台路由器就减1;一旦在到达目标之前减到0,报文就会被丢弃,并向发送方回送一条错误消息。以毫秒为单位测得的往返时延(RTT)反映的是整个往返路径上累积的网络延迟,而不仅仅是目标附近最后一段的延迟——这一点常被误解,因为Ping结果慢的根本原因可能出现在路径上的任意位置,未必靠近被测服务器。Ping通常会连续发送多个报文而不是只发一个,这样就能区分出偶发的延迟毛刺和持续性的问题,并据此计算出这一批样本的丢包率。

结果解读

稳定且较低的RTT——局域网内几毫秒,同一国家内的目的地10到50毫秒,跨洲链路则明显更高——说明连接状况良好。哪怕只是轻微的丢包(超过1%到2%),对VoIP或交互式远程会话这类对延迟敏感的场景也会造成明显影响,每一个丢失的包都会表现为卡顿或断音。相比稳定但数值较高的延迟,包与包之间延迟波动很大(抖动)对这些场景往往是更严重的问题。"请求超时"表示在规定时间内没有收到应答——可能是主机确实宕机,也可能是防火墙悄悄屏蔽了ICMP,或者路径上某处出现了故障;"目标不可达"则不同,信息量更大:它是路径上某台中间路由器主动回送的消息,明确表示自己无法转发该报文,有助于缩小问题定位范围。

常见误区

最常见的误判是一旦Ping失败就断定主机"宕机",而实际上大量服务器和设备——尤其是部署了严格防火墙策略或托管在主流云服务商那里的——出于策略考虑会主动屏蔽入站ICMP,同时它们提供的实际服务(HTTP、数据库等)完全正常可用。因此,没有收到Ping应答只有在结合其他信号(比如应用本身也无响应)时才具有实际意义。反过来,Ping成功也完全不能保证该主机上运行的应用服务本身工作正常——这是网络栈中两个完全独立的层面。

适用场景

在升级工单之前先做的第一项检查:先确认设备是否有响应,再深入排查。在修改防火墙规则或路由表之后确认连通性,确保改动没有破坏访问。在VoIP上线或运营商链路切换之前建立延迟基线,以便后续出现通话质量投诉时有客观的对比依据。作为MSP并行监控多个客户站点时一种轻量、低开销的周期性健康检查手段,但始终应作为更深层应用级监控的补充,而非替代。

Traceroute(路由追踪)

逐跳追踪到目标主机的网络路径。

输入主机名或 IP 地址并运行,查看本服务器到目标之间的每一跳,以及各跳的延迟。

You TTL=1 TTL=2 TTL=3 Host each hop replies "ICMP Time Exceeded" until TTL reaches the host

      

DNS 查询(Nslookup)

查询 DNS 记录:A、AAAA、MX、TXT、NS、CNAME、SOA、PTR、SRV、CAA。

输入域名,选择记录类型(A、AAAA、MX、TXT、NS、CNAME、SOA、PTR、SRV 或 CAA),然后查询。

You Root .com Auth NS ① query root ② referral → TLD ③ referral → auth NS ④ answer

      

Whois 查询

查询域名或 IP 地址的注册信息。

输入域名或 IP 地址,查询其注册信息:注册商、所有者组织及重要日期。

You Registry RDAP / :43 query: domain / IP reply: registrar, dates, name servers

      

黑名单检测

检查某个 IP 地址或域名是否被列入公共垃圾邮件/滥用黑名单(DNSBL)。

输入 IPv4 地址或域名并运行,即可一次查询 7 个公共 DNSBL/RBL 黑名单 - 每个列表会显示已列入、未列入或检测失败。

You zen.spamhaus.org spamcop.net sorbs.net +4 more reverse-IP DNS query to each DNSBL zone, in parallel

      

TCP 端口扫描

检测主机或 IP 上的 TCP 端口是否开放:常用端口、自定义列表,或完整的 1-65535 范围。

输入主机或 IP,选择常用端口、自定义列表或完整范围,然后扫描查看哪些 TCP 端口有响应。

You 22 open 443 open 3389 closed 8080 closed SYN → SYN-ACK = open · SYN → RST = closed

        
      

HTTP 响应头检测

获取某个 URL 的 HTTP 响应状态码和响应头。

输入网址,获取其 HTTP 响应状态码以及服务器返回的所有响应头。

You Server GET / HTTP/1.1 200 OK + headers Content-Type · Strict-Transport-Security · X-Frame-Options …

      

SSL / TLS 证书检测

检测主机的 TLS 证书:颁发机构、有效期以及剩余天数。

输入主机名,检查其 TLS 证书:颁发者、有效期及距过期的剩余天数。

You Host ClientHello → ← ServerHello + Certificate + Finished Root CA Intermediate Leaf (site) certificate chain of trust · validity dates checked

      

IP 地理位置查询

查询某个 IP 地址的地理位置和网络信息。留空则查询您自己的公网 IP。

输入任意 IP 地址,或留空以查询您自己的 IP,查看其大致位置及网络/ISP 信息。

IP address Geo / RIR database City · Country ASN · Org

        
        
      

子网 / CIDR 计算器

完全在您的浏览器中计算 — 不会向服务器发送任何数据。

输入 IP 地址和 CIDR 前缀(例如 192.168.1.0/24),即时计算网络范围、广播地址和可用主机数量。

network bits (prefix) host bits /24 example — split moves with your prefix

      

网速测试

与本服务器之间的基础下载/上传速度测试(准确性取决于服务器自身的网络带宽)。

点击开始,测量与本服务器之间的下载和上传速度。准确度取决于本服务器自身的网络连接。

You Server ↓ download ↑ upload throughput (Mbps)

      

国家代码词典

ISO 3166-1 alpha-2 国家代码 — 完全在您的浏览器中搜索。

搜索或浏览 ISO 3166-1 alpha-2 国家代码列表,完全在您的浏览器中查询。

国家ISO 代码

国际电话区号词典

按国家划分的国际电话区号 — 完全在您的浏览器中搜索。

按国家搜索或浏览国际拨号代码,完全在您的浏览器中查询。

国家区号

世界时钟

选择一个时区查看当前时间 — 拖动地球即可旋转。

从列表中选择一个时区,或拖动地球仪,查看该地的当前时间。

您的时间
--:--:--
—

—

所选时间
--:--:--
—
— UTC±00:00
与您的时差 —

—

拖动以旋转地球。

法国移动网络状态

法国各运营商(Orange、Free、SFR、Bouygues Telecom)故障或维护中的移动基站,数据来自 Arcep 公开数据。每日更新一次快照,非实时数据流。

按法国运营商浏览移动基站和光纤故障数据——无需输入,根据 ARCEP 公开数据自动更新。

来源:Arcep,「Sites indisponibles」数据集,采用 Licence Ouverte / Etalab 2.0 许可发布——明确允许商业性重用,这与此前使用的 IODA/CAIDA 数据不同。正常/关注/警报 徽章是自制估算(今日故障数与前几日中位数比较),并非 Arcep 官方分类。来源链接见下方。

受影响最多的省份

当前故障或维护中的站点数量,按省份统计。点击上方运营商可筛选。

数据来源: Arcep — Sites indisponibles · 官方网络状态地图


固网(光纤)

各运营商光纤(FTTH)网络质量:故障上报率与装机失败率,数据来自 Arcep 公开数据。月度指标,6个月滚动平均——不像移动部分那样为实时数据。

来源:Arcep,「Qualité des réseaux en fibre optique」数据集,采用 Licence Ouverte / Etalab 2.0 许可发布——明确允许商业性重用。来源链接见下方。

按运营商(母公司)

过去 6 个可用月份的平均值,按基础设施运营商母公司分组。

数据来源: Arcep — Qualité des réseaux en fibre optique