Cable Modem Troubleshooting Tips


Web Proxy issues: on this page:

The transparent web caches

Your ISP's network might intercept all attempts you make to connect to the web (by means of the HTTP protocol on TCP port 80), and route your request through a transparent web proxy cache, technically known as an interception proxy. NTLworld used Inktomi Traffic Servers, but is now introducing NetApp NetCache appliances. Your ISP does this in order to reduce the traffic on their backbone, and to reduce the traffic they exchange with other operators' networks. If a proxy cache works well, it can also improve performance for the customer, by supplying locally cached copies of web pages and graphics much more quickly than by fetching them from the remote original web server.

However, when the proxy web cache is overloaded, it can make your web browsing appear slower than the nominal speed of your cable modem. For this reason, you should not rely on HTTP download speeds as evidence of the practical speed of your cable modem.

According to reports, Blueyonder no longer enforce transparent web proxies (in some regions?), but permit their users to configure Blueyonder's web proxies explicitly if they wish.

Which is my web proxy cache?

You can find out whether your web connection is being proxy cached, and, if so, the address of the web proxy cache, by visiting either of these sites:

Because the ISP might be load-balancing across more than one web proxy cache, your web connections might use different proxy caches for different web destinations. So you might get different answers from the two sites above. And the actual cache used for your other web accesses might be different yet again. When load-balancing is in operation, the above sites will identify an individual cache in a cluster of caches, and the DNS names of the caches will usually have an obvious structure enabling you to deduce the names of other members of the cluster.

For instance, with NTL web proxy cache clusters, the DNS names of the individual caches are of the form:

and N is the number of the cache within the cluster.

Refreshing stale pages in the web cache

While a copy of a page is stored in a proxy cache, the original page could be updated, and users would never see it, because the proxy will return the stale copy to users. Even if a browser user clicks on Refresh or Reload, the proxy will still return the stale version.

With MSIE for Windows, the fix is to use Ctrl-Refresh (hold down the Ctrl key while clicking on Refresh) or Ctrl-F5, which causes the transparent proxy to refresh its copy of the page from the original web server. However, Ctrl-Refresh does not work with:

See;EN-US;Q266121 for more details. The faulty versions of MSIE send cache-control commands on Refresh or Ctrl-Refresh only if they know it is using a user-configured proxy. A fixed version of MSIE, such as MSIE 5.5+SP1 sends a cache-control command also for Ctrl-Refresh even when functioning without a user-configured proxy, and so works better with transparent proxies. If you have faulty versions of MSIE 5.01 or 5.5, use Windows Update to update MSIE with the latest service pack.

