Application switch causes the issue which can be explained in the sample session detail output as below:
> show session id 1005336
Session 1005xxx
c2s flow:
source: aa.aa.aa.aa [TC-NET]
dst: bb.bb.bb.bb
proto: 6
sport: 49609 dport: 80
state: INIT type: FLOW
s2c flow:
source: bb.bb.bb.bb [TC-NET]
dst: aa.aa.aa.aa
proto: 6
sport: 80 dport: 49609
state: INIT type: FLOW
start time : Tue Dec 2 xx:xx:xx xxxx
timeout : 30 sec
total byte count(c2s) : 508
total byte count(s2c) : 5738
layer7 packet count(c2s) : 5
layer7 packet count(s2c) : 5
vsys : vsys1
application : teamviewer-base
rule : allow_all
layer7 processing : enabled
URL filtering enabled : True
URL category : any
captive portal session : False
ingress interface : ethernet1/xx
egress interface : ethernet1/xx
session QoS rule : N/A (class 4)
session tracker stage l7proc : ctd stop proc
URL category shows 'any' and 'session tracker stage l7proc' shows 'ctd stop proc'.
This is because the application turns into another app rather than web-browsing already, which is using TCP/80.
In the above example the application is detected as teamviewer. As this app has its own decoder, it is not considered to be a web-browsing app anymore.
PAN only do the URL-Filtering in http decode for sure but it is not always for specific application decode.
Similar to the "teamviewer-base" app returning URL category as "any", "facebook-base" returns "social-networking". The app detection/URL category detection depends on application decode setting and it is hard-coded. Customers cannot change the behavior.
Please do not control the web app by url category profile. Specifying application in the security rule will work for application management.