Although non-normative, the browsers are generally following the well-reasoned User Agent Implementation Advices from RFC 6797, 12 for not letting the user to bypass the errors if there's a known HSTS policy in place.
12.1. No User Recourse
Failing secure connection establishment on any warnings or errors (per
Section 8.4 ("Errors in Secure Transport Establishment")) should be
done with "no user recourse". This means that the user should not be
presented with a dialog giving her the option to proceed. Rather, it
should be treated similarly to a server error where there is nothing
further the user can do with respect to interacting with the target
web application, other than wait and retry.
Essentially, "any warnings or errors" means anything that would cause
the UA implementation to announce to the user that something is not
entirely correct with the connection establishment.
Not doing this, i.e., allowing user recourse such as "clicking through
warning/error dialogs", is a recipe for a man-in-the-middle attack. If
a web application issues an HSTS Policy, then it is implicitly opting
into the "no user recourse" approach, whereby all certificate errors
or warnings cause a connection termination, with no chance to "fool"
users into making the wrong decision and compromising themselves.
If you need to be able to MitM your own connections e.g. for testing or debugging purposes, the only way around HSTS is to install the root CA certificate of your HTTPS proxy as a trusted root CA. This way the certificate used by the proxy becomes a valid certificate and, therefore, HSTS isn't a problem.
According to Provide a Bettercap's CA certificate to integrate into browser #536, the root CA certificate of Bettercap would be stored in /root/.bettercap-ca-cert.pem
.