While you probably know "proxy server" as a kind of hub through which Internet requests are processed, this has nothing to do with network communication. Basically Egui_proxy is the icon in the system tray and its purpose is to provide basic UI functionality and open the main UI (egui.exe). Among other benefits it saves several megabytes of memory since egui doesn't have to run all the time.
The problem is Eset SSL/TLS; i.e. HTTPS, protocol scanning uses the Windows Filtering Platform to do so. The installed version of Adguard also does the same and also by default, uses Windows Filtering Platform. That is where the conflict is and why WFP must be disabled in installed Adguard. This doesn't weaken Adguard's SSL/TLS protocol scanning in any way since it will install a network adapter mini-port filter driver instead to do this protocol scanning.
In the browser add-on version of Adguard, it is examining HTTPS traffic after it has been processed by the browser. As such, it can't detect adware/malware as effectively as can be done via examination outside of the browser. However since Eset has already examined that traffic outside of the browser, it would have already detected anything malicious and removed it prior to web page rendering. This means that the only thing left for Adguard to detect is ads and the like. Additionally, other browser add-ons such as uBlock origin are quite capable of removing ads and the like. As such, I really don't understand why folks insist on spending money on the installed version of Adguard.
If the question is if Eset by default monitors for modification of Win firewall rules, the answer is no.
If this is in regards to the Eset firewall, the simplest answer is the following. The Eset Public profile will not allow by default any inbound traffic from other devices on your local network other than the router.