MCP گیٹ وے کے لیے VPS: ایک پتے اور ایک ٹوکن کے پیچھے کئی MCP سرور

خود میزبانی والے MCP سرور بڑھتے جاتے ہیں۔ پہلے اندرونی دستاویزات کے لیے ایک ہوتا ہے، پھر ڈیٹا بیس کے لیے ایک، پھر کوئی ڈیپلائے پائپ لائن کے لیے چھوٹا سا لکھ دیتا ہے۔ ہر ایک کا اپنا پورٹ، اپنا URL اور اپنا راز ہوتا ہے، اور ٹیم کا ہر فرد تینوں کو اپنی کلائنٹ کنفیگ میں چسپاں کرتا ہے۔ ٹوکن بدلنے کا مطلب ہے سب کو پیغام بھیجنا۔

گیٹ وے اسے ایک پتے اور ایک ٹوکن میں بدل دیتا ہے۔ کلائنٹس https://mcp.example.com/docs/mcp، .../db/mcp وغیرہ سے جڑتے ہیں۔ گیٹ وے ٹوکن جانچتا ہے، ہر پاتھ کو localhost پر درست سرور تک بھیجتا ہے، اور سرور خود کبھی باہر نہیں کھلتے۔ اس کے لیے بہت کم چاہیے: اپنے IPv4 والا ایک چھوٹا VPS اور Caddy۔

نیچے کا سیٹ اپ ہم نے ایک ٹیسٹ سرور پر بنایا اور لکھنے سے پہلے اصلی کلائنٹس سے جانچا۔

کیا چاہیے

• عوامی IPv4 والا VPS، تاکہ کلائنٹس 443 تک پہنچ سکیں۔ اگر آپ کے MCP سرور خود بھاری کام نہیں کرتے تو Nano-IP کافی ہے۔
• سرور کی طرف اشارہ کرتے A ریکارڈ والا ڈومین، یہاں mcp.example.com۔
• Ubuntu 24.04 یا Debian 12/13۔ Caddy دونوں کی معیاری ریپوزیٹریز میں ہے۔

1. MCP سرورز کو localhost پر چلائیں

ہر سرور ایک systemd سروس کے طور پر چلتا ہے۔ مثال مکمل رہے، اس لیے یہاں ریفرنس سرور server-everything دو بار استعمال کیا ہے؛ اس کی جگہ اپنے سرور لگائیں۔ اسے Node.js 20 یا نیا چاہیے:

mkdir -p /opt/mcp && cd /opt/mcp
npm install @modelcontextprotocol/server-everything

# /etc/systemd/system/mcp-everything-1.service
[Unit]
Description=MCP server everything #1
After=network.target

[Service]
WorkingDirectory=/opt/mcp
Environment=PORT=3101
ExecStart=/opt/mcp/node_modules/.bin/mcp-server-everything streamableHttp
Restart=always
User=nobody

[Install]
WantedBy=multi-user.target

دوسری کاپی پورٹ 3102 استعمال کرتی ہے۔ پھر:

systemctl daemon-reload
systemctl enable --now mcp-everything-1 mcp-everything-2

ٹیسٹ کے دوران ہم نے دیکھا: یہ سرور صرف 127.0.0.1 پر نہیں بلکہ تمام انٹرفیسز پر سنتا ہے، اور بہت سے دوسرے بھی ایسا ہی کرتے ہیں۔ تیسرا قدم اسے سنبھالتا ہے۔

2. Caddy: پہلے ٹوکن جانچیں، پھر پاتھ سے روٹ کریں

ایک ٹوکن بنائیں اور ماحول کی فائل سے Caddy کو دیں:

apt install -y caddy
echo "MCP_GATEWAY_TOKEN=$(openssl rand -hex 32)" > /etc/caddy/gateway.env
chmod 600 /etc/caddy/gateway.env
mkdir -p /etc/systemd/system/caddy.service.d
printf '[Service]\nEnvironmentFile=/etc/caddy/gateway.env\n' > /etc/systemd/system/caddy.service.d/env.conf
systemctl daemon-reload

Caddyfile:

