I use two wan PCC "loadbalancing" ( basically followed this method http://mum.mikrotik.com/presentations/US12/steve.pdf )
Often pc web browsers hang with " waiting for website...."

It doesn't happen if I disable a wan interface (no matter which one)

I know there are issues with HTTPS sites using the method per-connection-classifier=both-addresses-and-ports I'm using, so I've added dst-port=!443 to those rules, anyway it happens with http sites .

What else could I check ??

Thank you

No good news yet, also a single user with a routing mark rule placed before PCC ones to bypass PCC mechanism, experience navigation issue
It seems however that calls made trough a WAN doesn't get the right answer or answer through diferent wan
here's my mangle rules :

D chain=forward action=change-mss new-mss=1440 passthrough=yes tcp-flags=syn protocol=tcp out-interface=all-ppp tcp-mss=1441-65535  
D chain=forward action=change-mss new-mss=1440 passthrough=yes tcp-flags=syn protocol=tcp in-interface=all-ppp tcp-mss=1441-65535  
D comment=special dummy rule to show fasttrack counters chain=prerouting
D comment=special dummy rule to show fasttrack counters chain=forward
D comment=special dummy rule to show fasttrack counters chain=postrouting
chain=prerouting action=accept dst-address=10.0.10.0/24
chain=prerouting action=accept dst-address=10.0.20.0/24  

chain=input action=mark-connection new-connection-mark=WAN1_conn passthrough=yes in-interface=ether23
chain=input action=mark-connection new-connection-mark=WAN2_conn passthrough=yes in-interface=ether24  
chain=output action=mark-routing new-routing-mark=to_WAN1 passthrough=no connection-mark=WAN1_conn  
chain=output action=mark-routing new-routing-mark=to_WAN2 passthrough=no connection-mark=WAN2_conn  

comment=wan1-pfw chain=forward action=mark-connection new-connection-mark=WAN1_pfw passthrough=no connection-state=new in-interface=ether23
comment=wan2-pfw chain=forward action=mark-connection new-connection-mark=WAN2_pfw passthrough=no connection-state=new in-interface=ether24  
comment=wan1-pfw chain=prerouting action=mark-routing new-routing-mark=to_WAN1 passthrough=no in-interface=ether1 connection-mark=WAN1_pfw  
comment=wan2-pfw chain=prerouting action=mark-routing new-routing-mark=to_WAN2 passthrough=no in-interface=ether1 connection-mark=WAN2_pfw  

comment=Paul_use_wan1 chain=prerouting action=mark-routing new-routing-mark=to_WAN1 passthrough=no src-address=192.168.1.100 dst-address=!192.168.1.0/24  

chain=prerouting action=mark-connection new-connection-mark=WAN1_conn passthrough=yes connection-state=new protocol=tcp dst-address-type=!local in-interface=ether1 dst-port=!443 per-connection-classifier=both-addresses-and-ports:2/0  
chain=prerouting action=mark-connection new-connection-mark=WAN2_conn passthrough=yes connection-state=new protocol=tcp dst-address-type=!local in-interface=ether1 dst-port=!443 per-connection-classifier=both-addresses-and-ports:2/1  
chain=prerouting action=mark-routing new-routing-mark=to_WAN1 passthrough=no in-interface=ether1 connection-mark=WAN1_conn  
chain=prerouting action=mark-routing new-routing-mark=to_WAN2 passthrough=no in-interface=ether1 connection-mark=WAN2_conn  


Interfaces :

Wan1 = 10.0.10.2/24 gw 10.0.10.1  (ether23)
Wan2 = 10.0.20.2/24 gw 10.0.20.1  (ether24)
LAN =  192.168.1.1/24 (ether1)
192.168.1.100 machine has to use exclusively WAN1

Please, any idea ??

Thank you

Does it do it for every site, or just a few? Try moving to just "both-addresses" if it's just for a few sites that are having problems, you can also remove the dst-port=443 restriction that way.

It is very random... fortunately it happens in few percent of visited websites, i can't say if some site is more affected than another, it seems not.

I'm checking now with both-addresses only , I'll let you know

I will also check the per-bandwidth method as in http://mum.mikrotik.com/presentations/US12/tomas.pdf  and see how it behaves....( anyone with a review about ?? )

I think we have similar problems. 

I'm in China. Here we have 3 internet vendors across the country. Let's say Y, L, and M. They provide good connection if both the server and client are inside their network. However, they only provide limited bandwidth for users who want to access servers in another network. This is only a start.

In order to improve the speed of users from different networks, almost all important websites provide different servers for users from different vendors. For example, if users are from Y, when they ping the website, they'll get an IP address which the server is inside Y network. The real problem starts.

As for PCC, the connections are spreaded into different wan, so it's possible that the user get a server ip from Y, but the actual http connection is from L or M. This connection will be very slow compared with normal situation. 

DNS is another problem. Y,L and M limit the access of their DNS to their own users. It means if you ping the DNS server you get from ADSL1, but actually the ping is from ADSL2, you'll not get a response.

To solve the DNS problem, you can specify a public DNS provider, and don't use the one you get from your vendors by ADSL or whatever.
To solve the server problem, I don't have any idea yet. 

Just realized that this issue is related to the use of "fast track" feature added as rule in firewall filter , as in my recent post http://forum.mikrotik.com/viewtopic.php?f=13&t=110560

Unfortunately not yet an useful answer....  

Please read description what fasttrack is bypassing
http://wiki.mikrotik.com/wiki/Manual:Wiki/Fasttrack

Mrz, thank you, 
 as per wiki :

Note that not all packets in a connection can be fasttracked, so it is likely to see some packets going through slow path even though connection is marked for fasttrack. This is the reason why fasttrack-connection is usually followed be identical action=accept rule. Fasttracked packets bypass firewall, connection tracking, simple queues, queue tree with parent=global, ip traffic-flow(restriction removed in 6.33), ip accounting, ipsec, hotspot universal client, vrf assignment, so it is up to administrator to make sure fasttrack does not interfere with other configuration;

So, it seems to be not always a good solution, it depends by working environment.
Since it is normal to have configurations listed above bypassed by fasttrack, when is this feature really useful ?
Should we assume fasttrack with pcc has to be avoided ? 

any updates on this? I've been struggling with this issue for months!! I've posted numerous posts across here, reddit, and IRC that got me nowhere until I systematically disabled every rule in the firewall as a first attempt before re-configuring PCC from scratch and BOOM, it worked when Fast Track was disabled! despite what is said in the link provided by @mrz, the line immediately after the default Fast Track rule of accept has no effect and still breaks PCC unless Fast Track is disabled. if there's a fix for this it would be welcome, but I'm glad to finally put this months long issue to rest!

EDIT: looks like the MikroTik gods have spoken http://forum.mikrotik.com/viewtopic.php ... 21#p551668

I had the same problem and have a solution but unsure if it's the right way to do it.

Please see here:
viewtopic.php?f=13&t=110560&p=586865#p586865