วิธีตั้งค่า Authentication สำหรับ Claude API บน VPS

เส้นทางการยืนยันตัวตน 4 รูปแบบของ Claude API

การยืนยันตัวตนสำหรับ Claude API ขึ้นอยู่กับการตัดสินใจเพียงอย่างเดียว คือการเลือกใช้ข้อมูลรับรอง (credential) ที่ไคลเอนต์ของคุณจะส่งผ่านเครือข่าย ซึ่งมีอยู่ 4 รูปแบบหลัก และแต่ละรูปแบบไม่ได้เป็นเพียงตัวแปรของกลไกเดียวกัน โดย Anthropic API แบบโดยตรงจะส่งคีย์แบบคงที่ในส่วนหัว x-api-key ส่วน Amazon Bedrock จะใช้วิธีลงนามในทุกคำขอด้วยข้อมูลรับรองของ AWS ซึ่งในรูปแบบนี้จะไม่มีคีย์ของ Anthropic เข้ามาเกี่ยวข้องเลย สำหรับ Google Cloud จะใช้ Google access token ที่มีอายุการใช้งานสั้น และ Microsoft Foundry จะใช้คีย์ที่ออกโดย Azure หรือโทเค็นจาก Microsoft Entra

คู่มือนี้จัดทำขึ้นสำหรับการเชื่อมต่อ SDK (software development kit) เข้ากับบริการที่ทำงานบนเซิร์ฟเวอร์ Linux หากคุณกำลังตั้งค่าเครื่องมือบรรทัดคำสั่ง Claude Code ตัวแปรและขั้นตอนการทำงานจะแตกต่างออกไป โปรดดูที่ การกำหนดค่า Claude Code ให้ใช้งาน Bedrock หรือ Vertex หากบริการดังกล่าวยังไม่มีอยู่จริง ให้สร้างขึ้นก่อนโดยดูที่ การสร้างแอป Claude API แอปแรกบน VPS แล้วจึงกลับมาที่นี่เพื่อตั้งค่าข้อมูลรับรอง

เนื้อหาทั้งหมดด้านล่างได้รับการตรวจสอบกับเอกสารประกอบแพลตฟอร์มของ Anthropic ณ เดือนสิงหาคม 2026 เนื่องจากตัวระบุโมเดล ราคา เวอร์ชันของ SDK และรูปแบบของ endpoint มีการเปลี่ยนแปลงอยู่เสมอ คู่มือนี้จึงใช้วิธีเชื่อมโยงไปยังหน้าเว็บของผู้ให้บริการแทนการระบุค่าที่อาจล้าสมัยได้ในอนาคต

เส้นทางที่ 1: Anthropic API key

นี่คือเส้นทางโดยตรงและเป็นวิธีเดียวที่ Anthropic ออกรหัสลับให้ คำขอจะถูกส่งไปยัง Messages endpoint บนโฮสต์ API ของ Anthropic และทุกคำขอจะต้องมีส่วนหัว (header) สามรายการ

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "MODEL_ID", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

ให้แทนที่ MODEL_ID ด้วยตัวระบุปัจจุบันจาก ภาพรวมโมเดล ของ Anthropic การตอบสนองที่ถูกต้องจะเป็น JSON ที่บรรจุอาร์เรย์ content และออบเจกต์ usage หากคีย์ไม่ถูกต้องหรือหมดอายุ ระบบจะส่งกลับ HTTP 401 พร้อมกับ authentication_error หากส่วนหัว anthropic-version หายไปจะถือเป็นความล้มเหลวอีกรูปแบบหนึ่ง เนื่องจากส่วนหัวนี้จำเป็นสำหรับทุกคำขอ โดยปกติ SDK จะตั้งค่าส่วนหัวนี้ให้คุณโดยอัตโนมัติ

การสร้างไคลเอ็นต์ในวิธีนี้สั้นที่สุดในบรรดาทั้งสี่วิธี เนื่องจากไม่มีขั้นตอนการตั้งค่าที่ซับซ้อน SDK อย่างเป็นทางการทุกตัวจะอ่านค่า ANTHROPIC_API_KEY จากสภาพแวดล้อม (environment) ด้วยตัวเอง

import os
from anthropic import Anthropic

client = Anthropic()  # reads ANTHROPIC_API_KEY from the environment

message = client.messages.create(
    model=os.environ["CLAUDE_MODEL"],
    max_tokens=64,
    messages=[{"role": "user", "content": "Hello"}],
)
print(message.usage)

การเก็บตัวระบุโมเดลไว้ในสภาพแวดล้อมควบคู่ไปกับคีย์เป็นสิ่งที่ควรทำ ชื่อโมเดลมีการเปลี่ยนแปลงตามกำหนดการที่คุณไม่สามารถควบคุมได้ และการต้อง deploy โค้ดใหม่เพียงเพื่อแก้ไขสตริงเดียวเป็นงานที่หลีกเลี่ยงได้

