I’ve had Charles Proxy 4.6.2 (Registered Version) installed and running a-ok for weeks now, using the Unity guide…
My initial testing was carried out using the Player build. But I’ve just tested the Windows UWP build and have noticed some odd behaviour. Even stranger is the Player build has started behaving oddly as well.
With “Windows Proxy” Off
Player - Events.CheckForRequiredConsents() succeeds >> Network io not captured
UWP - Events.CheckForRequiredConsents() succeeds >> Network io not captured
And With “Windows Proxy” On
Player = Events.CheckForRequiredConsents() succeeds >> Network io captured
UWP = Events.CheckForRequiredConsents() fails with network unreachable >> Network io not captured (*)
(*) Closing Charles Proxy unblocks the consent call and it then succeeds, but network io is still not captured.
The results have been reproduced across reboots, multiple times.
I’ve uninstalled Charles Proxy, removed the settings & root cert and re-installed\configured and am seeing the same behaviour.
I thought it might be ESET Smart Security causing problems, but disabling the firewall & network protection makes no difference.
It’s not Unity either as “Network io not captured” also means any network io, not just Unity.
Then again, I’m not convinced it’s Charles Proxy either.
It’s really odd and has me completely baffled.
I wasn’t sure where to post this, but if anyone could shed some light on this it would be hugely appreciated.
@PeachyPixels If you are testing from the Windows platform and not a device, Windows Proxy would need to be on. Please share a screenshot of your SSL Proxying settings. Charles itself is probably blocking the requests without the proper SSL settings. Also, you need to ensure to install the root certificate, move it to the correct certificate store as mentioned, and REBOOT your system. You are welcome to also try with Fiddler, a similar tool.
It’s a fresh Charles Proxy install (default settings) with the Unity changes made as per the support article. I’ve definitely rebooted after root cert install. Screenshots attached.
I’ve no Charles Proxy stores for the Server, Client & Root Certs on the SSL Proxy settings, but assume they’re not needed (and not covered in the article)
Everything looks as expected, but it’s blocking SSL calls by the looks of it.
It works fine in the Player, but not in the UWP build. Which is what made me think it’s the firewall blocking. But disabling that makes no difference either.
So I’ve pretty much ruled out the the ESET Firewall.
I can see Charles change the Windows Proxy settings and root HTTP/HTTPS traffic via the local loopback to port 8888. This change is reset when Charles is closed.
It seems Win32 apps are working just fine in terms of traffic. I’ve tried many and traffic isn’t blocked and shows in Charles.
But UWP apps are not. I’ve tried another Unity app and multiple UWP apps (from the store) and all of them appear to be blocked by Charles, hence no traffic.
I think this is why it’s working in the Unity Player but not in a build.
Your screenshots are correct, and are the same as in the article. I meant the cert store on Windows, as you have in the screenshot. Thanks for confirming. Please share your Charles .chls file in a private message, I’ll ensure the settings are correct. And thanks for the links, interesting! Personally I have not used Charles on a UWP (built) app locally.
Tbh it’s not worth sending a session (.chls) file as absolutely nothing is recorded. I tried and the file was empty, save for what looked like a header. All calls made from the game seem to be blocked before (or by) the proxy before they’re registered.
At best I can send you a settings file, but it’s the default settings with the Unity changes applied, so not of any real use.
If you ever find time, maybe you could fire up a UWP Unity app and see if you can replicate the behaviour? That might at-least indicate a wider issue, rather than one specific to my setup.
I’ll also raise a support ticket with the Charles developer and see what they say.
@PeachyPixels Understood. This is likely a Unity issue, not Charles, since it’s working for you when running in the Player. The bug is marked as lower priority and marked Won’t Fix unfortunately. I can ping the team, but no guarantee.
