AdguardTeam · puglieri · Mar 6, 2026 · Mar 6, 2026 · Mar 6, 2026
diff --git a/docs/adguard-for-windows-8/settings/app-settings/network-settings.md b/docs/adguard-for-windows-8/settings/app-settings/network-settings.md
@@ -43,6 +43,14 @@ Here you can choose which proxy AdGuard should use to download filter updates or
 
 ## Use SockFilter driver
 
-Enable this option to use the SockFilter driver, which helps block ads and trackers in apps on Windows 8 and later.
+Enable this option to use the SockFilter driver, which helps block ads and trackers in apps on Windows 8 and later. If this option is disabled, AdGuard will switch to the older WFP driver instead.
 
-If this option is disabled, AdGuard will switch to the older WFP driver instead.
+SockFilter was first introduced in v8.0 RC. It is an *experimental*, lightweight kernel-mode network driver that works at the socket level (TCP/UDP). Instead of inspecting or modifying packets as they travel through the full Windows networking stack, a sock filter intercepts socket calls (e.g., connect, send, receive, bind) at a higher, more stable abstraction level. This makes it ideal for applications that need to monitor or control network activity without deep packet processing.
+
+When fully tested and implemented, SockFilter has the potential to bring several advantages over other drivers:
+
+- **It operates at a higher, socket-level layer**: SockFilter works with socket operations rather than raw packets, making it less complex and more stable than WFP's low-level packet filtering.
+- **No interference with other network drivers**: Because it sits above VPN, firewall, and antivirus WFP filters, it avoids filter-ordering problems and compatibility conflicts common in the WFP stack.
+- **Greatly reduced risk of NETIO-related BSODs**: SockFilter doesn't run inside the NETIO packet pipeline, so it avoids the typical crash scenarios caused by WFP callouts mishandling buffers, classification results, or packet memory.
+
+When it comes to disadvantages, SockFilter driver sees only socket-level operations and does not capture traffic generated by other kernel drivers or components that bypass the standard Winsock API. From a low-level networking perspective, this can be viewed as a limitation, since the driver cannot access raw packets or inspect non-socket traffic. However, for an ad-blocking application, this behavior is not just acceptable but optimal. All relevant traffic from browsers and user-mode applications goes through standard sockets, and that's exactly what we need to control. At the same time, ignoring low-level driver traffic removes unnecessary complexity, avoids compatibility issues, and keeps the system stable.
diff --git a/docs/adguard-for-windows-8/solving-problems/tdi-driver-and-Chrome-142.md b/docs/adguard-for-windows-8/solving-problems/tdi-driver-and-Chrome-142.md
@@ -33,6 +33,14 @@ Because of this, TDI-based traffic visibility becomes increasingly unstable. In
 
 AdGuard already treats the TDI driver as deprecated, and its complete removal is planned as the product evolves.
 
+## Permanent solution
+
+From v8.0 RC, we’ve added experimental support for the SockFilter driver. It fixes the issue by solving conflicts in the WFP stack. [More information](/adguard-for-windows-8/settings/app-settings/network-settings/).
+
+To use it, go to *Settings → Network → Traffic filtering*, enable traffic filtering, and select *SockFilter (Experimental)* from the list of available options.
+
+Since it's Experimental, there may be bugs. If you notice anything unusual, unexpected, or just plain broken, **you can switch back to TDI or WFP at any time** in the same section.
+
 ## Temporary solution
 
 Certain Windows registry changes can force the browser to stop using AppContainer, causing its processes to run in a non-sandboxed mode again. Network Service stops using the WSK stack and falls back to a network path that the TDI driver can see. AdGuard then regains the ability to filter browser traffic.
@@ -122,7 +130,3 @@ You should see the following policies active:
 If available, click *Reload policies*.
 
 Done!
-
-## Permanent solution
-
-We’re planning to add support for the SockFilter driver in the upcoming versions. It will fix the issue by solving conflicts in the WFP stack. [More information](https://github.com/AdguardTeam/AdguardForWindows/issues/5780).
diff --git a/docs/adguard-for-windows/features/network.md b/docs/adguard-for-windows/features/network.md
@@ -27,7 +27,7 @@ The **TDI** driver is also available, but it is outdated and may cause [filterin
 
 **SockFilter** is an *experimental*, lightweight kernel-mode network driver that works at the socket level (TCP/UDP). Instead of inspecting or modifying packets as they travel through the full Windows networking stack, a sock filter intercepts socket calls (e.g., connect, send, receive, bind) at a higher, more stable abstraction level. This makes it ideal for applications that need to monitor or control network activity without deep packet processing.
 
-Currently, SockFilter Right is still unstable, and you may encounter bugs. When fully tested and implemented, SockFilter has the potential to bring several advantages over other drivers:
+SockFilter was first implemented in v7.22.4 and, currently, it's still unstable, and you may encounter bugs. When fully tested and implemented, SockFilter has the potential to bring several advantages over other drivers:
 
 - **It operates at a higher, socket-level layer**: SockFilter works with socket operations rather than raw packets, making it less complex and more stable than WFP's low-level packet filtering.
 - **No interference with other network drivers**: Because it sits above VPN, firewall, and antivirus WFP filters, it avoids filter-ordering problems and compatibility conflicts common in the WFP stack.

diff --git a/docs/adguard-for-windows/solving-problems/tdi-driver-and-Chrome-142.md b/docs/adguard-for-windows/solving-problems/tdi-driver-and-Chrome-142.md
@@ -33,6 +33,14 @@ Because of this, TDI-based traffic visibility becomes increasingly unstable. In
 
 AdGuard already treats the TDI driver as deprecated, and its complete removal is planned as the product evolves.
 
+## Permanent solution
+
+From v7.22.4, we’ve added experimental support for the SockFilter driver. It fixes the issue by solving conflicts in the WFP stack. [More information](/adguard-for-windows/features/network/#sockfilter-and-other-network-drivers).
+
+To use it, go to *Settings → Network → Traffic filtering*, enable traffic filtering, and select *SockFilter (Experimental)* from the list of available options.
+
+Since it's Experimental, there may be bugs. If you notice anything unusual, unexpected, or just plain broken, **you can switch back to TDI or WFP at any time** in the same section.
+
 ## Temporary solution
 
 Certain Windows registry changes can force the browser to stop using AppContainer, causing its processes to run in a non-sandboxed mode again. Network Service stops using the WSK stack and falls back to a network path that the TDI driver can see. AdGuard then regains the ability to filter browser traffic.
@@ -135,7 +143,3 @@ You should see the following policies active:
 If available, click *Reload policies*.
 
 Done!
-
-## Permanent solution
-
-We’re planning to add support for the SockFilter driver in the upcoming versions. It will fix the issue by solving conflicts in the WFP stack. [More information](https://github.com/AdguardTeam/AdguardForWindows/issues/5780).