The connection check URL actually used is part of the update center metadata, see the comment.

You'll need to host your own update center and replace the URL with one that can be reached from your network.

@Daniel
In my update, I mentioned that I changed google url in source code, but still not work.
According to the logs I attached, this maybe lead to another problem. It seems connected to UpdateSite.java line no. 789
After some test, I found that "job" in "UpdateCenter.InstallationJob job = uc.getJob(dep);" returned null.

How would it be null then?

Why do you think that that value being null is a problem?

Did you change the connectionCheckUrl entry in updated/default.json (replace default by the update center name if you changed its configuration)? Because the hard-coded value you're referencing is never actually used...

Finally, I know what's the cause.
As you said, the log did nothing wrong.

It's due to two other hard-coded google urls:

Line 333 in method getConnectionCheckUrl() of UpdateSite.java:
if(dt==null) return "http://www.google.com/";

and

key-value "connectionCheckUrl": "http://www.google.com/" in $JENKINS_HOME/updates/default.json

This is a weird one.

On one hand, it makes sense to allow update centers to do their own connectivity check configuration, to account for corporate intranets. And it's a very rare situation that Google cannot be reached while still having actual connectivity, so it's a good default for the public update center. So I'd really like to resolve this as Won't Fix, unless you have a nice, generally applicable solution available.

OTOH, telling you to fix your network issues would lead nowhere. And I assume this affects all Chinese users, so a straightforward solution would be good. How easy (or difficult) would it be to route google.com to a host you can connect to, such as baidu, in your hosts file or local DNS?

I do not think changing hosts file is a good idea.

IMHO, the best solution at present is a graceful error notice appearing when checking connectivity hang there after some time. That notice should guide user to change the url in `key-value "connectionCheckUrl": "http://www.google.com/" in $JENKINS_HOME/updates/default.json `

JENKINS-15124 notes that some shit proxies return nice looking error pages instead of error responses, so having a reference URL with defined content that can be compared would be nice.

Please answer the question in the comment from Oct 11 if you're still interested in a solution to this.

If the need in the end is that it is possible to reach the update site, then why bother checking www.google.com, why not check that you can reach the update site?

It is possible to rsync the update site and update the update site URL in Jenkins, so it appears to be a valid use case to have an internal update site anyway. In that case this internet issue is artificial and should be able to be avoided if desired as a configuration option within the update management IMO.

Any update on this problem?

I can ping updates.jenkins-ci.org and download package manually but cannot use the update center.

I guess the problem is because the server is behind GFW. But why bother test against other site when you want to connect to THE SITE if I follow the comments correctly.

If you want to update some plugins, you can modify jenkins_home/updates/default.json ,change connectionCheckUrl from http://www.google.com/ to some one you can access ,maybe https://www.baidu.com for china, then reload configuration,and install plugins.But jenkins will get this file daily,so if you need,you can do it.

pipehappy

danielbeck: What do you think?

Could we just set http://updates.jenkins-ci.org/ as the connectivity check URL in the JSON? It is reliable, and is what the code currently checks anyway at the moment (after checking Google):
https://github.com/jenkinsci/jenkins/blob/jenkins-1.647/core/src/main/java/hudson/model/UpdateCenter.java#L1062

If you can't reach the Jenkins update server, then you have problems anyway. In the worst case, if that host really is down, then the user would be informed, and asked if they need to make proxy changes. But that should be rare, and the same would happen anyway for people in countries where Google can end up being blocked.

Just wondering, as somebody was asking about the connection check URL here:
https://github.com/jenkinsci/backend-update-center2/pull/40#issuecomment-183517346

I have no idea if this helps at all, but seganw you might be to hit our mirrors directly for your update-center.json.

A list of the mirrors can be found here and from each mirror listed you should be able to navigate to updates/ and then select either the latest update-center.json or the LTS version (stable/update-center.json)