My website has a 1% random chance of redirecting visitors to this YouTube video.
The server currently sends the good-old 302, but I want it to have better semantics.
I don't know if the redirect is permanent or temporary. It's permanent in the sense that people always have a 1% chance of being redirected, and it's temporary in the sense that people don't get redirected every single time.
None of the current 3xx response status codes match my website's behavior.
301 Moved Permanently
This and all future requests should be directed to the given URI.[21]
"This and all future requests" - nope, not all future requests.
302 Found (Previously "Moved temporarily")
Tells the client to look at (browse to) another url. 302 has been superseded by 303 and 307. This is an example of industry practice contradicting the standard. The HTTP/1.0 specification (RFC 1945) required the client to perform a temporary redirect (the original describing phrase was "Moved Temporarily"),[22] but popular browsers implemented 302 with the functionality of a 303 See Other. Therefore, HTTP/1.1 added status codes 303 and 307 to distinguish between the two behaviours.[23] However, some Web applications and frameworks use the 302 status code as if it were the 303.[24]
This is confusing. It does state, "302 has been superseded by 303 and 307," so I guess this is obsolete yet still commonly used?
303 See Other (since HTTP/1.1)
The response to the request can be found under another URI using the GET method. When received in response to a POST (or PUT/DELETE), the client should presume that the server has received the data and should issue a new GET request to the given URI.[25]
"The response to the request can be found under another URI" - Rickroll is not the response to the original request. It has nothing to do with my site! "When received in response to a POST (or PUT/DELETE), the client should presume that the server has received the data and should issue a new GET request to the given URI." The last sentence of the 303 description doesn't work with my redirect.
307 Temporary Redirect (since HTTP/1.1)
In this case, the request should be repeated with another URI; however, future requests should still use the original URI. In contrast to how 302 was historically implemented, the request method is not allowed to be changed when reissuing the original request. For example, a POST request should be repeated using another POST request.[30]
"In this case, the request should be repeated with another URI; however, future requests should still use the original URI." Yes! This is what my redirect is. "...the request method is not allowed to be changed when reissuing the original request. For example, a POST request should be repeated using another POST request." Unfortunately, this doesn't work with my redirect. My site randomly Rickrolls users even when they submit forms (POST method).
308 Permanent Redirect (RFC 7538)
The request and all future requests should be repeated using another URI. 307 and 308 parallel the behaviors of 302 and 301, but do not allow the HTTP method to change. So, for example, submitting a form to a permanently redirected resource may continue smoothly.[31]
308 has the same issue as 301 because not all future requests should go to the Rickroll video. Furthermore, the method isn't allowed to change.
What HTTP response status code should my server send for random-chance redirects that have nothing to do with my actual site?
The official source for HTTP response status codes is RFC7231, not Wikipedia. You should peruse RFC7231 Section 6.4 for the explanation of 3XX status codes.
The "redirecting visitors by random chance" thing is irrelevant to the actual redirection, therefore the status code that fits your requirement is 303, which is explained in Section 6.4.4 as follows (emphasis mine):
The 303 (See Other) status code indicates that the server is redirecting the user agent to a different resource, as indicated by a URI in the Location header field, which is intended to provide an indirect response to the original request. A user agent can perform a retrieval request targeting that URI (a GET or HEAD request if using HTTP), which might also be redirected, and present the eventual result as an answer to the original request. Note that the new URI in the Location header field is not considered equivalent to the effective request URI.
303 fits your requirement for three reasons:
Why not 302? Because of this part of the explanation in Section 6.4.3 (emphasis mine):
For historical reasons, a user agent MAY change the request method from POST to GET for the subsequent request.
In other words, the user agent can use either the same request method or a different request method. The flexibility that the specification allows for 302 doesn't fit your requirement.