คีย์จะถูกสร้างขึ้นใน Console ซึ่งคุณสามารถเลือกวันหมดอายุได้ในขณะสร้าง โดยมีค่าเริ่มต้นให้เลือกคือ 3 ชั่วโมง, 1 วัน, 7 วัน หรือ 30 วัน รวมถึงการกำหนดระยะเวลาเอง หรือเลือกไม่มีวันหมดอายุ วันหมดอายุจะถูกกำหนดตายตัวตั้งแต่ตอนสร้างและไม่สามารถเปลี่ยนแปลงภายหลังได้ Anthropic จะส่งอีเมลแจ้งเตือนผู้สร้างคีย์ก่อนที่คีย์ที่มีอายุการใช้งานยาวนานจะหมดอายุ แต่สำหรับคีย์ที่มีอายุการใช้งานสั้น ระบบจะไม่มีการส่งอีเมลแจ้งเตือนใดๆ ทั้งสิ้น คีย์ที่หมดอายุจะส่งกลับสถานะ 401 และไม่สามารถเปิดใช้งานใหม่ได้ ดังนั้นวิธีแก้ไขคือการสร้างคีย์ใหม่เสมอ

ไม่มีการเลือกภูมิภาค (region) สำหรับการใช้งาน API โดยตรง และค่าใช้จ่ายจะถูกเรียกเก็บไปยังองค์กร Anthropic ของคุณโดยตรง การใช้ Workspaces จะช่วยจำกัดขอบเขตของคีย์ให้ครอบคลุมเฉพาะโปรเจกต์เดียว ซึ่งเป็นวิธีที่ชัดเจนที่สุดในการตรวจสอบค่าใช้จ่ายของบริการแต่ละตัว สำหรับรายละเอียดการคำนวณค่าใช้จ่าย โปรดดู การเปรียบเทียบราคา API แบบต่อโทเค็นกับแบบสมาชิก

มีอีกหนึ่งตัวเลือกที่ควรกล่าวถึงในที่นี้ เนื่องจากช่วยกำจัดรหัสลับแบบคงที่ (static secret) ออกไปได้ทั้งหมด Workload Identity Federation ช่วยให้ workload สามารถแลกเปลี่ยน OpenID Connect (OIDC) token จากผู้ให้บริการยืนยันตัวตนที่คุณเชื่อถืออยู่แล้ว เพื่อรับ Anthropic token ที่มีอายุการใช้งานสั้นที่ POST /v1/oauth/token และ SDK จะทำการรีเฟรช token นั้นก่อนที่จะหมดอายุ วิธีนี้จะไม่มีการสร้างหรือคัดลอกสตริง sk-ant-api... ไปไว้ที่ใดเลย วิธีนี้เหมาะสำหรับ Kubernetes, GitHub Actions และ cloud VM ซึ่งมีตัวตนบนแพลตฟอร์มอยู่แล้ว สำหรับ VPS ทั่วไปมักไม่มีผู้ออกใบรับรอง (issuer) ดังกล่าว ดังนั้นบนเครื่องประเภทนี้ การเก็บ API key ไว้ในไฟล์จึงเป็นวิธีที่ตรงไปตรงมาที่สุด และเนื้อหาส่วนที่เหลือของคู่มือนี้จะถือว่าคุณใช้วิธีดังกล่าว

เส้นทางที่ 2: การใช้ AWS credentials บน Amazon Bedrock

บน Bedrock คุณไม่จำเป็นต้องมี Anthropic key เลย SDK จะทำการลงนามในคำขอ HTTP แต่ละรายการด้วย AWS Signature Version 4 (SigV4) โดยใช้ AWS credentials ตามปกติ และ AWS จะเป็นผู้ตัดสินใจว่าผู้เรียกรายนั้นมีสิทธิ์เรียกใช้โมเดลหรือไม่

pip install -U "anthropic[bedrock]"
aws sts get-caller-identity

aws sts get-caller-identity จะแสดงหมายเลขบัญชีและ ARN (Amazon Resource Name) ของตัวตนที่ credentials ของคุณอ้างอิงถึง ให้รันคำสั่งนี้ก่อนขั้นตอนอื่น หากคำสั่งนี้ล้มเหลว การเรียกใช้ Claude ก็จะล้มเหลวเช่นกัน เนื่องจาก SDK จะตรวจสอบตามลำดับขั้นตอนเดียวกัน คือเริ่มจากอาร์กิวเมนต์ในคอนสตรัคเตอร์ ตามด้วยตัวแปรสภาพแวดล้อม AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, AWS_SESSION_TOKEN และ AWS_REGION จากนั้นจึงเป็นไฟล์ AWS config และส่วนที่เหลือของลำดับมาตรฐาน (SSO, assumed roles, ECS task role, instance metadata service)

สิ่งที่เปลี่ยนแปลงในการสร้าง client คือคลาสและอาร์กิวเมนต์หนึ่งตัว

