Skip to content

Fix proxy port configuration for non-default SERVER_PORT #555

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 5 commits into from
Jun 27, 2025

Conversation

felixweinberger
Copy link
Contributor

@felixweinberger felixweinberger commented Jun 24, 2025

Pass proxy port via URL parameters when using non-default SERVER_PORT

Motivation and Context

Fixes the issue raised by @cliffhall in #529 where the client cannot connect to the proxy server when SERVER_PORT is set to a non-default value.

When the proxy server runs on a non-default port (not 6277), the client doesn't know about it and tries to connect to the default port. This creates a chicken-and-egg problem:

  • The client needs to know the proxy port to fetch configuration from /config
  • But it needs to connect first to get that configuration

Changes:

  • Modified getClientUrl() in start scripts to include MCP_PROXY_PORT parameter when non-default
  • Updated client to read MCP_PROXY_PORT from URL parameters and use it for proxy connection
  • Updated server to display the complete URL with port parameter for consistency
  • Replaced magic number '6277' with DEFAULT_MCP_PROXY_LISTEN_PORT constant

How Has This Been Tested?

Default port: npm run dev - works Custom port: SERVER_PORT=8888 npm run dev - works, client connects to port 8888 Production: npm run build && SERVER_PORT=9090 npm start - works
CleanShot 2025-06-24 at 11 59 32 CleanShot 2025-06-24 at 12 00 08 CleanShot 2025-06-24 at 12 00 49

Breaking Changes

None.

Types of changes

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change (fix or feature that would cause existing functionality to change)
  • Documentation update

Checklist

  • I have read the MCP Documentation
  • My code follows the repository's style guidelines
  • New and existing tests pass locally
  • I have added appropriate error handling
  • I have added or updated documentation as needed

Additional context

@felixweinberger felixweinberger changed the base branch from main to fweinberger/client-localhost June 24, 2025 10:36
Copy link

github-actions bot commented Jun 24, 2025

🎭 Playwright E2E Test Results

✅  12 passed

Details

12 tests across 1 suite
 22.7 seconds
 1aea337
ℹ️  Test Environment: Ubuntu Latest, Node.js 18
Browsers: Chromium, Firefox

📊 View Detailed HTML Report (download artifacts)

@felixweinberger felixweinberger force-pushed the fweinberger/fix-proxy-port-config branch 4 times, most recently from 0df3ce3 to f7cbeab Compare June 24, 2025 10:53
@felixweinberger felixweinberger marked this pull request as ready for review June 24, 2025 11:03
Copy link
Contributor

@cliffhall cliffhall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One little refactor request.

Base automatically changed from fweinberger/client-localhost to main June 26, 2025 09:05
@felixweinberger felixweinberger force-pushed the fweinberger/fix-proxy-port-config branch from 6424232 to 554a922 Compare June 26, 2025 09:41
- Update client to read MCP_PROXY_PORT from URL parameters
- Update server to include port in displayed URL when non-default
- Update start scripts to pass SERVER_PORT to client
- Use DEFAULT_MCP_PROXY_LISTEN_PORT constant instead of magic numbers

This fixes the issue where the client couldn't connect to the proxy
when SERVER_PORT was set to a non-default value.
Address PR feedback by restructuring getClientUrl to always include
MCP_PROXY_PORT parameter when using non-default port, regardless of
auth status. Also improved code clarity by using params.size check.
@felixweinberger felixweinberger force-pushed the fweinberger/fix-proxy-port-config branch from 554a922 to 9e9419b Compare June 26, 2025 09:52
Copy link
Contributor

@cliffhall cliffhall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Non-default server port is working great, and if combined withDANGEROUSLY_OMIT_AUTH, also does the right thing.

Screenshot 2025-06-26 at 11 59 19 AM Screenshot 2025-06-26 at 12 00 43 PM

There is one more wrinkle. If the user also has MCP_AUTO_OPEN_ENABLED set to false, then they are left with the situation of having no link that will actually open a working inspector. The MCP Inspector is up and running at http://localhost:6274 message isn't enough, it would also need to have ?MCP_PROXY_PORT=7777 appended.

Screenshot 2025-06-26 at 12 04 14 PM

Refactored startProdClient to match startDevClient's logging pattern,
ensuring consistent user feedback whether auto-open is enabled or disabled.

Also ensures that we log full information on how to open the browser
regardless of whether MCP_AUTO_OPEN_ENABLED=false.
Simplifies the startup flow by consolidating browser opening
in the client script rather than the start script for prod.

