[App Creation] Basic Concepts of Web Servers and Proxies - Learning through Apache Configuration

Hello everyone talking to Generative AI!

The story about running the AI partner I wrote about in the previous article as an AI agent.To achieve this, I first started the configuration to use an MCP server on the server!

I was proceeding with the server configuration while being taught by Claude, but
this is a record of the questions and learning that started from the question that arose during that process What is a proxy?.

What is a proxy?

It is used in a completely different sense from the generally known 'skewer (anonymization)'. I will explain the concept of a proxy in a Web server in an easy-to-understand manner through Apache configuration.

Difference from a general proxy (skewer)

General proxy (skewer):

• Access anonymously by hiding the IP address

• Purpose of concealing identity

Web server proxy:

• Intermediary/Bridge role

• Function to forward access to another server

Role of a proxy in a Web server

ブラウザ → Apache(80/443ポート) → Django MCPサーバー(3000ポート)

Role of Apache:

1. Receive access from the outside (HTTPS support with SSL certificate)

2. Forward to the internal Django app (app running on port 3000)

3. Return the response from Django to the outside

Understand with concrete examples

ユーザー: https://example.com にアクセス
↓
Apache: 「あ、exampleへのアクセスだ。内部の3000ポートに聞いてみよう」
↓
Django: 「MCPサーバーのレスポンスです」
↓
Apache: 「じゃあそれをHTTPSで返すね」
↓
ユーザー: MCPサーバーの画面が表示される

Why use a proxy configuration?

Problems with Django alone

• Django uses a development server (weak security)

• SSL certificate management is cumbersome

• Not good at serving static files

Advantages of Apache + Proxy

• Strong security (Apache handles external requests)

• Easy SSL certificate management (supports Let's Encrypt)

• High speed (leave tasks Apache is good at to Apache)

Structure of Apache configuration files

Relationship between sites-available and sites-enabled

sites-available:

• A 'warehouse' for configuration files

• Does not work just by being here

• Stores multiple site configurations

sites-enabled:

• Configurations that are actually running

• Symbolic links (shortcuts) from sites-available

# 確認コマンド
ls -la /etc/apache2/sites-enabled/
# → 001-myapp-ssl.conf -> ../sites-available/001-myapp-ssl.conf

Concept of Virtual Hosts

Apache configuration files are 'routing settings for domains'

<VirtualHost *:80>
    ServerName example.com
    ProxyPass / http://localhost:3000/
    ProxyPassReverse / http://localhost:3000/
</VirtualHost>

In other words:

The concept of ports

A port is a "building entrance"

If you think of a server as a large building:

サーバー（ビル）
├── 22番入り口（SSH専用）
├── 80番入り口（HTTP専用）
├── 443番入り口（HTTPS専用）
├── 3000番入り口（Django MCP専用）
└── 他にも沢山の入り口...

How it works in this configuration

1. External access

ユーザー → 「https://example.com」
↓
Apache「443番入り口（HTTPS）で受け取った！」

2. Internal processing

Apache → 「exampleの設定を確認...3000番に転送しよう」
↓
Apache → 「3000番入り口のDjangoアプリさん、お客さんです」
↓
Django（3000番）→ 「了解、レスポンス作りました」

3. Returning to the outside

Django → Apache → ユーザー

The relationship between firewalls and ports

Firewall (ufw): "A fence around the building"

80番、443番の関所は開放
3000番の関所は内部専用（外部からは直接アクセス不可）

Apache: "A receptionist"

「80/443番で受け取って、適切な部署（3000番）に案内します」

Process and queue mechanisms

Apache's operating principle

Multi-process configuration:

Apache親プロセス (pid=463986)
├── 子プロセス1 (pid=1304755)
├── 子プロセス2 (pid=1304756)
└── 子プロセス3 (pid=1304753)

Why multiple?

• Handling simultaneous access: Processing multiple users at the same time

• Speeding up: If one process is busy, others can respond

• Stability: If one crashes, others continue to operate

The relationship between the number of processes and the queue

Using a restaurant as an analogy:

建物の外（キュー）: 511人まで待機可能
建物の中（プロセス）: 150人まで対応中
├── 部署A（ポート80）: 70人対応中
├── 部署B（ポート443）: 60人対応中
└── 部署C（他の処理）: 20人対応中
合計150人が中で作業中

MaxRequestWorkers 150 = Apache's total simultaneous processing capacity (not per port)

Configuration verification command

# 現在のポート使用状況
sudo ss -tlnp | grep -E ':80|:443'

# Apacheの設定確認
sudo apache2ctl -S

# プロセス一覧
ps aux | grep apache2

Website access restriction system

Two-stage control system

Front-end (application) control

• Purpose: Service quality, fairness, and business strategy

• Display: "There are currently 500 people waiting"

• User-visible restrictions

Internal (system) control

• Purpose: System protection and technical security

• Mechanism: 511 people in queue, 150 people in process

• User-invisible restrictions

Implementation methods for access restrictions

1. WebSocket / Server-Sent Events

const socket = new WebSocket('wss://example.com/queue');
socket.onmessage = (event) => {
  const data = JSON.parse(event.data);
  console.log(`現在の順番: ${data.position}`);
};

2. Gradual redirection

1. ユーザーがアクセス
2. サーバー「満員です」→ 待機ページにリダイレクト
3. 待機ページ「現在500人待ちです」表示
4. 30秒後に自動リロード
5. 空きができたら本サイトにリダイレクト

3. Token-based method

11:00-11:15の枠: トークンABC123
11:15-11:30の枠: トークンDEF456
→「11:05になったらアクセスしてください」

Challenges in queue management

Session management issues:

ユーザーA: 100番目で待機中
↓ ブラウザ閉じる
↓ 再アクセス
↓ 新しいセッション = 最後尾（500番目）に！

Practical countermeasures:

• Warning: "Please do not close your browser"

• Restart from the end of the line upon reconnection

• The same rules as a real-world queue (leaving the line = starting over)

Summary

Key Points

1. Proxy = Intermediary: A completely different concept from 'skewering'

2. Port = Building entrance: Windows for specific purposes

3. Process = Worker inside the building: The queue is the people waiting outside

4. Two-stage control: Front-end limits (improving experience) + System limits (protection)

Application in Actual Configuration

By understanding these concepts:

• You can understand the meaning of Apache configuration files

• You can see how to handle troubleshooting

• You can identify points for performance improvement

• You can understand the meaning of security settings

Web server management is a combination of these basic concepts. If you understand them one by one, you will see that even settings that look complex are actually logically structured.

Finally

I worked on a server for the first time in a very long time.

I had forgotten quite a bit, so I proceeded while having Claude teach me the settings, and the explanations were incredibly easy to understand, which was a great learning experience again. I'm really grateful for generative AI, as it used to be so hard to look things up in the past.

Also, among the various things Claude taught me, the
story about the website admission restriction system was interesting. I had been curious about how it worked for a while, so I'm glad I could learn about it in detail this time.

Next time, I would like to finish the server-side configuration and actually proceed from request to response.

I will summarize any progress on the MCP server production again, so I would be happy if you could read it again if you'd like.

See you later!