CSC, v6.3, HTTP 503 Error

Unanswered Question
Aug 6th, 2010
User Badges:


We just put in a CSC v6.3 and occassionally when browsing out we get an HTTP 503 Unavailable error, but when we reload the page it loads. Anyone else experience something like this? Any known fixes?

This happens with well-known sites such as,, etc.



  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Kureli Sankar Fri, 08/06/2010 - 13:06
User Badges:
  • Cisco Employee,


If you remove the module from the flow - meaning when the CSC module is not scanning the http traffic you never see these 503 erros?

Make sure the CSC module is using a proper DNS server IP address to resolve names.


BEN ROBINSON Fri, 08/06/2010 - 13:10
User Badges:

well i haven't "removed" the CSC from the flow... but we didn't have the issue before the CSC was put in a few days ago... and the DNS is correct, it's our internal server.

Kureli Sankar Fri, 08/06/2010 - 13:36
User Badges:
  • Cisco Employee,

Directly connected to the CSC module in the same segment?  If not pls. change the DNS to and see if this resolves the issue.


BEN ROBINSON Fri, 08/06/2010 - 14:25
User Badges:

Yes, the DNS server is on the same segment. I'll try changing it anyhoot.

Magnus Mortensen Fri, 08/06/2010 - 19:51
User Badges:
  • Cisco Employee,

      When the CSC module returns a 503 error it means that the connection between the CSC module socket and the webserver was reset or timed out. How often does it happen? If it happen always (google) never loads then we need to figure out what the proxied connection from the CSC to the web server fails.

First, lets talk about how the module works. The CSC acts like a transparent proxy. When you browse to Google you actually are connecting to a TCP socket on the CSC module. Once you form that connection (browser to csc) and send your HTTP GET request, the CSC checks to make sure the page is allowed etc. If all is well, the CSC then opens a socket (mimicking the same source ip as the first socket) to the destination webserver (Google). Once the content is transferred, the module scans the content and then passes it back on the first socket.

If the connection between the CSC and the webserver is broken (timeout or torn down prior to us sending the GET request on the socket), we get a 503.

Just as a test (since I have seen this is some strange corner cases) can you load up Firefox and reproduce the problem. After doing so, go to 'about:config' in Firefox and filter for "network.http.keep-alive" and set it to false. Close Firefox and try to reproduce the problem again. Just on a hunch.. If this 'fixes' it for Firefox, then my hunch is that that we are trying to pass GET request on closed sockets (something I have seen in prior cases). There are some tricks we can do in CSC version 6.3.1172.3 to tweak connection behavior to prevent this... but we can talk about that when the time comes...

If the Firefox trick does not help, let me know and we can re-tool for a different approach...

- Magnus

BEN ROBINSON Tue, 08/10/2010 - 15:05
User Badges:


I found out the users were not typing www. in the URL of their browser, they were just putting "". So far, that seems to have fixed it! Thanks for everyone's assistance. I'll post again if the issue creeps up again.


dhammink47 Thu, 12/16/2010 - 06:54
User Badges:


We have this behaviour to and also with sites with www  Furthermore we need to test if our domains function without www.

And it is dreadfully slow (sites that download normally within 300 ms  take 4 seconds with URL filtering ...)

if anyone has a good idea.

BEN ROBINSON Thu, 12/16/2010 - 22:11
User Badges:

Make sure your DNS server that is specified in the CSC is reachable and can resolve all the web site addresses.

Also, for the slowness, try tweaking the HTTP settings for scanning (such as increasing the threshold for sizes, etc). That normally works.

dhammink47 Fri, 12/17/2010 - 00:16
User Badges:

Hi Ben,

Thanks for your answer. The DNS server are reachable (and are really close by and fast, checked that already). I can only tweak ate Scanning tab and then only for large files. Or do you know other places where I can tweak. The websites I am talking about are really small and still take 4 sec (read this one to )

If it does a check to the CSC server for every GET in a page (which it looks like it does, because that explains the amount of DNS wait time firebug sees, most likely trend Micro tells the Browser it is doing a DNS ). I think that is pretty sloppy programming you could keep already checked URL's in an array ...

Anyway I hope we find an answer otherwise I have two Anti-X modules for sale :-)

Kind regards,

David Hammink


This Discussion

Related Content