from anthropic import AnthropicBedrock

client = AnthropicBedrock(aws_region="us-east-1")

Region ในที่นี้ไม่ใช่แค่ข้อมูลประกอบ แต่ endpoints ของ Bedrock แยกตาม region และการเข้าถึงโมเดลจะถูกกำหนดสิทธิ์แยกตาม region ใน AWS console นอกจากนี้ region ยังเป็นส่วนหนึ่งของลายเซ็น SigV4 ดังนั้นลายเซ็นที่คำนวณสำหรับ region หนึ่งจะถูกปฏิเสธโดยอีก region หนึ่ง ให้ตั้งค่า AWS_REGION ให้ชัดเจนในสภาพแวดล้อมของบริการ Anthropic ระบุไว้ว่า AnthropicBedrock client จะอ่านค่า AWS_REGION และจะใช้ us-east-1 แทนหากไม่ได้ตั้งค่าไว้ และ client จะไม่อ่านค่า ~/.aws/config เพื่อกำหนด region นี่คือเหตุผลที่ AWS CLI สามารถแสดงรายการโมเดล Claude ได้สำเร็จบนเครื่องเดียวกับที่โปรเซส Python ของคุณล้มเหลว เพราะ CLI อ่านไฟล์ config ของคุณในขณะที่ client ไม่ได้อ่าน

บน EC2 instance คุณสามารถแนบ IAM (identity and access management) role ได้โดยไม่ต้องมี secret ใดๆ เก็บไว้บนดิสก์ เนื่องจาก instance metadata service จะส่งมอบ temporary credentials ให้กับ SDK ส่วน VPS ที่อยู่นอก AWS จะไม่มีทั้ง instance role และ metadata service คุณจึงต้องเลือกระหว่างการใช้ access key pair แบบถาวรของ IAM user ซึ่งเก็บไว้บนเครื่อง (ซึ่งถือเป็น secret ประเภทเดียวกับ Anthropic key) หรือการใช้ federation: คือการยืนยันตัวตนกับ identity provider ของคุณ จากนั้นเรียกใช้ AWS STS (security token service) แล้วใช้ temporary credentials ที่ได้รับกลับมา นอกจากนี้ Bedrock ยังรองรับ bearer token ผ่าน AWS_BEARER_TOKEN_BEDROCK ซึ่งมีเอกสารระบุว่ามีอายุสูงสุด 12 ชั่วโมง และ AWS ระบุว่าเป็นวิธีที่แนะนำน้อยที่สุด

ค่าใช้จ่ายจะถูกเรียกเก็บไปยังบัญชี AWS ของคุณแทนที่จะเป็น Anthropic ซึ่งมักเป็นเหตุผลหลักในการเลือกใช้บริการนี้ Regional endpoints มีค่าธรรมเนียมสูงกว่า global endpoint อยู่ 10% ตามที่ระบุไว้ในเอกสารเมื่อเดือนสิงหาคม 2026 มีข้อผิดพลาดหนึ่งของ Bedrock ที่ควรทราบเพราะดูเหมือนปัญหาเรื่องสิทธิ์แต่ไม่ใช่: Invocation of model ID ... with on-demand throughput isn't supported. Retry your request with the ID or ARN of an inference profile that contains this model. นั่นคือปัญหาเรื่องการกำหนดเส้นทางโมเดล (model routing) ซึ่งการเปลี่ยน credential จะไม่สามารถแก้ไขปัญหานี้ได้

เส้นทางที่ 3: ข้อมูลรับรอง Google บน Vertex AI

Google Cloud ใช้ Application Default Credentials (ADC) ซึ่งเป็นลำดับการค้นหาที่กำหนดไว้ตายตัวเพื่อให้ไลบรารีการยืนยันตัวตนของ Google ค้นหาข้อมูลรับรองได้โดยที่คุณไม่ต้องระบุชื่อ ADC จะตรวจสอบ GOOGLE_APPLICATION_CREDENTIALS ก่อน จากนั้นจึงตรวจสอบไฟล์ที่เขียนโดย gcloud auth application-default login และสุดท้ายคือบัญชีบริการ (service account) ที่แนบผ่าน metadata server

pip install -U "anthropic[vertex]"
gcloud auth application-default login

บนเวิร์กสเตชัน การล็อกอินจะเขียนไฟล์ $HOME/.config/gcloud/application_default_credentials.json และคุณก็ดำเนินการเสร็จสิ้น แต่บนเซิร์ฟเวอร์ นี่เป็นเครื่องมือที่ไม่เหมาะสม เพราะข้อมูลรับรองที่จัดเก็บไว้เป็นของบุคคลและจะใช้งานไม่ได้เมื่อบัญชีของบุคคลนั้นสิ้นสุดลง นอกจากนี้ หากอยู่นอก Google Cloud จะไม่มี metadata server ดังนั้น ADC จะเปลี่ยนไปใช้ GOOGLE_APPLICATION_CREDENTIALS ซึ่งชี้ไปยังไฟล์คีย์ของบัญชีบริการ ไฟล์ JSON ดังกล่าวเป็นความลับที่มีอายุการใช้งานยาวนานและจำเป็นต้องได้รับการจัดการตามที่อธิบายไว้ในภายหลังของคู่มือนี้ หากอยู่ภายใน Google Cloud ให้แนบบัญชีบริการเข้ากับ VM แล้วคุณจะไม่ต้องปกป้องไฟล์ใดๆ อีก