mcp.example.com {
	route {
		@unauthorized not header Authorization "Bearer {$MCP_GATEWAY_TOKEN}"
		respond @unauthorized 401

		handle_path /everything/* {
			reverse_proxy 127.0.0.1:3101 {
				flush_interval -1
			}
		}
		handle_path /tools2/* {
			reverse_proxy 127.0.0.1:3102 {
				flush_interval -1
			}
		}
		respond 404
	}
}

caddy validate --config /etc/caddy/Caddyfile && systemctl restart caddy

mcp.example.com کا سرٹیفکیٹ Caddy خود حاصل کر لیتا ہے۔

route بلاک سجاوٹ نہیں ہے۔ ہمارے پہلے ورژن میں ٹوکن جانچ اور handle_path بلاکس سب سے اوپری سطح پر ساتھ ساتھ تھے، اور بغیر ٹوکن والی درخواستیں 200 کے ساتھ سیدھی گزر جاتی تھیں۔ Caddy ہدایات کو اپنی ترتیب میں لگاتا ہے، اور handle_path، respond سے پہلے چلتا ہے۔ route کے اندر وہ لکھی گئی ترتیب میں چلتے ہیں۔ اگر آپ یہ کنفیگ بدلیں تو سب سے پہلے "بغیر ٹوکن" والا معاملہ ٹیسٹ کریں۔

handle_path سابقہ ہٹا دیتا ہے، اس لیے /everything/mcp سرور تک /mcp بن کر پہنچتا ہے۔ flush_interval -1 اسٹریم کیے گئے ایونٹس آتے ہی آگے بھیج دیتا ہے۔

3. SSH اور HTTPS کے سوا سب بند کریں

apt install -y ufw
ufw default deny incoming
ufw allow OpenSSH
ufw allow 80,443/tcp
ufw enable

اس کے بعد ہمارے ٹیسٹ میں پورٹ 3101 اور 3102 سرور کے باہر سے نہیں پہنچتے تھے، جبکہ 22 اور 443 جواب دے رہے تھے۔ پورٹ 80 صرف اس لیے کھلا رہتا ہے کہ Caddy سرٹیفکیٹ لے اور تجدید کر سکے اور HTTPS پر ری ڈائریکٹ کر سکے۔

4. جانچیں

TOKEN=$(cut -d= -f2 /etc/caddy/gateway.env)
INIT='{"jsonrpc":"2.0","id":1,"method":"initialize","params":{"protocolVersion":"2025-06-18","capabilities":{},"clientInfo":{"name":"check","version":"1"}}}'
curl -s -o /dev/null -w '%{http_code}\n' -X POST https://mcp.example.com/everything/mcp \
  -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' -d "$INIT"
curl -s -o /dev/null -w '%{http_code}\n' -X POST https://mcp.example.com/everything/mcp \
  -H "Authorization: Bearer $TOKEN" \
  -H 'Content-Type: application/json' -H 'Accept: application/json, text/event-stream' -d "$INIT"

پہلی درخواست کو 401 اور دوسری کو 200 دکھانا چاہیے۔ ہمارے ٹیسٹ میں غلط ٹوکن اور کٹے ہوئے ٹوکن دونوں کو 401 ملا، اور نامعلوم پاتھ کو درست ٹوکن کے ساتھ بھی 404 ملا۔

پھر کسی کلائنٹ سے، مثلاً Claude Code:

claude mcp add --transport http everything https://mcp.example.com/everything/mcp \
  --header "Authorization: Bearer $TOKEN"
claude mcp list

دونوں سرورز نے ✔ Connected دکھایا۔ اسی کلائنٹ نے غلط ٹوکن کے ساتھ ✘ Failed to connect دکھایا۔ کلائنٹ سیٹ اپ کے بارے میں مزید EQVPS MCP کو Claude Code اور Codex سے جوڑیں میں ہے۔

اگلا سرور جوڑنا

اسے نئے localhost پورٹ پر شروع کریں، ایک handle_path بلاک جوڑیں، Caddy ری لوڈ کریں۔ کسی کی کنفیگ نہیں بدلتی، بس اسی ہوسٹ اور اسی ٹوکن کے تحت ایک نیا URL آ جاتا ہے۔

جاننے کے قابل حدود

• سب کے لیے ایک ٹوکن آسان ہے اور اسے بدلنا ایک فائل ہے، لیکن سب کے لیے بدلے بغیر کسی ایک شخص کی رسائی نہیں ہٹا سکتے۔ ہر صارف کے لیے الگ رسائی چاہیے تو آگے تصدیقی پراکسی لگائیں یا ہر شخص کو اپنا روٹ اور ٹوکن دیں۔
• گیٹ وے سرور کو محفوظ نہیں بناتا۔ shell کمانڈز چلانے والا MCP سرور ٹوکن رکھنے والے ہر شخص کے لیے shell ہی رہتا ہے۔ ٹوکن مشترکہ کنفیگز اور git سے دور رکھیں۔
• سائز سرورز کے مطابق چنیں، گیٹ وے کے مطابق نہیں۔ Caddy خود چند درجن MB لیتا ہے۔ اگر کوئی سرور لوکل ماڈل چلاتا ہے یا بڑی ریپوزیٹری انڈیکس کرتا ہے تو پلان وہی طے کرتا ہے، پراکسی نہیں۔

صرف ایک MCP سرور ہے؟ وہ آسان معاملہ MCP سرورز کے لیے VPS میں ہے۔ چاہتے ہیں کہ ایجنٹ اس سرور کو بھی سنبھالیں جس پر وہ رہتے ہیں؟ یہ EQVPS MCP سرور کرتا ہے (یا اسکرپٹ پسند ہوں تو REST API)، اور اپنے IPv4 والے پلانز $8 ماہانہ سے شروع ہوتے ہیں۔