I am using proxy set in sonarlint.ls.vmargs but after pressing “Save Connection” getting the error:
Failed: com.google.gson.stream.MalformedJsonException: Use JsonReader.setLenient(true) to accept malformed JSON at line 1 column 12 path $
Hi @roman_mashchak,
Could you please share your Proxy configuration?
This error typically happens when the HTTP client tries to parse as JSON a response that is definitely not JSON - usually, it’s a HTML page with the proxy authentication error.
This documentation page explains the properties you can set; you can check that there are no mistakes.
Thank you for using SonarLint! 
I have used same setting like 2 weeks ago but switched to different VDI with windows 11 instead of windows 10. And another difference is sonarlint extension version it was 4.4.2 and 4.5.0.
from settings.json
"sonarlint.ls.vmargs": "-Dhttps.proxyHost=proxy_url -Dhttps.proxyPort=8080",
On VS Code, it’s required to specify the credentials for authentication. Could you try to set https.proxyUser and see if it works?
I will bring up the discussion internally about having proxy settings without authentication.
What I said is not correct. I’m redirecting the thread to the appropriate team.
Error is exactly the same.
"sonarlint.ls.vmargs": "-Dhttps.proxyHost=proxy.url -Dhttps.proxyPort=8080 -Dhttps.proxyUser=USER",
Hello 
thanks for coming back with the new result.
By chance, do you know what kind of authentication your proxy uses?
As far as I can tell, there was a recent change in how SonarLint for VSCode handles proxy authentication. I suspect that the previous implementation was compatible with “transparent” authentication schemes (e.g. NTLM), but the new one is not.
Could you maybe check with an older version of the extension, e.g. 4.3.0? It should be the last version that used the previous proxy authentication implementation.
Hello Jean-Baptiste
Yes, it is NTLM authentication.
< Proxy-Authenticate: NTLM
< Proxy-Authenticate: Basic realm="McAfee Web Gateway"
Downgrading to 4.3.0 resolved the issue and I successfully connected.
Thanks for confirming that reverting to the older version restores connectivity.
This is not an ideal situation, we definitely don’t want you to be stuck with this old version.
Web proxies are capricious beasts, between the different protocols and auth mechanisms, and it would be impractical for us to maintain an infrastructure to test all different combinations.
In this case, I would be curious to see what happens if, instead of passing the -Dhttp(s).proxyXxx=zzz properties, we use -Djava.net.useSystemProxies=true and let the JVM rely on the system-configured proxy.
Would you be willing to help us investigate and try this with the latest version? Thanks!
-Djava.net.useSystemProxies=true
This setting is working with latest 4.5.1 sonarlint extension.
On Windows 11 we don’t have http_proxy or https_proxy env variables set but in system network settings we have pac file for proxy configuration
Thank you for confirming this!
We will make sure to mention it in relevant documentation.