We were duplicating a lot of logging, making it easy for
logs to go out of sync - this is a proposal to consolidate:

- server only logs info about itself
- client only logs info about itself

To reduce the number of places we print connection information
to the user.
@felixweinberger felixweinberger force-pushed the fweinberger/fix-proxy-port-config branch from dad3696 to 042e7a2 Compare June 27, 2025 14:01
@felixweinberger
Copy link
Contributor Author

felixweinberger commented Jun 27, 2025

There is one more wrinkle. If the user also has MCP_AUTO_OPEN_ENABLED set to false, then they are left with the situation of having no link that will actually open a working inspector. The MCP Inspector is up and running at http://localhost:6274 message isn't enough, it would also need to have ?MCP_PROXY_PORT=7777 appended.

Addressed in ae1aeb3. On closer look I also found we were logging URLs repeatedly, making it potentially confusing to the user which is the correct place to go, so I made a proposal in 042e7a2 how we could unify all this logging to be cleaner. End result:

Without auto-open and auth:

npm run build && npm run start npm run dev
CleanShot 2025-06-27 at 14 51 00@2x CleanShot 2025-06-27 at 14 50 12@2x

With auto-open & auth:

npm run build && npm run start npm run dev
CleanShot 2025-06-27 at 14 52 08@2x CleanShot 2025-06-27 at 14 52 37@2x

For comparison - before this change it would look like this (note the duplicated links & info):

npm run build && npm run start npm run dev
CleanShot 2025-06-27 at 14 56 11@2x CleanShot 2025-06-27 at 14 54 15@2x

Copy link
Contributor

@cliffhall cliffhall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One small change below.

But also I now notice that if the Inspector is already running and you start it again, it does not report that the proxy is running and stop. Instead it creates a new token and launches anyway. The new instance works and the old instance stops working.

Here is a video demonstrating it.

Instead of launching the second instance, I would expect the following response, which is what is happening on main at the moment.
Screenshot 2025-06-27 at 10 43 18 AM

Replace explicit property assignments with shorthand syntax when
property names match variable names (e.g., SERVER_PORT: SERVER_PORT
becomes just SERVER_PORT).
@felixweinberger
Copy link
Contributor Author

felixweinberger commented Jun 27, 2025

One small change below.

But also I now notice that if the Inspector is already running and you start it again, it does not report that the proxy is running and stop. Instead it creates a new token and launches anyway. The new instance works and the old instance stops working.

Here is a video demonstrating it.

Instead of launching the second instance, I would expect the following response, which is what is happening on main at the moment. Screenshot 2025-06-27 at 10 43 18 AM

Interesting - I wasn't able to reproduce this. If I start 2 instances, they conflict as they should:

CleanShot 2025-06-27 at 18 19 38@2x

In your video it looks like one of the versions running is 0.14.3 though (the one in puzzlebox?) - I believe that one predates #513 (your video still shows the string (Auto-open is disabled when authentication is enabled), but it was removed in #513)

We had established here #513 (comment) that the reason no conflict was being detected is the difference between *:6277 binding to IPv6, while localhost:6277 binds to IPv4. I think the same thing is at play here - if you run a checkout of this branch in 2 terminals, it should conflict like it did for me.

In any case if I check out a separate worktree of 0.14.3 and main side by side, they don't conflict either - so that behavior is unrelated to this change, #555.

CleanShot 2025-06-27 at 18 16 29@2x

Copy link
Contributor

@cliffhall cliffhall left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! 👍

@cliffhall cliffhall merged commit c24d2a9 into main Jun 27, 2025
7 checks passed
@cliffhall cliffhall deleted the fweinberger/fix-proxy-port-config branch June 27, 2025 17:28
@cliffhall
Copy link
Contributor

cliffhall commented Jun 27, 2025

We had established here #513 (comment) that the reason no conflict was being detected is the difference between *:6277 binding to IPv6, while localhost:6277 binds to IPv4.

@felixweinberger Yep, that was it. Apologies and thanks for checking. I've been battling a bad RSV type bug all week and my head's still full of cotton. 🤧

@felixweinberger
Copy link
Contributor Author

felixweinberger commented Jun 27, 2025

We had established here #513 (comment) that the reason no conflict was being detected is the difference between *:6277 binding to IPv6, while localhost:6277 binds to IPv4.

@felixweinberger Yep, that was it. Apologies and thanks for checking. I've been battling a bad RSV type bug all week and my head's still full of cotton. 🤧

No problem thanks for the review :) hope you feel better soon!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants