No access to wss://website.com unless port 443 bypassed

This is expected.   WAF has added support for websockets in recent releases, but Web Filtering has not.  Web Filtering supports HTTP, HTTPS, and FTP protocols only.  You need to create a bypass for this site.

In Website overrides, create a TAG named "Bypass All" and assign it to your website.

In Exceptions, create an exception object, check all the boxes, and configure it for "Going to websites tagged as"  tag="Bypass All".

This approach worked for me for both Standard and Transparent mode.   My best guess is that your first attempt at an exception either had a Regex error or insufficent exceptions.

Check Your Logs

You have not mentioned what your logs say, which implies that you have not been looking at them.   This is a mistake.   The logs will tell you what Filter Profile, Policy, and Exceptions were applied, what action was taken  (id and name), and result (statuscode="value" and error="value".

Exceptions may not work in this situation

There is a possibility that Web Filter cannot handle the unrecognized wss protocol, triggering a failure before the exception can be applied.   The logs should help you know if this is the case.   If it is, then you will have to bypass by other means:

• For Standard Mode, add a line to the proxy script to go DIRECT if the URL begins with wss://
• For Transparent Mode, add a skip list entry for all possible destinations (or all possible sources).

The exception object is preferable because it solves the problem in both modes, and it does so based on URL.  This means that IP addresses do not need to be known in advance.

RegEx may be the right solution

You could create a bypass-all exception to ignore and websocket traffic.   I think the regex would be: $wss:\/\/

On the other hand, you may want to allow websockets only as needed.  If so, then you create exceptions for specific host names, and let the others be blocked by default.

RegEx vs WebSites with Tags

The UTM RegEx logic works.   The problem is ensuring that your RegEx does what you want, with neither unwanted matches nor unwanted mismatches.    I started abandoning RegEx after an unwanted URL was allowed because of a subtle RegEx mistake (a host name was allowed, but it also allowed a URL with the host name embedded in the querystring.

Tags provide several benefits that I love:

• Host name matching without regex:   www.example.com
• Organization matching without regex:   example.com with "include subnets".   
• Just be aware that this only matches one level,
  host1.example.com will match,
  but host1.div1.example.com will not match 
• No need to worry about protocol, http, https, or ftp.  Creating a regex that allows http and https is easy, creating one that supports all three is a little trickier.
• Tags add a little bit of documentation if the Tag name is wisely chosen.
• My successor is more likely to understand a website override than a complex RegEx

Limitations to consider:

• Website exceptions can only evaluate the host name, not the full URL.
• RegEx can match any portion of the full URL, as long as it is visible.
• If the connection is https without decrypt-and-scan, the path and querystring are not visible and cannot be matched.
• I assume that wss is also based on TLS without decrypt-and-scan, so the path and querystring will not be visible to your RegEx

Check Your Logs

You have not mentioned what your logs say, which implies that you have not been looking at them.   This is a mistake.   The logs will tell you what Filter Profile, Policy, and Exceptions were applied, what action was taken  (id and name), and result (statuscode="value" and error="value".

Exceptions may not work in this situation

There is a possibility that Web Filter cannot handle the unrecognized wss protocol, triggering a failure before the exception can be applied.   The logs should help you know if this is the case.   If it is, then you will have to bypass by other means:

• For Standard Mode, add a line to the proxy script to go DIRECT if the URL begins with wss://
• For Transparent Mode, add a skip list entry for all possible destinations (or all possible sources).

The exception object is preferable because it solves the problem in both modes, and it does so based on URL.  This means that IP addresses do not need to be known in advance.

RegEx may be the right solution

You could create a bypass-all exception to ignore and websocket traffic.   I think the regex would be: $wss:\/\/

On the other hand, you may want to allow websockets only as needed.  If so, then you create exceptions for specific host names, and let the others be blocked by default.

RegEx vs WebSites with Tags

The UTM RegEx logic works.   The problem is ensuring that your RegEx does what you want, with neither unwanted matches nor unwanted mismatches.    I started abandoning RegEx after an unwanted URL was allowed because of a subtle RegEx mistake (a host name was allowed, but it also allowed a URL with the host name embedded in the querystring.

Tags provide several benefits that I love:

• Host name matching without regex:   www.example.com
• Organization matching without regex:   example.com with "include subnets".   
• Just be aware that this only matches one level,
  host1.example.com will match,
  but host1.div1.example.com will not match 
• No need to worry about protocol, http, https, or ftp.  Creating a regex that allows http and https is easy, creating one that supports all three is a little trickier.
• Tags add a little bit of documentation if the Tag name is wisely chosen.
• My successor is more likely to understand a website override than a complex RegEx

Limitations to consider:

• Website exceptions can only evaluate the host name, not the full URL.
• RegEx can match any portion of the full URL, as long as it is visible.
• If the connection is https without decrypt-and-scan, the path and querystring are not visible and cannot be matched.
• I assume that wss is also based on TLS without decrypt-and-scan, so the path and querystring will not be visible to your RegEx