MSIE 5.0 for Mac and earlier versions have similar problems. It sends cache-control requests only if it knows it is using a user-configured proxy, and does not send cache-control requests when working without a configured proxy. Therefore there is no way to flush stale pages from a transparent proxy cache. This was fixed in version MSIE 5.1 for Mac (download, so that Option-Refresh will always send cache-control commands. An ordinary Refresh will not work.

Another method which works is to use Netscape (on any platform) as your browser. In Netscape, clicking Reload always causes the proxy cache to conditionally refresh the page from the original server. Clicking Shift-Reload (Option-Reload for Mac Netscape earlier than version 6) forces the proxy cache to unconditionally refresh the page from the original server.

As of March 2001, transparent web proxy caches in some regions of the NTL network have been reconfigured so that Ctrl-Refresh/Shift-Reload/Option-Reload no longer force a reload from the original server, unless the page had been updated. This is technically incorrect, though it yields the right visible results. It will however, yield incorrect timings if you had been trying to time downloads from the original server: you will only get a download from the proxy.

In cases where the transparent proxy cache is a Network Appliance NetCache, to ensure that you get a full refresh from the original server, you should perform a full browser refresh (Ctrl-Refresh in IE, or Shift-Reload in Netscape) twice, with the second one following the first after a gap of at least 1 and not more than 10 seconds.

Another technique to force a fresh copy of a page through a proxy cache to your browser is to edit the URL by appending a question mark followed by a string chosen to be different each time you try this trick. For instance, if the URL was originally:

then the first time you want a fresh copy, you would edit it to be:

and the second time you want a fresh copy, you would edit it to be:

and so on. This works because the cache treats these URLs as being references to different documents. However, there are drawbacks to this technique:

How to sidestep the transparent web caches

When your default transparent proxy cache breaks down, you lose all contact with the web. Because it is a transparent cache, there is no setting you can adjust on your computer to cause it to go direct to the remote site rather than via the proxy.

You can however defeat the transparent web cache by configuring your web browser explicitly to use another working proxy cache that accepts requests on a port other than 80 (usually 8080 or 3128). Because the request is made on a port other than 80, the transparent cache does not intercept the request.

In choosing an alternative HTTP (web) proxy server name, try the following in order of preference for performance:

The higher in the list above, the better the web browsing performance is likely to be. You should revert to normal working (with no explicit proxy setting) when your default transparent proxy has recovered.

Each application that used the HTTP protocol is likely to have its own HTTP proxy configuration, every one of which might need setting. Just setting the HTTP proxy for Internet Explorer will not affect the HTTP settings for (e.g.) Netscape, RealPlayer, QuickTime Player, etc.

Setting an explicit web proxy in Internet Explorer for Windows

The following procedure works on all Windows platforms running Internet Explorer 5.x/6.x, and the procedure for Internet Explorer 4.x is very similar:

The last few stages in Advanced avoid using the proxy for Secure HTTPS and FTP traffic, and ensure that you retain local access to any cable modem diagnostics pages and to any NAT router setup pages, which typically use addresses in the range

To return Internet Explorer to normal operation with no explicit web proxy:

Setting an explicit web proxy in Internet Explorer for Macintosh OS 8.x/9.x

To set an explicit web proxy in MSIE 5.x under Mac OS 8.x/9.x:

Setting an explicit web proxy in Mac OS X 10.3 for Safari or Internet Explorer

To restore to normal working, repeat the above, but leaving Web Proxy (HTTP) unchecked.

Setting an explicit web proxy in Netscape or Mozilla

To restore to normal working:

Setting an explicit web proxy in Firefox

To restore to normal working:

NTL web proxy caches (use port 8080) are as follows.

Old naming scheme:
2003 naming scheme:
2004 naming scheme:

where xxx is the old 3-character abbreviation for the area, and yyyy is the new 4-character abbreviation. N is the number of the cache in the cluster.

In the list below, sites marked Ink are believed to running Inktomi Traffic Servers; other sites are believed to be running NetApp NetCache appliances. Caches listed in italics were not working when last checked (23 April 2006). (Ashford)  [ash/asfd] (Baguley)  [bagu] (Belfast)  [bel/blfs/belf] (Birmingham)  [bir/brhm] (Brentford)  [bre/brnt] (Brighton)  [btn/brtn/brig] (Bristol)Ink  [bri/bstl] (Bromley)Ink  [bro/bror/bmly] (Cambridge)  [cam/cmbg] (Cardiff)  [cdf/cdif] (Colchester)  [col/colc] (Cosham)  [cos/cos2/cosh] (Dublin)Ink  [dub/dbln] (Edinburgh)Ink  [edi/edin] (Guildford)  [gui/glfd] (Hersham)Ink  [her/herm/hers] (Huddersfield)Ink  [hud/hudd] (Langley)Ink  [lng/lang] (Leeds)  [lee/ldst/leed] (Leicester) (Luton)  [lut/lutn] (Manchester)  [man/mant/manc] (Middlesbrough)  [mid/midd] (Northampton)  [nth/nrth] (Nottingham)  [not/nott] (Oxford)  [oxf/oxfd] (Peterborough)  [pet/pete] (Poplar)  [pop/popl] (Renfrew)  [ren/renf] (Southampton)  [sot3/sotn] (Swansea)Ink  [swa/swan] (Watford)  [wat/wtfd/watf] (Winnersh)  [win/winn]

Blueyonder web proxy caches (either port 8080 or 3128) appear to be:          * (London N)            (London W)          * (London S)      * * *          * (London SE)            (Midlands)            (Birmingham)          * (South West)            (North East)          * (North West)            (Yorkshire)          * (Scotland)

The caches marked with an asterisk are available on a round-robin from

Web authoring tips for dealing with caches

Web authors should (some say must) include hints in their pages as to how web caches should treat them. If your pages are static, and rarely subject to change, then you need take no action: the caches will cache your page and end-users will see correct results. If your pages are dynamic (created on the fly) or subject to frequent updates, then you must include a hint to web caches that they should check back for updates, otherwise they will cache your page and serve stale copies to clients. The mechanism for doing the hinting is the cache-control line in the HTTP headers, fully described in RFC 2616.

There is no mechanism for authors to generate custom HTTP headers on

Some authors advise that web authors can achieve the same effect with a meta tag in the HTML headers of their page, for instance:

        <meta http-equiv="cache-control" content="no-cache">
        <title>My page</title>

In fact, those authors are wrong. Web caches take no account of meta HTML headers; they respond only to HTTP headers. The meta tag above would work only if the hosting web server is of the type that promotes meta http-equiv HTML tags to true HTTP headers on the fly as the page is served out.

The server does not promote meta http-equiv tags to HTTP headers.

The server does not promote meta http-equiv tags to HTTP headers.

For more detailed information on authoring in a cache-aware manner, see

Return to Index.