Didn't see instructions for this anywhere else when I searched, so adding this here.
TL;DR: It works. Steps:
Make a file in "%localappdata%\EgnyteWebEdit" called "config.txt" with your explicit proxy settings.
Make sure that webedit.egnyte.com isn't going through the proxy (add it to your PAC file/explicit proxy bypass list).
Lock it down with Windows Firewall and AppLocker, since WebEdit binds its local webserver to 127.0.0.1:9404 on startup. (Also: don't deploy it to systems that don't need it, and don't set it to run automatically on user login.)
SSL proxying should Just Work, as long as your PKI's deployed to the computer-level stores.
Egnyte WebEdit currently supports configuration for explicit proxying by creating a config.txt file in your EgnyteWebEdit settings folder (in %LOCALAPPDATA%). Parameters:
proxy_host: The address of your explicit HTTP proxy. (IPv4 addresses and DNS names are both supported. Haven't tested IPv6.)
proxy_port: The destination port number of your explicit HTTP proxy.
Here's a PowerShell one-liner to generate this file and add the parameters to it (replace both <> with your settings):
You could deploy this as a startup script along with the installer to your targets, or your could just have a custom GPO that pushes the file itself.
SSL proxying is supported as well, as long as your PKI is deployed correctly to the host machine (root CAs in computer-level Trusted Root Certificate Authorities store, any intermediate CAs in computer-level Intermediate Certificate Authorities store).
If you're seeing s_client errors in the WebEdit logs in such an environment, the most likely cause is that you deployed the PKI to the user-level store instead, so double-check your GPOs and gpupdate /force on the host.
When you click "Edit on your desktop" in your browser, it passes the file URL to WebEdit by sending the browser's HTTP request to webedit.egnyte.com:9404, which is a webserver that WebEdit spins up on your local machine.
That DNS name resolves to 127.0.0.1 (yes, really), so make sure that the DNS name is in your PAC file as a DIRECT host (or, if you use GPOs to push proxy settings manually, make sure that it's in the list of IPs/DNS names that don't go through the proxy).
If Egnyte ever decides to modify WebEdit to register a custom URI scheme instead of running a local webserver, then this step is obsolete.
General security considerations:
Since that local webserver is a security risk, you'll want to lock it down at least a little bit: if your host-based firewalls don't block requests to it already, make sure you have a rule in there that does.
WebEdit should only ever write to files in the user's temp directory. Have some AppLocker rules in place to make sure that the binary can't try to do anything else.
Limit your deployment targets! Don't deploy WebEdit to your whole enterprise, just to the hosts that actually need it.
Don't set WebEdit to automatically run on user login.
Hope this helps someone else; I didn't see any official KBs about any of this.