So, I had this ongoing issue with bundler:

Errno::ECONNRESET: Connection reset by peer - SSL_connect
(...)/.rbenv/versions/3.4.1/lib/ruby/gems/3.4.0/gems/net-protocol-0.2.2/lib/net/protocol.rb:46:in 'OpenSSL::SSL::SSLSocket#connect_nonblock'
(...)/.rbenv/versions/3.4.1/lib/ruby/gems/3.4.0/gems/net-protocol-0.2.2/lib/net/protocol.rb:46:in 'Net::Protocol#ssl_socket_connect'
(...)/.rbenv/versions/3.4.1/lib/ruby/3.4.0/net/http.rb:1736:in 'Net::HTTP#connect'
(...)/.rbenv/versions/3.4.1/lib/ruby/3.4.0/net/http.rb:1636:in 'Net::HTTP#do_start'
(...)/.rbenv/versions/3.4.1/lib/ruby/3.4.0/net/http.rb:1631:in 'Net::HTTP#start'

TL;DR

I asked Claude Code to fix that for me and, quite surprisingly, it did.

The culprit was webfilterproxyd which macOS sets up for when you enable web content filtering (in System Settings).

I’ve seen plenty of resources about bundler SSL errors, but I haven’t found any that link them to webfilterproxyd. So I’m leaving this here in case it helps someone else.

Whole story

I had this error for a long time. Simple fixes like reinstalling or recompiling Ruby kept failing. And I really did not want to reinstall my entire OS. I was going around in circles and often got misled by ChatGPT and Google.

While scripts like check.rb and doctor.rb are super useful and might help you debug your bundler SSL issues, they weren’t so helpful with mine:

  Trying connections to https://rubygems.org:

  Bundler:       ❌ failed     (Connection reset by peer - SSL_connect)
  RubyGems:      ❌ failed     (Errno::ECONNRESET: Connection reset by peer - SSL_connect (https://rubygems.org))
  Ruby net/http: ❌ failed

  Unfortunately, this Ruby can't connect to rubygems.org. 😡

  Even worse, we're not sure why. 😕

Because in my day-to-day job I worked with Claude Code with some success, I decided to give it a go. It had already proved useful not only for writing code but also for analysing and using the terminal.

Prompt? Super simple. I literally just asked “halp”:

I ran check.rb can got this error:

<output here>

I was trying to fix that for a long time, don't want to reinstall entire system. Halp?

And halp it did! First, it told me to reinstall Ruby, which I knew would not help. Then the miracle happened (highlight mine):

⏺ Bash(ruby -ropenssl -rnet/http -e "
      http = Net::HTTP.new('rubygems.org', 443)…)
  ⎿  opening connection to rubygems.org:443...
     opened
     starting SSL for rubygems.org:443...
     … +2 lines (ctrl+o to expand)

⏺ The TCP connection opens but fails immediately when starting SSL. Let me test with Ruby 3.3.6 to see if this is a Ruby 3.4.1 specific issue:

⏺ Bash(~/.rbenv/versions/4.0.1/bin/ruby -rnet/http -e "uri = URI('https://rubygems.org'); Net::HTTP.start(uri.host, uri.port, use_ssl: true) { |http| puts http.head('/…)
  ⎿  Error: Sibling tool call errored

⏺ Wait! I see something interesting - Ruby 3.3.6 shows peeraddr=127.0.0.1:10011 which means there's a local proxy running on port 10011! Let me check your proxy settings:

⏺ Bash(lsof -i :10011)
  ⎿  COMMAND     PID          USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
     ZoomUpdat  4880 bartoszkrajka   30u  IPv4 0x97dad948ef274a55      0t0  TCP localhost:49683->localhost:10011 (ESTABLISHED)
     Vivaldi   15035 bartoszkrajka   19u  IPv4 0x2e3e4ee0554961f4      0t0  TCP localhost:49267->localhost:10011 (ESTABLISHED)
     … +17 lines (ctrl+o to expand)

⏺ Found the culprit! There's something running on port 10011 that's acting as a local proxy. Vivaldi browser, Zoom, and other apps are connecting to it. Let me find what's actually listening on that port:

⏺ Bash(ps aux | grep -i proxy | grep -v grep)
  ⎿  root              1942   0,1  0,2 417001968  39792   ??  Ss   15wrz25  95:10.49 /System/Library/PrivateFrameworks/WebContentAnalysis.framework/Resources/webfilterproxyd
     bartoszkrajka    14650   0,0  0,0 426916544   8128   ??  S    10sty26   0:00.25 /System/Library/Frameworks/Security.framework/Versions/A/Resources/CloudKeychainProxy.bundle/Contents/MacOS/CloudK
     eychainProxy
     … +5 lines (ctrl+o to expand)

⏺ There's something listening on port 10011. I see webfilterproxyd which is macOS's web content filtering proxy (often used with parental controls or MDM). This is intercepting your SSL connections!

It wanted to continue the investigation, but for me that was enough! I remembered that some time ago I had set up my macOS to filter out some web pages in the browser. I can then safely say I’ve cooperated with Claude, rather than relying on it entirely 😅.

Apparently that thing spawns webfilterproxyd. I just turned that thing off, restarted the OS, and voilà. No more SSL errors.

The whole thing cost me less than $1 and took maybe 10 minutes, including the OS restart.

Honestly, that is impressive. To figure this out on my own, I would have had to dust off my knowledge of networking and Unix tools. And even then, I am not sure I would find a local proxy running on port 10011 an interesting fact.

So folks, remember that webfilterproxyd can cause bundler SSL errors. And hats off to Claude Code for its impressive analytical power.