Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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).
22 changes: 17 additions & 5 deletions docs/adguard-for-windows/features/network.md
Original file line number Diff line number Diff line change
Expand Up @@ -17,24 +17,36 @@ In this module you can select the checkbox *Use AdGuard as an HTTP proxy* to use

At last, there is a section with proxy settings. There you can specify which proxy server AdGuard should use to update filters, get new versions, and so on.

### SockFilter and other network drivers
### Enable Traffic Filtering

In *Network*, you can also enable traffic filtering and choose which driver to use: SockFilter, WFP, or TDI.
Traffic filtering is the core mechanism that allows AdGuard to inspect and control the network traffic generated by applications on your computer. When it is enabled, AdGuard intercepts outgoing and incoming connections and checks them against its filtering rules. If a request matches a blocking rule, AdGuard can block it, modify it, or allow it depending on the configuration. In AdGuard for Windows, this interception is implemented through network drivers.

**WFP** (Windows Filtering Platform) is a powerful driver, but it may present stability risks, such as [occasional system crashes (BSOD)](https://github.com/AdguardTeam/AdguardForWindows/issues/5792) for some users.
If HTTPS filtering is enabled, AdGuard performs a controlled local TLS interception: it decrypts the traffic using its local certificate, applies filtering rules, and then re-encrypts the traffic before sending it to the browser. The driver simply provides the system-level access needed for AdGuard to intercept these connections.

The **TDI** driver is also available, but it is outdated and may cause [filtering issues in some versions of Google Chrome](https://github.com/AdguardTeam/AdguardForWindows/issues/5771). [A temporary workaround exists](https://adguard.com/kb/adguard-for-windows/solving-problems/tdi-driver-and-Chrome-142/), but it’s not a reliable long-term solution.
In *Network*, you can also enable traffic filtering and choose which driver to use: SockFilter, WFP, or TDI.

#### SockFilter

**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.
- **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.

#### WFP

**WFP** (Windows Filtering Platform) is a Microsoft networking framework built into Windows that allows software to filter and monitor network packets at different layers of the system networking stack. AdGuard uses WFP to safely hook into the network flow of applications and apply filtering rules before the traffic reaches the browser or the internet. [More information](https://learn.microsoft.com/en-us/windows/win32/fwp/windows-filtering-platform-architecture-overview).

While it is a powerful driver, it may present stability risks, such as [occasional system crashes (BSOD)](https://github.com/AdguardTeam/AdguardForWindows/issues/5792) and lower internet speed for some users.

#### TDI

The **TDI** driver is also available, but it is outdated and may cause [filtering issues in some versions of Google Chrome](https://github.com/AdguardTeam/AdguardForWindows/issues/5771). [A temporary workaround exists](https://adguard.com/kb/adguard-for-windows/solving-problems/tdi-driver-and-Chrome-142/), but it’s not a reliable long-term solution.

### AdGuard VPN

The last section is dedicated to AdGuard VPN — an ideal tool that provides security and anonymity each time you browse the Internet. You can download it by clicking the *Download* button or go to the AdGuard VPN website by clicking the *Homepage* button.
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -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.
Expand Down Expand Up @@ -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).
Loading