The original question was 'Different proxy for each QWebEngineView instance?'
that I read as set-once-and-forget but not as change-later-again-at-runtime
and setting it once (at creation time) is doable - usually by altering command line of those external sub-processess and adding --proxy-server=host:port which also allows to specify different proxy per protocol - and it will work per individual tab or page instance (as long as QWebEngine creates sub-process per each tab/page)
alas altering command line for chromium embedded sub-processes is not exposed in the API
Interesting fact - command line params are actually used but from QApplication::arguments() and we can change them only once by modifying argc/argv before we pass them to QApplication a(argc, argv);
so my point is - infrastructure is there it is just not exposed to changes (per tab/page) and original command line params are blindly re-used over and over again
e.g. that is proper way to set/use custom flash plugin/dll location - with this command line argument:
TLDR; Obviously the Initial command line parameters (or modified argc, argv passed in QAplication constructor into QApplication::arguments()) are used always (send over and over again) on each tab/page creation and sent to its sub-process - alas not exposed for modification(s) in some settings per page or sub-process. If they were exposed I think that would solve proxy-per-tab problem, and I think closing a page and silently creating new one in same tab is a good trade off for solving the dreaded proxy-per-tab problem. Of course it will cause conflicts with currently used QNetworkProxy::applicationProxy - but these are implementation details...
First try a standard demobrowser example - .../Qt/Qt580/Examples/Qt-5.8/webenginewidgets/demobrowser/
Change User-Agent: remove ' QtWebEngine/5.8.0 ' from it - sometimes helps
in demobrowser user-agent is under - Settings.Advanced
Use Wireshark or WebInspector to inspect HTTP headers for extra information being sent like - cookies, headers etc.
--disable-web-security - if they use IFRAMEs
Please pay attention to the fact that so called LFN (Long File Names) are affected not only by length but also by (some) special characters e.g.: 5.8.0 is a LFN so is "5 8 0" with spaces while correct short name will be 5_8_0 or 580
as you can see from my little test here (original/actual name is the last column and short name - IF PRESENT is in the next to last column)
C:\TEMP>dir 5* /x
02/23/2017 10:46 AM <DIR> 580~1 5 8 0
02/23/2017 10:44 AM <DIR> 58D237~1.0 5.8.0
02/23/2017 10:45 AM <DIR> 5_8_0
Visual Studio (especially C/C++ compilers and linker) are notoriously known to stick to Short File Names (SFN)
so my suggestion is to use a shorter path and try to keep it (all the way down) all in SFN