Additionally, the blocking page returns 200 status code, which is also wrong as it pretends it to be correct result and not error page (which could be properly handled by the client then).

My IP is also blocked

This raises some questions that are probably unrelated to the problem at hand, but might affect things indirectly:

• Why is an internal service (wdqs) querying a public endpoint? It should probably use private internal endpoints like appservers.svc or api.svc, but there may be arguments about desirability of [Varnish] caching. This is something we're grappling with in general in the longer-term (trying to understand and/or eliminate private internal service<->service traffic routing through the public edge unnecessarily).
• Why is it using webproxy to access it? It should be able to reach www.wikidata.org without any kind of proxy.

Why is an internal service (wdqs) querying a public endpoint?

It needs to load Wikidata data, and I don't know any other way to do it.

It should probably use private internal endpoints like appservers.svc or api.svc, but there may be arguments about desirability of [Varnish] caching.

It doesn't need varnish. If you point me to the docs of how to do it better, I can switch the URLs.

Why is it using webproxy to access it?

It seems to work the same with or without proxy (unless there's a config by puppet that sets the proxy by default?) but my understanding was production hosts need proxy to talk to the web. I've enabled proxy because in the past I had issues reaching www.wikidata.org from production without proxy.

Yes, I verified, I get the same block with curl --noproxy \*. Just different IP in the error message.

In T199146#4409455, @BBlack wrote:

This raises some questions that are probably unrelated to the problem at hand, but might affect things indirectly:

• Why is an internal service (wdqs) querying a public endpoint? It should probably use private internal endpoints like appservers.svc or api.svc, but there may be arguments about desirability of [Varnish] caching. This is something we're grappling with in general in the longer-term (trying to understand and/or eliminate private internal service<->service traffic routing through the public edge unnecessarily).

That specific request seems to be trying to bust cache nocache=1531160117052 so bypassing varnish caching is probably not an issue. In the more general context, there are probably instances where caching makes a lot of sense.

• Why is it using webproxy to access it? It should be able to reach www.wikidata.org without any kind of proxy.

That's probably an historical mistake, no reason that I can think of.

Note that the same request directly from wdqs1009.eqiad.wmnet (curl -v 'https://www.wikidata.org/wiki/Q18289639?action=constraintsrdf&nocache=1531160117052') also gives an HTTP 200 Blocked. Same from elastic2035 (just for fun). But same request from my own desktop gives an HTTP 204 NO CONTENT.

For the record, 204 NO CONTENT or 200 with RDF output is the right answer. For most items, it's 204 no content.

It looks to me that the block is done by mediawiki itself (see P7355 for details):

< x-cache: cp1066 pass, cp1054 pass
< x-cache-status: pass

That looks like varnish just lets it through. (Note that I have no idea how those blocks are working, just trying to guess).

Yeah looks like ipblocks table for wikidata has block on 2620:0:862:101:0:0:0:0/96 by user "Merlissimo" with comment 'Toolserver Range - no anon edits' but this doesn't seem to match wdq9. So probably not this one.

In T199146#4409514, @Smalyshev wrote:

Yeah looks like ipblocks table for wikidata has block on 2620:0:862:101:0:0:0:0/96 by user "Merlissimo" with comment 'Toolserver Range - no anon edits'.

That block goes from 2620:0000:0862:0101:0000:0000:0000:0000 to
2620:0000:0862:0101:0000:0000:ffff:ffff. It does not match either webproxy or wdqs1009

This block seems to be driven by $wgSoftBlockRanges setting in CommonSettings.php, which includes $wgSquidServersNoPurge, which includes private WMF IPs.

	// Addresses used by WMF, people should log in to edit from them directly.
	$wgSquidServersNoPurge

Now we need to figure out why it thinks we're editing anything.

Hi @Jonas: I blocked that particular range, among others allocated to Telefonica Germany, in an attempt to enforce this global ban. @Multichill and @MisterSynergy can tell you more about what has been going on. If you'd like me to lift that particular range block, I'd be happy to do this, but please be aware of what you may be allowing to happen.

Looks like we don't need to change blocks - instead, 'constraintsrdf' should be marked as read action not requiring blocks check.

Change 444736 had a related patch set uploaded (by Smalyshev; owner: Smalyshev):
[mediawiki/extensions/WikibaseQualityConstraints@master] Set requiresUnblock to false for CheckConstraintsRdf

https://gerrit.wikimedia.org/r/444736

Change 444736 merged by jenkins-bot:
[mediawiki/extensions/WikibaseQualityConstraints@master] Set requiresUnblock to false for CheckConstraintsRdf

https://gerrit.wikimedia.org/r/444736

In T199146#4409514, @Smalyshev wrote:

Yeah looks like ipblocks table for wikidata has block on 2620:0:862:101:0:0:0:0/96 by user "Merlissimo" with comment 'Toolserver Range - no anon edits' but this doesn't seem to match wdq9. So probably not this one.

Toolserver? Unblocked.