Jenkins主从节点连接异常求助：连接被拒/超时及Windows服务启动问题

Hey there, let's tackle this Jenkins master-slave connection issue you're facing—those random rejects/timeouts after running for a while plus Windows service startup failures are definitely frustrating. I've dealt with similar headaches before, so here's what works:

Immediate Workarounds for Connection Rejects/Timeouts #

• Force a protocol fallback: The error java.lang.Exception: The server rejected the connection: None of the protocols were accepted often stems from mismatched JDK versions or protocol negotiation issues between master and slave. Try explicitly setting the slave to use older, compatible protocols on startup:
  When launching the slave agent (either via command line or service config), add this JVM argument:

  -Djdk.tls.client.protocols=TLSv1.2,TLSv1.1
  

  This forces the slave to use TLS versions that the master might be expecting, avoiding protocol mismatches that cause sudden connection drops.
• Reset the agent session: Over time, the agent's connection pool can get corrupted. Stop the slave agent completely, kill any leftover Java processes related to Jenkins (check Task Manager on Windows), then restart it. If using the Windows service, make sure to stop the service first and verify no stray java.exe processes are running before restarting.
• Rule out firewall/antivirus interference: Even if it worked initially, some security tools might start blocking the Jenkins agent port (default is 50000, but could be custom) after periods of inactivity. Add permanent allow rules for the Jenkins master IP and agent port on both machines. Also, check if your antivirus has behavioral detection that's flagging the Jenkins agent as suspicious and terminating the connection.

Fixing Windows Service Startup Failures #

• Re-register the service cleanly: If your first service install failed, you might have invalid leftover registry entries. Uninstall the existing service first (run Command Prompt as Administrator):

  jenkins-slave.exe uninstall
  

  Then re-install it with corrected arguments (including the protocol fix above):

  jenkins-slave.exe install --javahome "C:\Path\To\Your\JDK" --jar "C:\Path\To\jenkins-slave.jar" --arguments "-Djdk.tls.client.protocols=TLSv1.2,TLSv1.1 -jnlpUrl http://your-master-url/computer/your-slave-name/slave-agent.jnlp -secret your-slave-secret"
  

  Double-check the JDK path (use a full JDK, not just JRE, to avoid missing libraries) and ensure the jnlpUrl and secret are copied exactly from your slave's configuration page in Jenkins.
• Fix service account permissions: The Windows service needs permissions to access the Jenkins jar file, write to its working directory, and establish network connections. Run the service under a local admin account (or a domain account with sufficient privileges) instead of the default Local System account, which can have restricted network access.

Known Jenkins Bug Context #

This protocol mismatch issue is indeed a known bug in certain Jenkins versions—especially when pairing newer JDK 11+ with older Jenkins LTS releases. The root cause is often the master's TLS configuration failing to properly negotiate with the slave's JVM. While Jenkins has patched this in recent LTS versions (2.346.3+), if you can't upgrade immediately, the workarounds above should keep your agents running reliably.

内容的提问来源于stack exchange，提问作者Max