In another thread ppalias said he used a set of NetBalance rules to basically divide the IP address range into two halves when considering HTTP/S connections. One half he always routes through one interface, the other half through the other.
Yup you are right, I had some issues with OpenVPN with the static routes, so I created 2 pairs of Netbalancer rules for the destination ports 80 and 443 for the 0.0.0.0/1 and destination 22.214.171.124/1.
As long as the rules for HTTP are the same as for HTTPS then the site would see the same IP from you for both protocols.
You have three interfaces which does not work into powers of two very well. But maybe dividing things like this might work:
IP range: 0.0.0.0/2 use interface 1
IP range: 126.96.36.199/2 use interface 2
IP range: 188.8.131.52/2 use interface 3
IP range: 192.0.0.0/4 use interface 1
IP range: 184.108.40.206/4 use interface 2
IP range: 220.127.116.11/4 use interface 3
IP range: 240.0.0.0/4 pick an interface
(I hope I have those subnet ranges close.)
Anyway that would roughly spread your HTTP/S traffic equally among the three interfaces based on the destination address. (5/16s of the traffic on two interfaces and 6/16s of the traffic on the third).
Assuming that the HTTPS and HTTP servers are in the same general part of the IP address range, what ever route is picked for your HTTPS session would be the same route for the HTTP session.
I hope that we can figure out how to make routing decisions for destinations “sticky” which would solve this problem for everyone without resorting to this type of hack.