from anthropic import AnthropicVertex

client = AnthropicVertex(project_id="my-project", region="global")

มีสองสิ่งที่เปลี่ยนแปลงหากคุณลดระดับจากการใช้ SDK มาเป็นการเรียก HTTP โดยตรง ตัวระบุโมเดลจะย้ายออกจากเนื้อหาคำขอ (request body) ไปอยู่ใน URL path และ anthropic_version จะย้ายออกจากส่วนหัว (header) ไปอยู่ในเนื้อหาคำขอ ซึ่งต้องระบุเป็น vertex-2023-10-16 ข้อมูลรับรองดังกล่าวคือ Google access token ปกติ

curl https://aiplatform.googleapis.com/v1/projects/${PROJECT_ID}/locations/global/publishers/anthropic/models/${MODEL_ID}:rawPredict \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  -d '{"anthropic_version": "vertex-2023-10-16", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

ภูมิภาค (Region) เป็นอาร์กิวเมนต์สำคัญ global จะกำหนดเส้นทางแบบไดนามิกเพื่อความพร้อมใช้งาน ส่วน us และ eu เป็นตัวระบุแบบหลายภูมิภาค (multi-region) และชื่ออย่างเช่น us-east5 จะเป็นการระบุภูมิภาคเดียวแบบเจาะจง จุดเชื่อมต่อแบบหลายภูมิภาคและระดับภูมิภาคมีค่าใช้จ่ายสูงกว่าแบบ global อยู่ 10% ตามที่ระบุไว้ในเอกสารเมื่อเดือนสิงหาคม 2026 การเรียกเก็บเงินจะดำเนินการผ่านโปรเจกต์ Google Cloud ดังนั้นโควตาและใบแจ้งหนี้จะเป็นของ Google

เส้นทางที่ 4: Microsoft Foundry คือเส้นทางสำหรับ Azure

หากคุณค้นหา Claude บน Azure นี่คือส่วนที่คุณต้องการ และมีเส้นทางที่รองรับอยู่จริง Claude ทำงานใน Microsoft Foundry (เดิมคือ Azure AI Foundry) โดยคิดค่าบริการผ่าน Azure Marketplace ในหน่วย Claude Consumption Units คุณต้องสร้างทรัพยากร Foundry, ปรับใช้โมเดล Claude ภายในนั้น และเรียกใช้งาน endpoint ที่โฮสต์บน Azure ที่ https://{resource}.services.ai.azure.com/anthropic/v1/*

คุณสามารถใช้ข้อมูลรับรองได้ 2 รูปแบบ รูปแบบแรกคือคีย์ที่ออกโดย Azure ซึ่งดูได้จากแท็บ Details ของการปรับใช้ในพอร์ทัล Foundry โดยส่งผ่าน header api-key หรือ x-api-key รูปแบบที่สองคือ Microsoft Entra token ซึ่งเป็นตัวเลือกที่ดีกว่าสำหรับการใช้งานบนเซิร์ฟเวอร์ เนื่องจาก Azure role-based access control จะเป็นตัวควบคุมว่าใครสามารถเรียกใช้งาน endpoint ได้บ้าง

