Every Servlet application can have multiple Filter implementations executing before reaching the actual Servlet. And the big picture is something like this:
Spring provides a Filter implementation named DelegatingFilterProxy that allows bridging between the Servlet container’s lifecycle and Spring’s ApplicationContext. The Servlet container allows registering Filters using its own standards, but it is not aware of Spring defined Beans. DelegatingFilterProxy can be registered via standard Servlet container mechanisms, but delegate all the work to a Spring Bean that implements Filter.
With this picture in mind, we can say that the DelegatingFilterProxy is an approach that Spring MVC uses to use its own standards when registering filters.
When you expose a Spring Bean that implements Filter, it will get registered inside the DelegatingFilterProxy.
FilterChainProxy is a special Filter provided by Spring Security that allows delegating to many Filter instances through SecurityFilterChain. Since FilterChainProxy is a Bean, it is typically wrapped in the DelegatingFilterProxy.
You can see that this hypothetical picture above has the FilterChainProxy as a second filter in the Filter Chain (the dashed box). Once the FilterChainProxy is done processing its SecurityFilterChain filters, it will call the originalChain (dashed box) to resume the processing of the remaining filters, in the above scenario, Filter2.
There's also a great explanation in the Spring Security reference where I took most of the resources present in this text.
If you want to prevent a Filter to be registered by Spring, you can refer to this question on StackOverflow.
