The Jenkins update center retrieval code, as well as the code which obtains tool catalogues, is written to piggyback on the Internet connectivity of the user's browser, rather than directly downloading files. This has the advantage that if the master is not configured for a proxy (or cannot reach the Internet at all) you can still check for updates. But it has a number of disadvantages:

1. The user's bandwidth is taken up, instead of the server's.

2. The security mechanisms needed for this to work—signing to allow non-administrators to do the download, JSONP or postDocument to bypass same-origin restrictions, and some JavaScript AJAX glue—are complex and fragile, so when they break, updates are broken and it is tricky to debug the problem: you need to examine not only the server's logs and the update center's content, but the browser error console too.

3. The download is interrupted by a new page load, so if a user clicks rapidly on several links, Jenkins goes into an exponential backoff procedure which can result in the download being significantly delayed with no clear explanation.

4. The actual downloads of plugins or tools are still done directly, so you cannot really run with the master disconnected from the Internet—you can at best see that there are updates which could be installed.

It would be better to default to making a direct connection, and fall back to the current browser tricks only if that fails.