ACCESS_TOKEN=$(az account get-access-token --resource https://ai.azure.com --query accessToken -o tsv)

curl https://${RESOURCE}.services.ai.azure.com/anthropic/v1/messages \
  -H "content-type: application/json" \
  -H "Authorization: Bearer $ACCESS_TOKEN" \
  -H "anthropic-version: 2023-06-01" \
  -d '{"model": "DEPLOYMENT_NAME", "max_tokens": 64, "messages": [{"role": "user", "content": "Hello"}]}'

ฟิลด์ model จะระบุ ชื่อการปรับใช้ (deployment name) ของคุณ ไม่ใช่ตัวระบุโมเดล โดยปกติแล้วทั้งสองค่าจะตรงกัน แต่จะเริ่มไม่ตรงกันทันทีที่คุณตั้งชื่อการปรับใช้ด้วยตนเอง ซึ่งเป็นสาเหตุทั่วไปที่ทำให้เกิดข้อผิดพลาด Deployment not found ในคำขอที่ถูกต้องในส่วนอื่น SDK สำหรับ Python และ TypeScript จะอ่านค่า ANTHROPIC_FOUNDRY_API_KEY และ ANTHROPIC_FOUNDRY_RESOURCE จาก environment โดยตรง การรองรับ Foundry ไม่ได้มีอยู่ในทุก SDK: ตามเอกสาร ณ เดือนสิงหาคม 2026 ครอบคลุมภาษา C#, Java, PHP, Python และ TypeScript ในขณะที่ SDK สำหรับ Go และ Ruby จำเป็นต้องใช้ generic client โดยชี้ไปยัง base URL ของ Foundry

วิธีแก้ปัญหาเฉพาะหน้านี้มีความเสี่ยง หาก ANTHROPIC_API_KEY ยังคงถูกตั้งค่าไว้ใน environment ตัว generic client จะดึงค่านั้นไปใช้และส่งคีย์ Anthropic ของคุณไปยัง endpoint ของ Microsoft คุณควรยกเลิกการตั้งค่าตัวแปรดังกล่าว หรือปิดการใช้งานค่าเริ่มต้นของ environment บนตัว client สำหรับ Entra token นั้นจะมีอายุการใช้งานประมาณหนึ่งชั่วโมง ดังนั้นกระบวนการที่ทำงานต่อเนื่องยาวนานจะต้องทำการรีเฟรช token แทนที่จะเก็บค่าไว้เพียงครั้งเดียวตอนเริ่มต้นโปรแกรม

ข้อมูลประจำตัวบนเซิร์ฟเวอร์ของคุณมีอายุการใช้งานนานเท่าใด

[
  {
    "label": "Anthropic key, 30-day preset",
    "max_lifetime_hours": 720
  },
  {
    "label": "Anthropic key, 7-day preset",
    "max_lifetime_hours": 168
  },
  {
    "label": "AWS STS assumed role",
    "max_lifetime_hours": 12
  },
  {
    "label": "Bedrock bearer token",
    "max_lifetime_hours": 12
  },
  {
    "label": "Entra ID access token",
    "max_lifetime_hours": 1
  },
  {
    "label": "Federated Anthropic token",
    "max_lifetime_hours": 1
  }
]

ค่าเหล่านี้เป็นเพดานและค่าเริ่มต้นที่ผู้ให้บริการแต่ละรายประกาศไว้ โดยอ้างอิงข้อมูล ณ เดือนสิงหาคม 2026 ไม่ใช่ค่าที่วัดจากการใช้งานจริง ข้อมูลเหล่านี้มีความสำคัญด้วยเหตุผลเดียวคือ เพื่อให้คุณทราบว่าข้อมูลประจำตัวที่รั่วไหลจะยังคงใช้งานได้นานเพียงใดในระหว่างที่คุณกำลังตรวจสอบการรั่วไหลนั้น โทเค็นที่มีอายุการใช้งานสั้นที่อยู่ด้านล่างของตารางจะมีอายุ 1 ชั่วโมงต่อรายการ และ SDK จะทำการรีเฟรชให้โดยอัตโนมัติ ดังนั้นอายุการใช้งานที่สั้นจึงไม่ส่งผลกระทบต่อการดำเนินงานของคุณ ส่วนบทบาทที่ถูกสมมติขึ้น (assumed role) จะมีอายุ 12 ชั่วโมง สำหรับคีย์ที่สร้างขึ้นด้วยค่าเริ่มต้น 30 วันจะมีอายุการใช้งาน 720 ชั่วโมง ซึ่งนั่นคือข้อมูลประจำตัวที่ถูกจัดเก็บไว้ในไฟล์บนเซิร์ฟเวอร์ของคุณเป็นเวลาหนึ่งเดือน

ตำแหน่งที่เก็บข้อมูลรับรองบน VPS

ให้เก็บข้อมูลลับไว้ในไฟล์ที่เฉพาะ root เท่านั้นที่อ่านได้ แล้วปล่อยให้ systemd ส่งข้อมูลนั้นไปยัง process วิธีนี้ใช้งานได้ยาวนานกว่าเวอร์ชันของ SDK ใดๆ จึงคุ้มค่าที่จะทำเพียงครั้งเดียวให้ถูกต้อง

sudo useradd --system --home /opt/claude-app --shell /usr/sbin/nologin claudeapp
sudo install -d -m 700 -o root -g root /etc/claude-app
sudo install -m 600 -o root -g root /dev/null /etc/claude-app/env
sudoedit /etc/claude-app/env

ไฟล์นี้จะเก็บข้อมูลในรูปแบบบรรทัด KEY=value ธรรมดา ไม่ต้องใส่ export ไม่ต้องมีเครื่องหมายคำพูด และไม่ต้องใช้ไวยากรณ์ของ shell เนื่องจาก systemd จะเป็นผู้ประมวลผลไฟล์นี้ด้วยตัวเองแทนที่จะรันผ่าน shell

ANTHROPIC_API_KEY=sk-ant-api03-REPLACE-ME
CLAUDE_MODEL=REPLACE-ME

[Unit]
Description=Claude API service
After=network-online.target

[Service]
User=claudeapp
EnvironmentFile=/etc/claude-app/env
ExecStart=/opt/claude-app/venv/bin/python -m claude_app
Restart=on-failure

[Install]
WantedBy=multi-user.target

systemd จะอ่านไฟล์ EnvironmentFile= ในฐานะ root ก่อนที่จะลดสิทธิ์ลงไปเป็น User=claudeapp ดังนั้นบัญชีผู้ใช้ของ service จึงไม่จำเป็นต้องมีสิทธิ์อ่านไฟล์นี้ การตั้งค่าโหมด 600 โดยให้ root เป็นเจ้าของนั้นเพียงพอแล้ว ซึ่งเป็นเหตุผลว่าทำไมคำสั่ง install ด้านบนจึงตั้งค่าไว้เช่นนั้น เริ่มต้นการทำงานด้วย sudo systemctl enable --now claude-app จากนั้นตรวจสอบด้วย systemctl status claude-app ว่า unit เข้าสู่สถานะ active (running) แล้ว แทนที่จะเป็นการรีสตาร์ทวนซ้ำไปมา

มี 4 สิ่งที่ควรหลีกเลี่ยง โดยแต่ละข้อมีเหตุผลที่คุณสามารถตรวจสอบได้ด้วยตนเอง:

• อย่าเขียน key ลงใน Environment= ภายในไฟล์ unit เพราะ unit ที่อยู่ภายใต้ /etc/systemd/system นั้นทุกคนสามารถอ่านได้ ดังนั้น systemctl cat claude-app จะแสดงข้อมูลลับออกมาให้ผู้ใช้ในเครื่องทุกคนเห็น
• อย่า commit ไฟล์นี้ลงใน repository เพราะ .gitignore จะช่วยป้องกันไม่ให้ไฟล์ใหม่ถูก commit เท่านั้น แต่ไม่มีผลกับไฟล์ที่ถูก commit ไปแล้ว เนื่องจากประวัติของ git จะเก็บข้อมูลทุกอย่างที่เคยได้รับไว้
• อย่าฝังข้อมูลลับไว้ใน container image เพราะบรรทัด ENV และค่า --build-arg จะถูกบันทึกไว้ใน layer ของ image และ docker history --no-trunc จะแสดงข้อมูลเหล่านั้นออกมา การลบไฟล์ใน layer ถัดมาจะไม่ช่วยลบข้อมูลออกจาก layer ก่อนหน้า ให้ส่งข้อมูลลับในขณะรันไทม์ด้วย --env-file หรือใช้การ mount ไฟล์แทน
• อย่ามองว่า environment ของ process เป็นสิ่งที่ปลอดภัยจาก root เพราะ sudo tr '\\0' '\\n' < /proc/$(pgrep -u claudeapp -f claude_app | head -1)/environ สามารถแสดง key ออกมาได้ เป้าหมายคือการเก็บข้อมูลลับให้พ้นจากบัญชีผู้ใช้อื่นๆ ทั้งหมดในเครื่อง ไม่ใช่จาก root ซึ่งสามารถอ่านข้อมูลได้ไม่ว่าคุณจะทำอย่างไรก็ตาม

ประเด็นสุดท้ายนี้เป็นตัวกำหนดขอบเขตของสิ่งที่คุณได้รับจากการออกแบบนี้ environment variable เป็นที่เก็บข้อมูลลับที่ดีเมื่อมีเพียง service และ root เท่านั้นที่อ่านได้ แต่มันจะเป็นที่เก็บข้อมูลที่ผิดพลาดหาก process นั้นรันโค้ดที่คุณไม่ได้เขียนขึ้นเอง เพราะทุกสิ่งที่ process สามารถรันได้ย่อมสามารถอ่าน environment ของตัวเองได้ การเก็บข้อมูลลับให้พ้นจากมือของ AI agent จะครอบคลุมกรณีดังกล่าว ซึ่งเป็นปัญหาที่ต่างออกไปและมีคำตอบที่แตกต่างกัน

ฉันจะหมุนเวียนคีย์โดยไม่ให้เกิด downtime ได้อย่างไร

ให้หมุนเวียนคีย์ใหม่ก่อน แล้วจึงเพิกถอนคีย์เก่า

1. สร้างคีย์ใหม่ใน Console ภายใน Workspace เดียวกับคีย์เดิม
2. เขียนคีย์ลงใน /etc/claude-app/env ด้วย sudoedit
3. รันคำสั่ง sudo systemctl restart claude-app
4. ตรวจสอบว่าบริการตอบสนองต่อคำขอได้ตามปกติ จากนั้นจึงเพิกถอนคีย์เก่าใน Console

EnvironmentFile จะถูกอ่านเมื่อ unit เริ่มทำงาน ดังนั้นกระบวนการที่กำลังรันอยู่จะยังคงใช้ค่าที่ได้รับตอนเริ่มต้น ส่วน systemctl daemon-reload จะอ่านไฟล์ unit ใหม่เท่านั้นและไม่ส่งผลต่อ environment ของกระบวนการที่กำลังรันอยู่ ดังนั้นการรีสตาร์ทเท่านั้นที่จะทำให้ระบบรับค่าคีย์ใหม่ไปใช้งาน การเพิกถอนคีย์ในขั้นตอนที่ 1 แทนที่จะเป็นขั้นตอนที่ 4 จะทำให้เกิดเหตุการณ์ระบบหยุดทำงานจนกว่าจะถึงขั้นตอนที่ 3

อีกสามวิธีที่เหลือคือการหมุนเวียนที่ฝั่งผู้ให้บริการ IAM user รองรับการใช้งาน access key พร้อมกันได้สองชุด ดังนั้นให้สร้างคีย์ที่สอง นำไปปรับใช้ แล้วจึงลบชุดแรกทิ้ง Google service account key ก็ใช้วิธีการหมุนเวียนแบบเดียวกัน ส่วน Foundry key จะถูกสร้างใหม่ในพอร์ทัลซึ่งจะทำให้คีย์เดิมใช้งานไม่ได้ทันที ดังนั้นต้องเขียนค่าใหม่ลงไปก่อนที่คุณจะกดดำเนินการ ส่วน Entra tokens และ federated Anthropic tokens ไม่จำเป็นต้องหมุนเวียนเลย ซึ่งนั่นเป็นเหตุผลที่ดีที่สุดในการเลือกใช้งานหากทำได้

ในระหว่างที่คุณอยู่ใน Console ให้ตั้งค่าขีดจำกัดการใช้จ่าย (spend limit) สำหรับ Workspace นั้นไว้ด้วย เพราะคีย์ที่หลุดออกไปอาจสร้างค่าใช้จ่ายมหาศาลก่อนที่จะเกิดปัญหาอื่นตามมา และ การจำกัดงบประมาณสำหรับเอเจนต์บน VPS จะอธิบายขั้นตอนการควบคุมส่วนนี้ไว้โดยละเอียด

เหตุใดไคลเอนต์ของฉันจึงตอบกลับเป็น 401 หรือ 403?

401 พร้อม authentication_error บน API โดยตรง คีย์อาจไม่ถูกต้อง ถูกเพิกถอน หรือหมดอายุแล้ว ผู้ใช้งานมักมองข้ามเรื่องวันหมดอายุเนื่องจากโค้ดไม่ได้มีการเปลี่ยนแปลงและคำขอยังทำงานได้ตามปกติเมื่อวานนี้ ให้ตรวจสอบคอลัมน์วันหมดอายุของคีย์ใน Console หรืออ่านค่า expires_at จาก Admin API ซึ่งจะมีค่าเป็น null สำหรับคีย์ที่ไม่มีวันหมดอายุ

SDK เพิกเฉยต่อการตั้งค่า federation ของคุณและใช้คีย์แทน ANTHROPIC_API_KEY และ ANTHROPIC_AUTH_TOKEN มีลำดับความสำคัญของข้อมูลประจำตัวสูงกว่า federation ดังนั้นค่าใดค่าหนึ่งจะบดบังการตั้งค่าดังกล่าว ประเด็นสำคัญคือ: ตัวแปรที่ถูก export เป็นสตริงว่างยังคงใช้ช่องของมันอยู่ ดังนั้น ANTHROPIC_API_KEY="" จึงทำให้ SDK พยายามยืนยันตัวตนด้วยคีย์ว่างแทนที่จะข้ามไปใช้ค่าอื่น ให้ใช้ unset ANTHROPIC_API_KEY แทน

401 พร้อมข้อความ Authentication failed บน federation ข้อความดังกล่าวถูกกำหนดให้เหมือนกันในทุกกรณีที่เป็นไปได้ เพื่อป้องกันไม่ให้ผู้เรียกใช้ตรวจสอบการตั้งค่ากฎของคุณผ่านการอ่านข้อความแสดงข้อผิดพลาด สาเหตุที่แท้จริงจะถูกบันทึกไว้ในหน้าประวัติการยืนยันตัวตน (authentication history) ใน Console ให้เริ่มตรวจสอบจากจุดนั้นแทนการคาดเดาค่า JWT

403 บน Foundry โทเค็นผ่านการยืนยันตัวตนแล้ว แต่บัญชี Azure ของคุณไม่มีบทบาท (role) ที่อนุญาตให้เรียกใช้งานได้ ให้กำหนดบทบาท Azure RBAC เช่น Foundry User (เดิมคือ Azure AI User) หรือ Cognitive Services User ให้กับ identity ที่ทำการเรียกใช้งานนั้น

ปัญหาใดๆ บน Bedrock ให้รัน aws sts get-caller-identity ในฐานะ service user ก่อน คำสั่งนี้จะช่วยตอบว่าเครื่องมีข้อมูลประจำตัว AWS ที่ใช้งานได้หรือไม่ ซึ่งจะช่วยแยกแยะปัญหาเรื่องข้อมูลประจำตัวออกจากปัญหาเรื่องการเข้าถึงโมเดลหรือการเลือกภูมิภาค (region) ไม่ตรงกัน การเข้าถึงโมเดลจะถูกกำหนดแยกตามภูมิภาคใน AWS console ซึ่งมักจะเปิดใช้งานในภูมิภาคหนึ่งไว้แต่กลับไปเรียกใช้งานอีกภูมิภาคหนึ่งได้ง่าย

FAQ

ฉันจำเป็นต้องใช้ Anthropic API key เพื่อใช้งาน Claude บน Bedrock หรือ Vertex หรือไม่

ไม่จำเป็น บน Amazon Bedrock ตัว SDK จะลงนามในแต่ละคำขอด้วย AWS credentials โดยใช้ SigV4 และบน Google Cloud จะส่ง Google access token ที่ได้รับผ่าน Application Default Credentials ในทั้งสองกรณีนี้ไม่มี secret ที่ออกโดย Anthropic และค่าใช้จ่ายจะถูกเรียกเก็บไปยังบัญชีคลาวด์แทนที่จะเป็น Anthropic นี่คือเหตุผลว่าทำไมการทิ้ง Anthropic key ไว้ใน ANTHROPIC_API_KEY จึงเป็นอันตรายบนโฮสต์เหล่านั้น เพราะไคลเอนต์ทั่วไปที่ชี้ไปยัง cloud endpoint จะส่งคีย์ดังกล่าวออกไปโดยไม่ตั้งใจ

Claude มีให้บริการบน Azure หรือไม่

มี โดยผ่านทาง Microsoft Foundry หรือที่รู้จักในชื่อเดิมว่า Azure AI Foundry คุณต้องสร้างทรัพยากร Foundry ขึ้นมา จากนั้น deploy โมเดล Claude ลงไป แล้วเรียกใช้ https://{resource}.services.ai.azure.com/anthropic/v1/messages ด้วยคีย์ที่ออกโดย Azure ใน header api-key หรือใช้ Microsoft Entra bearer token ค่าใช้จ่ายจะถูกเรียกเก็บผ่าน Azure Marketplace ในรูปแบบ Claude Consumption Units ฟิลด์ model ในเนื้อหาคำขอต้องระบุชื่อ deployment ของคุณ ซึ่งชื่อนี้จะเหมือนกับตัวระบุโมเดลก็ต่อเมื่อคุณยังไม่ได้เปลี่ยนชื่อ deployment เท่านั้น

ฉันควรจัดเก็บ Claude API key ไว้ที่ใดบนเซิร์ฟเวอร์ Linux

ควรเก็บไว้ในไฟล์ที่ root เป็นเจ้าของและตั้งค่า mode เป็น 600 โดยโหลดผ่าน EnvironmentFile= ใน systemd unit ตัว systemd จะอ่านไฟล์นั้นในฐานะ root ก่อนที่จะเปลี่ยนสิทธิ์ไปยัง User= ของ unit ดังนั้น service account จึงไม่จำเป็นต้องเข้าถึงไฟล์ดังกล่าวโดยตรง ห้ามเก็บคีย์ไว้ใน repository, ห้ามเก็บไว้ในไฟล์ unit เอง (ซึ่งทุกคนสามารถอ่านได้และจะถูกแสดงออกมาเมื่อใช้ systemctl cat) และห้ามเก็บไว้ใน container image layers เนื่องจาก docker history --no-trunc จะแสดงค่าทุกอย่างที่ตั้งไว้ด้วย ENV หรือ --build-arg ออกมา

เหตุใดคำขอ Claude API ของฉันจึงเริ่มส่งค่า 401 กลับมาทั้งที่ไม่มีการเปลี่ยนแปลงใดๆ

สาเหตุที่พบบ่อยที่สุดคือคีย์หมดอายุตามระยะเวลาที่กำหนดไว้ตอนสร้าง คีย์จะถูกกำหนดวันหมดอายุตั้งแต่ตอนสร้างและไม่สามารถแก้ไขภายหลังได้ โดยคีย์ที่มีอายุการใช้งานสั้นจะหมดอายุโดยไม่มีอีเมลแจ้งเตือน คีย์ที่หมดอายุแล้วไม่สามารถเปิดใช้งานใหม่ได้ ดังนั้นให้สร้างคีย์ทดแทน เขียนลงในไฟล์ environment รีสตาร์ท service แล้วจึงเพิกถอนคีย์เก่าทิ้ง หากคีย์ยังคงใช้งานได้ปกติ ให้ตรวจสอบว่ามี credential เก่าที่ค้างอยู่มาทับซ้อนหรือไม่ เพราะ ANTHROPIC_API_KEY ที่ตั้งค่าเป็นสตริงว่างเปล่าจะมีความสำคัญเหนือแหล่งที่มาของ credential อื่นๆ ทั้งหมด