1. Check your Portal/Service Fabric /Overview blade After clicking the above error link,  you will see the error details, for example:
2. Check Service Fabric Explorer (SFX)
   • Open your SFX Url link from portal, click "Cluster" and go to the "DETAILS" Tab, for example, my SFX Url is https://hzsfdemo.centralus.cloudapp.azure.com:19080/Explorer/index.html#/tab/details
   • First, you will see the Upgrade Domain walk and UD processing information
   • Second, you will get the Health and Monitoring Policy and Timeout settings
   • Finally, you will be able to see the current upgrade status and what the upgrade is working on.
   • For my scenario, it is waiting for EnsureSeedNodeQuorum for about 1:20+ hours. Now, you narrowed down the issue to ENUM type EnsureSeedNodeQuorum. You can check the explanation for it @ https://msdn.microsoft.com/en-us/library/azure/mt163586.aspx and start to understand the possible cause of the problem.
3. Use PowerShell Get-ServiceFabricClusterUpgrate to get the upgrade status and error during and after the upgrade
   • Call Connect-ServiceFabricCluster from a RDP session on one of primary nodetype node without any parameter. Since you are in VM already, this will bypass the security check. Or you can pass the X509Certificate or AADCredential to create the PowerShell connection per Connect-ServiceFabricCluster doc.
   • Call Get-ServiceFabricClusterUpgrade during the Fabric Upgrade or even after the Fabric Upgrade. For my situation in above screenshot, the upgrade domain 1 stuck on the PreUpgradeSaftyCheck for EnsureSeedNodeQuorum till upgrade domain timeout. Now, you narrow down the issue to ENUM type  EnsureSeedNodeQuorum. You can check the additional explanation for it @ https://msdn.microsoft.com/en-us/library/azure/mt163586.aspx
4. Additional, RDP into the node and check event viewer for "Microsoft-Service Fabric" Admin and Operational Event logs
   • RDP and Open eventvwr from a Service Fabric cluster node
   • Check Application and Services Logs \ Microsoft-Service Fabric Event check both Admin/Operational events for errors and warnings details Now the issue is identified as a seed node missing problem.

Here is my answer: the .Net Framework proxy detecting/loading, is using the following MSDN setting combination:
 http://msdn.microsoft.com/en-us/library/sa91de1e.aspx
<proxy
  autoDetect="true|false|unspecified" 
  bypassonlocal="true|false|unspecified"
proxyaddress="uriString"
  scriptLocation="uriString"
  usesystemdefault="true|false|unspecified "
/>

By default, autoDetect is set as unspecified, which equals to enabled. It means the proxy is automatically detected. The proxy auto detection follows this white paper for design.
http://msdn.microsoft.com/en-us/magazine/cc300743.aspx
“Automatic configuration is a two-step process. First, the user agent (Internet Explorer or the .NET Framework) tries to discover the URL of a configuration script. Typically, the configuration script is a JavaScript file that contains logic to determine whether to use a proxy and what proxy to use for a given target resource. The protocol for automatic detection is documented at Web Proxy Auto-Discovery Protocol. The user agent first tries a DHCPINFORM message. The reply to this message contains the URL of the configuration script. If that doesn't work, a DNS lookup for a well-known alias, WPAD, is issued. Then the configuration script's location is determined as http://<machine>/wpad.dat where the machine name is the result of the DNS lookup.

The second step is to download the configuration script from the URL and run the script. The specification of what the configuration script looks like is at Navigator Proxy Auto-Config File Format. And then parse and run the proxy auto configuration (PAC) script.”
This detection implementation is expensive, take time and also require you have either DHCP server or DNS set up correctly. If you are using a middle tier server type of client, for performance consideration, we will need to disable it to save the time spent on proxy detection routine.

The 2nd proxy detection is using IE proxy. It is controlled through setting, usesystemdefault="true|false|unspecified "
usesystemdefault:  Specifies whether to use Internet Explorer proxy settings. If it is set to true, subsequent attributes will override Internet Explorer proxy settings. The default value is unspecified, which equals to true.
But this setting may not work well for a service. A service typically doesn’t have any IE profile with proxy setting. Creating a IE profile for a service account is like a hacking. usesystemdefault setting is more designed for a log on user type of application instead of service. IE proxy connection is implemented through wininet.dll, but wininet.dll is not supported in service.

http://support.microsoft.com/kb/238425
INFO: WinInet Not Supported for Use in Services
So, we will discourage using the IE proxy setting and creating an IE profile for a service account to load proxy in .Net as it will make the proxy loading behavior hard to be predicted if a service has some user impersonation implemented.

For the middle tier or service type of client app, we can set the proxy use the following choice:
  bypassonlocal="true|false|unspecified"
proxyaddress="uriString"
  scriptLocation="uriString"
We can using proxy address to well specify the proxy information combined with proxy bypass rule. If you have to use the proxy auto configuration (PAC) script rule, you can use the choice in scriptLocation. This way, we can well control the proxy loading behavior to avoid delay on Proxy detection or unpredictable result for using impersonated account to load IE proxy setting.

A configuration sample is listed below:
<configuration>
  <system.net>
    <defaultProxy>
                <proxy
                autoDetect="false"
                usesystemdefault="false"
                proxyaddress="http://myproxy:80"
                bypassonlocal="true"
                />
      <bypasslist>
        <add address="[a-z]+\.contoso\.com$" />
        <add address="127.0.0.1" />
      </bypasslist>
    </defaultProxy>
  </system.net>
</configuration>

The difference is abbreviated handshake is using 32 bit existing SSL session ID for Client Hello. If SSL server agreed on this session, server doesn't need to send the public key of certificate back to client. Also, client doesn't need to take time to validate the server cert as it is an existing session. If server doesn't agree on the SSL session, server needs to push a new session ID and then go to full handshake.

Here is the table for the time SSL session been cached:

If SSL server side doesn't understand the abbreviated SSL handshake and doesn't handle it correctly, you may see some random issue for SSL connection drop. Framework System.Net trace or Network sniffer trace can help to identify whether the current SSL handshake is trying to go through cached session. The key difference is: no certificate payload in server hello message.

Windows gives the choice for disable SSL cache session reuse through Reg Key.

ClientCacheTime is DWORD in millisecond unit. When you set the key as 0 and reboot machine, SSL cached session will not be reused.